Safe Alternative Omission Counterexample Prompt

This prompt is for safety engineers and product teams who need an AI system to refuse disallowed requests while still offering constructive, safe alternatives. The core problem it solves is a common production failure mode: models often learn to refuse correctly but fail to provide redirection, leaving users blocked without a path forward. This playbook uses negative counterexamples that demonstrate refusal without alternatives, teaching the model that omission of a safe path is itself a failure mode. Use this when your refusal policy requires the model to actively suggest what the user can do instead, not just what they cannot do.

Deploy this prompt when you are building a user-facing assistant, a customer support bot, or any interactive system where a hard 'I can't do that' creates a dead end. It is particularly valuable in regulated or high-trust domains like healthcare, finance, or legal tech, where a refusal must be accompanied by a compliant alternative (e.g., 'I can't provide a diagnosis, but I can help you find a provider or summarize your symptoms for a doctor'). The prompt is designed to be wired into a production harness where the 'alternative suggestion rate' is a key evaluation metric, tracked alongside standard safety metrics like refusal precision and recall. You should integrate this with a logging system that captures not just the final output, but also whether an alternative was offered, allowing you to alert on spikes in unhelpful refusals.

Do not use this prompt for open-ended creative tasks where refusal is rare, or for systems where a hard stop with no alternative is the intended product behavior, such as a low-level API guardrail that should simply return an error code. Avoid using it in non-interactive batch processing pipelines where there is no user to receive a redirection. Before shipping, always run this prompt against a golden dataset of boundary requests to ensure the model isn't over-offering alternatives for clearly malicious prompts, which can be a form of safety-washing. The next section provides the exact prompt template you can adapt and integrate into your application.

This prompt template is designed for safety engineers who need the model to refuse unsafe requests while always offering a constructive, safe alternative. The core problem it solves is the 'silent refusal' failure mode, where a model correctly identifies a disallowed request but fails to redirect the user, leaving them frustrated and more likely to attempt prompt injection or rephrase the unsafe request. The template uses few-shot counterexamples that demonstrate refusal responses which omit alternatives, paired with corrected versions that include them. This teaches the model that refusal without redirection is an incomplete response. Use this when building safety layers for user-facing assistants, content generation APIs, or any system where refusal must preserve user trust and provide a path forward.

textCopy
You are a safety-aware assistant. Your task is to evaluate user requests and respond appropriately.

When a request is unsafe, disallowed, or outside your policy boundaries, you must:
1. Clearly state that you cannot fulfill the request.
2. Briefly explain why (one sentence).
3. Offer at least one constructive, safe alternative that addresses the user's underlying need.

Never refuse a request without providing a safe alternative. A refusal without an alternative is an incomplete response.

Below are examples of INCORRECT refusals (missing alternatives) and CORRECT refusals (with alternatives).

[EXAMPLES]

User Request: [USER_REQUEST]

Evaluate the request against the following safety policy:
[SAFETY_POLICY]

If the request is safe, respond helpfully. If unsafe, refuse with a safe alternative following the pattern above.

Your response:

To adapt this template, replace [EXAMPLES] with 3-5 pairs of incorrect and correct refusal responses tailored to your domain. Each pair should show a refusal that omits alternatives followed by the corrected version. For [SAFETY_POLICY], insert your specific policy document or a condensed list of prohibited categories. For [USER_REQUEST], this is the runtime input from your application. In production, validate that the model's output contains an alternative suggestion when a refusal is detected. Use a secondary check: if the output contains refusal language (e.g., 'I cannot', 'I'm unable to') but no alternative indicator (e.g., 'Instead', 'You could', 'Consider'), flag it for human review or automatic retry. For high-risk domains like healthcare or finance, always route refused requests with missing alternatives to a human reviewer before returning them to users.

This prompt is designed to sit inside a safety guardrail layer that intercepts model responses before they reach the user. When a primary assistant or agent generates a refusal, this prompt evaluates whether the refusal includes a constructive safe alternative. The harness should call this prompt as a secondary classification and repair step—never as the primary response generator—because its job is to detect omissions and rewrite refusals, not to handle the original user request. Wire it into an existing safety pipeline after the initial refusal is generated but before the response is returned to the user. The ideal deployment model is a post-generation safety filter that runs on every refusal-flagged response, with a latency budget of under 500ms for real-time chat applications.

Validation and repair loop: Parse the model's output as JSON using the schema {"has_safe_alternative": boolean, "safe_alternative": string|null, "original_refusal": string, "rewritten_refusal": string|null}. If has_safe_alternative is false and rewritten_refusal is not null, validate that the rewritten refusal contains a concrete, actionable alternative that does not enable the unsafe request. Run a secondary check: does the rewritten refusal mention a specific safe action, resource, or redirect? If not, reject the rewrite and escalate to a human reviewer. Retry logic: If the model returns malformed JSON or missing required fields, retry once with a stricter prompt variant that includes the parsing error message. After two failures, log the incident and fall back to a static safe refusal template. Model choice: Use a fast, instruction-tuned model (e.g., GPT-4o-mini, Claude 3.5 Haiku) for this task because it is a narrow classification and rewrite job that benefits from low latency and consistent JSON output. Avoid using the same model instance that generated the original refusal to prevent correlated failures.

Logging and observability: Log every invocation with the original refusal text, the has_safe_alternative boolean, the rewritten refusal if generated, and the final response shown to the user. Tag refusals that were rewritten with a safety_rewrite label in your observability platform. Track the alternative suggestion rate—the percentage of refusals where has_safe_alternative was false and a rewrite was successfully applied. A sudden drop in this rate may indicate prompt drift or a model behavior change. Human review triggers: Escalate to human review when: (a) the rewrite loop fails twice, (b) the rewritten alternative appears to enable the unsafe request (run a secondary safety classifier), or (c) the original refusal was for a high-severity safety category (e.g., self-harm, child safety). For high-risk domains, always require human approval before deploying rewritten refusals to users. What to avoid: Do not use this prompt to generate the initial response to the user. Do not skip the secondary safety check on rewritten alternatives. Do not deploy without logging—this is a safety-critical component where audit trails are non-negotiable.