Safety Refusal with Alternative Suggestion Prompt

This prompt is designed for trust and safety teams, AI product engineers, and platform builders who need their assistant to refuse disallowed requests without damaging user trust. The core job-to-be-done is enforcing a safety policy boundary while preserving the user relationship. Instead of a generic block message that ends the conversation, this prompt produces a refusal that explains the policy boundary clearly, offers a safe alternative when one exists, and avoids moralizing language or over-refusal on adjacent safe requests. The ideal user is an engineer or policy owner embedding this behavior into the system prompt layer of a production assistant where safety policies must be enforced consistently across every user interaction.

Use this prompt when you have a defined safety policy with clear boundaries and you need the model to enforce it with precision. This is appropriate for production assistants in customer support, internal tools, or any user-facing AI where disallowed requests are expected but you want to guide users toward acceptable alternatives. The prompt is designed to be wired into a system-level instruction that sits above user and developer messages in the instruction hierarchy. It should be combined with a content safety classifier or guardrail system that detects policy violations before the model generates a response, allowing the prompt to handle the refusal gracefully rather than relying on the model to detect violations from raw user input alone.

Do not use this prompt when you need a hard block with no explanation, such as in environments where any engagement with a disallowed request is a compliance risk. Do not use it when the safety policy is vague or undefined—this prompt requires concrete policy boundaries to be effective. Avoid using it as a standalone safety layer without upstream detection; the model should receive a clear signal that a violation has occurred, not be expected to perform content moderation from scratch. Finally, do not use this prompt for capability-boundary refusals (e.g., 'I cannot browse the web') or uncertainty disclosures—those require separate, specialized prompts from the fallback and error handling family. The next step after reading this section is to define your specific safety policy categories and map them to the [POLICY_CATEGORY] and [SAFE_ALTERNATIVE] placeholders in the prompt template.

This template encodes a safety refusal policy that balances firm boundary enforcement with user experience. Instead of a blunt rejection that frustrates users, the prompt instructs the model to explain why a request falls outside policy and, critically, to identify a safe, constructive alternative when the user's underlying goal can be served without violating the policy. The template is designed to be inserted into your system prompt or used as a policy instruction block in a larger assistant architecture. It uses square-bracket placeholders so you can adapt the policy domain, risk level, and output constraints to your product.

textCopy
## Safety Refusal Policy

When a user request matches a disallowed category defined in [POLICY_DOMAIN], you must refuse the request. Your refusal must follow this structure:

1. **Policy Boundary Statement**: Clearly state that the request cannot be fulfilled and identify which policy category it falls under. Do not moralize, lecture, or use condescending language.
2. **Safe Alternative (if applicable)**: If the user's underlying goal can be addressed through a safe, policy-compliant alternative, describe that alternative in concrete, actionable terms. If no safe alternative exists, state that explicitly and briefly explain why.
3. **Adjacent Request Invitation**: End with an open-ended offer to help with adjacent, policy-compliant requests in the same domain.

### Disallowed Categories
[DISALLOWED_CATEGORIES]

### Alternative Suggestion Rules
- Suggest alternatives only when they directly address the user's stated or reasonably inferred goal.
- Do not suggest alternatives that are themselves policy violations or that circumvent the policy.
- If the request is ambiguous between a safe and unsafe interpretation, ask a clarifying question before refusing.
- For requests in [HIGH_RISK_CATEGORIES], do not suggest alternatives. Refuse directly and recommend the user consult [ESCALATION_PATH].

### Tone Requirements
- Professional, neutral, and helpful.
- No sarcasm, moral superiority, or shaming.
- Match the user's language and formality level.

### Output Format
Return your refusal as a JSON object with the following schema:
{
  "decision": "refused",
  "policy_category": "string",
  "refusal_message": "string",
  "safe_alternative": "string | null",
  "alternative_is_direct_substitute": boolean
}

### Examples
[FEW_SHOT_EXAMPLES]

### Important
- Do not over-refuse. If a request does not clearly match a disallowed category, proceed normally.
- When in doubt about boundary cases in [AMBIGUITY_CATEGORIES], ask one clarifying question rather than refusing.

Adaptation guidance: Replace [POLICY_DOMAIN] with your specific domain (e.g., "content safety," "financial advice," "medical guidance"). Populate [DISALLOWED_CATEGORIES] with a concrete, testable list of categories and examples. [HIGH_RISK_CATEGORIES] should enumerate categories where alternatives are unsafe to suggest (e.g., self-harm, child safety). [ESCALATION_PATH] should point to a human reviewer, support channel, or external resource. [FEW_SHOT_EXAMPLES] is critical for boundary precision—include at least three examples: one clear refusal with an alternative, one clear refusal without an alternative, and one ambiguous case that triggers a clarifying question. [AMBIGUITY_CATEGORIES] helps prevent over-refusal on edge cases. Test the populated template against a red-team dataset that includes both clearly disallowed requests and adjacent safe requests to measure boundary precision and alternative quality.

This prompt is not a standalone safety solution; it is a structured refusal layer that must be integrated into a broader trust and safety architecture. The prompt template expects a [USER_REQUEST] and a [POLICY_BOUNDARY] definition, and it produces a refusal that explains the boundary, offers a safe alternative when one exists, and avoids moralizing or over-refusal on adjacent safe requests. The implementation harness must enforce that the refusal is only triggered after upstream classification confirms the request violates a defined policy, not as a first-pass filter on all inputs.

Wire the prompt into a decision pipeline: first, classify the user request against your policy taxonomy using a separate classification prompt or rule-based system. If the classification confidence exceeds your threshold for a policy violation, route the request to this refusal prompt. The harness must inject the specific policy name and boundary description into [POLICY_BOUNDARY] from a policy registry, not from the classifier's raw output, to ensure consistent refusal language. Validate the refusal output against a schema that requires three fields: refusal_reason (string), safe_alternative (string or null), and policy_citation (string). If safe_alternative is non-null, run a secondary check to confirm the alternative does not itself violate any policy. Log every refusal with the original request, the triggered policy, the generated refusal, and the safe alternative for audit and policy-tuning purposes.

For high-stakes domains such as healthcare, finance, or child safety, add a human review queue before the refusal is returned to the user. The review interface should display the original request, the classifier's confidence score, the triggered policy, and the generated refusal. Reviewers can approve, edit, or override the refusal. Track override rates per policy to identify policies that need refinement or classifiers that need retraining. For model choice, use a model with strong instruction-following and low refusal-creep; test across multiple model versions to ensure the prompt does not produce over-refusal on safe adjacent requests. Implement a retry with exponential backoff only for transient API errors, not for refusal content issues, and set a max retry of 2 before falling back to a static refusal template stored in your application code. The static fallback must never expose internal policy logic or system prompt details.