Safe-Decline with Alternative Suggestion Prompt Template

This prompt is built for product teams shipping user-facing AI features that must say no without breaking trust. The core job-to-be-done is refusal formatting and alternative generation, not policy decision-making. You should already have an upstream classifier, policy engine, or rule system that has determined the request is disallowed. The model's responsibility here is narrow: take that decision, produce a clear decline statement, and offer a specific, actionable alternative that stays within policy boundaries. Typical deployment points include customer support copilots that cannot process refunds but can check order status, internal knowledge assistants that cannot access HR records but can point to the employee handbook, and code-generation tools with license restrictions that cannot reproduce GPL code but can suggest an architectural pattern.

Do not use this prompt when the request requires a hard block with no alternative, when the policy decision itself is ambiguous and needs the model to interpret rules, or when the refusal must cite specific policy clauses with audit-grade precision. For hard blocks, use a Hard Refusal Boundary Prompt Template. For policy citation, use a Policy-Aware Refusal Language Prompt Template. For ambiguous requests that need clarification before deciding, use a Refusal for Ambiguous Requests Prompt Template. This prompt also assumes a single-turn refusal with an alternative. If you need cross-turn consistency where the model remembers prior refusals and blocks rephrasing attempts, pair this with a Multi-Turn Refusal Consistency Prompt Template.

Before wiring this into production, define your tone calibration variables explicitly. A refusal for a healthcare chatbot should sound different from one in a developer tool. Test the prompt against edge cases where the alternative suggestion could be misinterpreted as an endorsement of a borderline activity, where the user's frustration level is high, or where the only available alternative is significantly less valuable than the original request. The most common production failure is the model generating an alternative that itself violates policy because the constraints were underspecified. Always validate the alternative against the same policy rules that triggered the refusal.

This template is designed to be placed in the system prompt or a dedicated refusal-handling layer of your AI application. It instructs the model to decline a user's request when it violates a defined policy, but instead of a dead-end 'I can't do that,' it guides the model to generate a helpful, in-bounds alternative. The core value is maintaining user trust and forward momentum while strictly enforcing safety and compliance boundaries. Before using this template, you must have a clear, written policy for what is disallowed. This prompt does not define your policy; it operationalizes it.

markdownCopy
# SYSTEM INSTRUCTION: SAFE-DECLINE WITH ALTERNATIVE SUGGESTION

You are an assistant operating under a strict safety and compliance policy. Your primary goal is to be helpful, but you must never comply with a request that violates the [POLICY_DOCUMENT].

## POLICY BOUNDARY
[POLICY_DOCUMENT]

## REFUSAL PROTOCOL
When a user's request is disallowed by the [POLICY_DOCUMENT], execute the following steps:
1.  **CLASSIFY**: Identify the specific policy clause that prohibits the request.
2.  **DECLINE**: Generate a refusal message in the [REFUSAL_TONE] tone. The refusal must:
    *   Acknowledge the user's underlying goal without repeating the disallowed request verbatim.
    *   State clearly that you cannot fulfill the request, citing the relevant policy category (e.g., 'safety guidelines,' 'content policy') without revealing the raw policy text.
3.  **SUGGEST**: Propose one or more constructive, alternative actions that are within policy bounds and address the user's likely underlying goal. The suggestion must be actionable and specific.
4.  **OUTPUT**: Format the final response as a single JSON object matching the [OUTPUT_SCHEMA].

## CONSTRAINTS
*   Never output the raw [POLICY_DOCUMENT] text.
*   Never engage in hypothetical scenarios that simulate violating the policy.
*   If the user's goal is ambiguous, ask clarifying questions before refusing. Only refuse when the violation is clear.
*   If no safe alternative exists, set the `alternative_suggestion` field to `null`.

## OUTPUT SCHEMA
```json
{
  "decision": "refused",
  "policy_category": "string",
  "refusal_message": "string",
  "alternative_suggestion": "string | null"
}

EXAMPLES

[EXAMPLES]

To adapt this template, replace the square-bracket placeholders with your specific operational details. [POLICY_DOCUMENT] should contain a concise, bulleted list of your disallowed use cases. [REFUSAL_TONE] should be a single adjective like 'empathetic,' 'clinical,' or 'firm' to calibrate the user-facing language. [EXAMPLES] is the most critical section for performance; provide 3-5 few-shot examples of user requests, the resulting JSON output, and a brief explanation of why the alternative was chosen. This grounds the model's behavior far more reliably than the instructions alone. For high-stakes applications, the [OUTPUT_SCHEMA] should be enforced via your inference platform's structured output or function-calling feature, not just the text instruction, to guarantee valid JSON parsing in your application code.

The Safe-Decline with Alternative Suggestion prompt is designed to sit behind a pre-execution safety check in your application's decision pipeline. Before any user-facing response is generated, your application should first classify the user's request against your policy rules. If the classifier returns a disallowed or needs-review verdict, the Safe-Decline prompt is invoked. This separation of concerns—classification first, refusal generation second—prevents the model from reasoning about policy boundaries and crafting a helpful response in the same call, which is a common vector for jailbreak and policy leakage. The classification step can be a simpler, faster model call or a deterministic rule engine, while the Safe-Decline prompt uses a more capable model to produce the user-facing text.

Wire the prompt into your application with a structured output contract. The prompt template should be configured to return a JSON object with at minimum decline_message (the user-facing refusal text), alternative_suggestion (the constructive, in-bounds alternative), and policy_tag (a machine-readable label for the policy that triggered the refusal, such as PII_DISCLOSURE or FINANCIAL_ADVICE). Validate this output before showing it to the user: confirm that decline_message is non-empty, that alternative_suggestion does not inadvertently fulfill the disallowed request, and that policy_tag matches one of your known policy identifiers. If validation fails, log the raw output for review and fall back to a static, pre-approved refusal message. Do not retry the Safe-Decline prompt more than once—if the model cannot produce a valid refusal on the second attempt, escalate to a human review queue and serve the static fallback.

For model selection, use a model with strong instruction-following and low refusal-creep for the Safe-Decline prompt itself. The classification step can often run on a smaller, faster model (e.g., a fine-tuned classifier or a lightweight model with a simple binary prompt). The Safe-Decline prompt benefits from a model that can calibrate tone and generate contextually appropriate alternatives without hallucinating capabilities. Log every refusal event with the session ID, user ID, original request, classification verdict, policy tag, generated decline message, alternative suggestion, and whether the output passed validation. This audit trail is essential for tuning refusal accuracy, defending against claims of bias or over-refusal, and demonstrating compliance. For high-risk domains, require a human reviewer to sample refusal logs daily and flag any decline messages that appear to leak policy details, offer inappropriate alternatives, or fail the tone calibration parameters.