Safe Alternative and Redirection Prompt Template

This prompt template is for product designers and safety engineers who need to build refusal flows that do more than say no. A refusal without a path forward drives user frustration and abandonment. This playbook produces a structured refusal with a policy-compliant alternative, a clear explanation of why the original request cannot be fulfilled, and a concrete next step the user can take. Use this when your application must reject disallowed, unsafe, or out-of-scope requests while preserving user trust and keeping the interaction productive.

The ideal deployment context is a classification or guardrail pipeline where an upstream safety classifier has already flagged a user request as disallowed. The prompt takes the classifier's label, the original request, and your policy definitions as input, then generates a refusal response that includes three required components: a brief, honest explanation of the policy boundary, a safe alternative that is genuinely useful and within policy, and a clear next action the user can take immediately. This is not a generic disclaimer generator. It is a reusable harness for refusal-plus-redirection that you can wire into classification pipelines, guardrails, or agent tooling. Before adopting this pattern, confirm that your system has a defined policy taxonomy, a classifier with acceptable precision and recall for your risk tolerance, and a catalog of approved safe alternatives mapped to each refusal category.

Do not use this prompt when the request requires immediate human intervention rather than a redirection—such as active self-harm, imminent violence, or child exploitation. Those scenarios should trigger an escalation workflow, not a redirection message. Do not use this prompt when your application has no safe alternative to offer; a hollow redirection to generic help pages erodes trust faster than an honest refusal with an explanation. Do not use this prompt for ambiguous requests where the correct action is clarification rather than refusal. And do not use this prompt as a substitute for proper upstream detection—if your classifier cannot reliably distinguish a legitimate security research question from a malware construction request, fix the classifier before tuning the refusal language. In high-risk domains such as healthcare, legal, or financial services, every refusal response must be reviewed by domain experts before deployment, and the safe alternatives must be vetted for accuracy and regulatory compliance.

This template provides a complete instruction set for an AI system to refuse a disallowed request while offering a constructive, policy-compliant alternative. The goal is to preserve user trust and provide a clear path forward, rather than a dead-end refusal. Replace every square-bracket placeholder with your specific application values before deployment. The template is designed to be used as a system-level instruction, a guardrail step in a compound AI system, or the core of a refusal-generation service.

codeCopy
You are a safety-focused assistant operating under a defined use policy. Your primary objective when encountering a disallowed request is to refuse safely while preserving the user's ability to achieve a legitimate, related goal.

When you identify a request that violates the [POLICY_NAME] policy, you must not comply, role-play, or continue the disallowed scenario. Instead, you will generate a structured refusal using the following internal logic:

1. **Classify the Request**: Identify the specific policy category from [POLICY_CATEGORIES] that the user's request falls under.
2. **Select an Alternative**: From the approved alternative map [ALTERNATIVE_MAP], choose the most relevant, policy-compliant alternative action or topic.
3. **Construct the Response**: Assemble a final message with three required components:
    - **Refusal Statement**: A clear, concise statement that the request cannot be fulfilled, citing the specific policy reason without being judgmental.
    - **Safe Alternative**: A concrete, actionable suggestion for a related task you can help with. This must be drawn from [ALTERNATIVE_MAP].
    - **Next Step**: A single, clear call to action for the user to proceed with the alternative.

**Output Format**: You must output a JSON object with the following schema. Do not include any text outside the JSON object.
{
  "policy_violation": "string, the specific policy category from [POLICY_CATEGORIES]",
  "refusal_message": "string, the complete user-facing refusal text with alternative and next step",
  "alternative_provided": "string, the key from [ALTERNATIVE_MAP] that was used",
  "escalation_required": boolean
}

**Constraints**:
- Do not repeat, summarize, or engage with the disallowed content in your refusal.
- The tone must be [REFUSAL_TONE], e.g., helpful, firm, and non-judgmental.
- If the request is ambiguous, default to safety and provide the most conservative alternative.
- If no suitable alternative exists in [ALTERNATIVE_MAP], set `alternative_provided` to "none" and the `refusal_message` must direct the user to [FALLBACK_HUMAN_ESCALATION_PATH]. In this case, `escalation_required` must be true.
- For requests classified under [HIGH_RISK_CATEGORIES], always set `escalation_required` to true, regardless of the alternative provided.

**Input**: You will receive the user's request as [USER_INPUT].

To adapt this template, start by defining your [POLICY_CATEGORIES] and [ALTERNATIVE_MAP]. The alternative map is the core of a good redirection; it should be a dictionary mapping a policy violation category (e.g., "medical_advice") to a safe alternative (e.g., "general_health_information"). The [REFUSAL_TONE] should be a specific, testable instruction like "empathetic and professional" or "direct and educational." For high-stakes domains, ensure [HIGH_RISK_CATEGORIES] is reviewed by your legal and policy teams. The structured JSON output is critical for logging, monitoring, and triggering downstream workflows like creating a ticket for human review when escalation_required is true.

Before shipping, validate that the prompt produces valid JSON under adversarial conditions. Test with edge cases like empty inputs, extremely long requests, and requests that sit on the boundary of multiple policy categories. A common failure mode is the model generating a refusal that subtly repeats the harmful premise; your evals must check for this. Wire the escalation_required boolean into your application logic to automatically create a review task in your internal tooling. Do not rely on the model alone to enforce the escalation; the application must act on the flag.

This prompt is designed to be a single step in a larger safety pipeline, not a standalone decision engine. Before the prompt is called, the application should have already classified the user request as requiring refusal and determined the specific policy violation. The prompt's job is to produce a structured, policy-compliant refusal with a constructive alternative. It should not be responsible for detecting the violation itself. Wire this prompt behind a classification router that passes in the [VIOLATED_POLICY], [RISK_LEVEL], and [REQUEST_CATEGORY] as resolved inputs. If the upstream classifier has low confidence, route to a human review queue instead of calling this prompt.

The output must be validated against a strict schema before it reaches the user. Expect a JSON object with refusal_statement, policy_explanation, safe_alternative, and next_step fields. Implement a post-generation validator that checks: (1) the safe_alternative field is not empty and is topically distinct from the disallowed request, (2) the policy_explanation references the specific policy passed in [VIOLATED_POLICY] rather than a generic disclaimer, and (3) the refusal_statement does not contain language that could be interpreted as judgmental or shaming. If validation fails, increment a retry counter and resubmit with the validation errors appended to [CONSTRAINTS]. After three failed retries, log the full prompt and response to an admin review queue and fall back to a static, pre-approved refusal message for that policy category. Never show a raw model refusal to the user without validation.

Observability is critical because refusal flows are a primary vector for user frustration and churn. Log the policy_id, risk_level, alternative_category, and a hash of the user input to your analytics pipeline. Track the rate at which users click or engage with the safe_alternative link versus abandoning the session. A declining alternative engagement rate signals that the redirections are not useful and need refreshing. Set up an alert if the refusal rate for a specific policy spikes above a rolling 7-day baseline, as this may indicate a new jailbreak technique or a change in user behavior. For high-risk categories like self-harm or child safety, the next_step field should include an escalation path that triggers a real-time notification to a trust-and-safety on-call channel, not just a static resource link. The prompt itself should never make the decision to escalate; the application layer reads the structured output and triggers the notification based on the [RISK_LEVEL] enum.