Refusal with Safe Alternative Suggestion Prompt Template

This prompt is for product teams who need their AI system to refuse a disallowed request without creating a dead end. The job-to-be-done is a refusal that redirects the user toward a constructive, policy-compliant action instead of leaving them with a flat 'I can't help with that.' The ideal user is a product engineer, trust-and-safety developer, or support automation builder who already has a policy boundary defined and needs the refusal to preserve user trust and reduce support tickets. Required context includes the original user request, the specific policy clause that was violated, and a catalog of safe, in-scope alternatives the system can actually perform.

Do not use this prompt when the request is malicious, adversarial, or part of a jailbreak attempt. In those cases, a neutral refusal with no engagement and silent logging is safer than offering alternatives that could be probed for further exploitation. This prompt is also inappropriate when the system lacks a clear catalog of safe alternatives—offering vague or ungrounded suggestions will increase user frustration. If the refusal requires a legal disclaimer or falls into a regulated domain such as medical or financial advice, pair this prompt with a regulated-domain disclaimer template and always route the final output through human review before it reaches the user.

Before implementing, define the evaluation criteria: the suggested alternative must be genuinely policy-compliant, relevant to the user's stated need, and something the system can actually fulfill. A common failure mode is suggesting an alternative that is technically safe but useless to the user, which degrades trust faster than a simple refusal. Wire this prompt into a harness that validates the alternative against your allowed-action catalog before returning it, and log every refusal-with-alternative event to monitor whether users accept the redirection or escalate to support.

This template is the core instruction set for redirecting a disallowed user request toward a constructive outcome. It is designed to be copied directly into your prompt management system or orchestration layer. The prompt instructs the model to first classify the violation against your specific policy, then generate a clear refusal, and finally propose one or more alternative requests that are both safe and genuinely useful. The square-bracket placeholders must be replaced with your actual policy text, risk context, and output formatting requirements before use.

codeCopy
SYSTEM:
You are a safety-focused assistant operating under a strict usage policy. Your goal is to refuse disallowed requests while preserving user trust by offering constructive, policy-compliant alternatives.

When you receive a user request that violates the policy below, you must:
1. Identify the specific policy clause(s) violated.
2. Generate a refusal message that is clear, calm, and does not repeat the harmful content.
3. Propose [NUMBER] safe alternative request(s) that are related to the user's apparent underlying goal but fully compliant with the policy.

## POLICY
[POLICY_TEXT]

## RISK CONTEXT
Current risk level: [RISK_LEVEL]
User segment: [USER_SEGMENT]

## OUTPUT FORMAT
Return a single JSON object with this exact schema:
{
  "violated_policies": ["string"],
  "refusal_message": "string",
  "safe_alternatives": [
    {
      "alternative_request": "string",
      "relevance_rationale": "string"
    }
  ]
}

## CONSTRAINTS
- Do not generate, summarize, or repeat the disallowed content in any field.
- Each safe alternative must be a fully-formed request the user could submit immediately.
- The relevance_rationale must explain how the alternative addresses the user's likely intent without violating policy.
- If no safe alternative exists that is genuinely useful, return an empty array for safe_alternatives and explain this in the refusal_message.
- Maintain a [TONE] tone throughout.

USER:
[USER_REQUEST]

To adapt this template, start by replacing [POLICY_TEXT] with your actual content policy, formatted as a numbered or bulleted list of clauses. The [RISK_LEVEL] and [USER_SEGMENT] variables should be injected by your application harness based on upstream classification or session context. Set [TONE] to a value like "professional and helpful" or "empathetic but firm" to match your product voice. The [NUMBER] placeholder controls how many alternatives the model should attempt to generate; start with 2 and adjust based on latency and relevance testing. The output schema is designed for programmatic consumption: your application can parse the JSON, render the refusal_message to the user, and present the safe_alternatives as clickable follow-up suggestions. If your application cannot render structured suggestions, modify the output format to plain text with a delimiter between the refusal and the alternatives list.

This prompt template is not a standalone safety solution. It must be embedded in a pipeline that validates the output, logs the decision, and escalates when the model fails to produce a safe, well-formed alternative. The primary risks in production are: the model suggests an alternative that is itself unsafe, the alternative is irrelevant to the user's intent, or the refusal message leaks information about internal policy thresholds. The harness described here addresses each of these failure modes before the response reaches the user.

Validation and Safety Gating. Before any response is returned, run the suggested alternative through a secondary safety classifier or keyword blocklist. The classifier should check whether the suggested alternative falls into the same disallowed category as the original request. For example, if the user requested instructions for a malicious activity and the model suggests a 'safer' alternative that still enables harm, the entire response must be discarded and escalated. Implement a structured output schema that separates the refusal text from the alternative suggestion array so each alternative can be individually scored. If any alternative scores above your risk threshold, replace the response with a generic refusal and log the incident.

Logging and Observability. Log every refusal event with the original request hash, the policy trigger, the model version, the generated alternatives, and the safety scores assigned to each alternative. This log becomes your audit trail for policy compliance and your dataset for improving the prompt over time. Attach a session risk score to each event so you can detect users who repeatedly probe refusal boundaries. If the session risk score crosses a configured threshold, switch from automated refusal-with-alternative to a hard refusal with no alternatives and flag the session for human review.

Human Review and Feedback Loop. For high-severity policy categories or ambiguous requests, route the refusal and suggested alternatives to a review queue before the user sees them. A human reviewer should confirm that the alternatives are genuinely safe and relevant. Capture the reviewer's decision and use it to build a preference dataset for fine-tuning or prompt improvement. If the model consistently suggests alternatives that reviewers reject, the prompt's [EXAMPLES] and [CONSTRAINTS] sections need updating. Avoid routing every refusal to review—this creates unsustainable queue volume. Gate review on risk score, policy category severity, and model confidence.

Model Choice and Retries. This prompt works best with models that have strong instruction-following and safety alignment. If you use a smaller or less aligned model, expect higher rates of unsafe alternative suggestions. Implement a retry layer: if the first generation produces an alternative that fails safety validation, retry with a stricter [CONSTRAINTS] block that explicitly forbids the unsafe alternative category. After two failed retries, fall back to a hard refusal with no alternatives and log the failure for analysis. Do not retry indefinitely—each retry adds latency and cost while the user waits.