User Clarification Request Prompt After Ambiguous Refusal

This prompt is designed for the recovery step immediately after a model has refused a request due to policy ambiguity. Instead of a hard refusal or a full escalation, the model asks the user one or more targeted clarification questions. The goal is to resolve the ambiguity so the system can either safely fulfill the request or provide a justified refusal with a clear policy citation. Use this prompt when your safety classifier or policy guard has flagged a request as borderline, when the refusal reason is unclear to the user, or when the request could be legitimate with additional context.

This prompt belongs in the retry-and-recovery layer of your AI harness, not in the initial system prompt. It assumes a prior refusal event is available in the conversation context. The ideal user is a developer or safety engineer building a production system where over-refusal degrades user experience. The prompt requires the original user request, the model's refusal response, and the specific policy or policies that triggered the refusal as input. It is not suitable for requests that are unambiguously unsafe, where clarification would only teach circumvention, or for systems that lack a mechanism to act on the clarified intent.

Before wiring this into production, define clear boundaries for when clarification is appropriate versus when to escalate directly to a human reviewer. A common failure mode is using this prompt for every refusal, which can frustrate users who receive a clarification request for a request that should have been fulfilled outright. Pair this prompt with a false-positive refusal identification step to ensure you are clarifying genuine ambiguity, not recovering from a misclassification. The next section provides the copy-ready template you can adapt to your policy framework and risk tolerance.

This template is designed to be pasted directly into your application's recovery harness. It instructs the model to analyze an ambiguous request that triggered a refusal, identify the specific information needed to resolve the ambiguity, and generate a set of safe, non-leading clarification questions. The prompt is structured to prevent the model from inadvertently teaching the user how to rephrase the request to circumvent safety policies. Use this when your primary safety classifier or policy prompt has flagged a request as borderline, and you want to recover the interaction by gathering more context instead of terminating the conversation.

codeCopy
SYSTEM: You are a clarification assistant operating within strict safety boundaries. Your job is to ask clarifying questions when a user request is ambiguous and could be interpreted as either safe or unsafe. You must not help the user rephrase their request to bypass safety policies. You must not provide examples of unsafe requests. You must not speculate about what the user might have meant. Your only output is a set of neutral, targeted questions that narrow the ambiguity.

USER REQUEST: [USER_INPUT]

REFUSAL REASON: [REFUSAL_REASON]

AMBIGUITY DESCRIPTION: [AMBIGUITY_DESCRIPTION]

POLICY CONTEXT: [POLICY_CONTEXT]

SAFE INTERPRETATION CRITERIA: [SAFE_INTERPRETATION_CRITERIA]

INSTRUCTIONS:
1. Analyze the user request and identify exactly what information is missing that would resolve the ambiguity.
2. Generate 2-4 clarification questions that are:
   - Neutral and non-leading: Do not suggest a safe or unsafe answer.
   - Specific: Target the exact ambiguity, not the general topic.
   - Bounded: Ask only about the user's intent, not about methods or implementation.
   - Safe: Do not introduce new unsafe concepts or vocabulary.
3. Do not restate the refusal reason in your questions.
4. Do not provide examples of what a safe or unsafe request would look like.
5. Output only the clarification questions, formatted as a numbered list.

OUTPUT FORMAT:
1. [First clarification question]
2. [Second clarification question]
...

To adapt this template, replace the square-bracket placeholders with live data from your application context. The [USER_INPUT] should contain the original user message verbatim. The [REFUSAL_REASON] should be a concise statement from your safety system explaining why the request was flagged. The [AMBIGUITY_DESCRIPTION] is a structured description of what makes the request borderline, such as "The request mentions data extraction but does not specify whether the data is publicly available or behind authentication." The [POLICY_CONTEXT] should include the relevant policy excerpts that define the boundary. The [SAFE_INTERPRETATION_CRITERIA] should specify what conditions would make the request clearly acceptable, such as "The user confirms the data is from a public API with no authentication required." Before deploying, validate that the generated clarification questions pass your safety eval suite, specifically checking that they do not contain circumvention instructions, unsafe vocabulary, or leading language that pushes the user toward a particular answer.

The User Clarification Request Prompt sits at a critical decision point in your application flow: after the model has issued an ambiguous refusal, but before you either escalate to a human or return a dead-end error to the user. The harness must intercept the refusal response, determine whether it falls into a policy gray zone worth clarifying, invoke the clarification prompt, validate that the resulting questions don't teach circumvention, and then present the clarification to the user. This is not a fire-and-forget prompt—it requires a stateful loop that tracks the original request, the refusal reason, the clarification questions asked, and the user's clarified response before re-evaluating safety.

The implementation should follow a classify-then-clarify pattern. First, run a lightweight classifier (or a structured output extraction from the refusal response) to determine the refusal category: over_refusal, policy_gray_zone, capability_boundary, or genuine_safety_refusal. Only route policy_gray_zone cases to the clarification prompt. For the clarification prompt itself, inject the original user request as [ORIGINAL_REQUEST], the model's refusal text as [REFUSAL_RESPONSE], and the relevant policy excerpts as [APPLICABLE_POLICIES]. The output must conform to a strict schema: an array of clarification questions, each with a question_text field, a target_ambiguity field explaining what's being disambiguated, and a safety_guardrail field that explicitly states why this question does not guide the user toward unsafe rephrasing. Validate this schema before surfacing any question to the user. If the output fails schema validation, retry once with a stronger constraint instruction; if it fails again, escalate to human review rather than risking an unvalidated clarification.

Model choice matters here. Use a model with strong instruction-following for the clarification generation step—Claude 3.5 Sonnet or GPT-4o are appropriate. The pre-clarification classifier can use a faster, cheaper model like Claude 3 Haiku or GPT-4o-mini since it's performing a narrow classification task. Log every step: the original request hash, the refusal category, the clarification prompt version, the generated questions, the schema validation result, and whether the questions were surfaced or escalated. This audit trail is essential for safety review and for detecting patterns where the clarification prompt might drift toward inadvertently teaching circumvention. Set a clarification budget—no more than two rounds of clarification per request—to prevent infinite loops where the user and model cycle through progressively rephrased unsafe requests. After the user responds to the clarification, route the clarified request back through your standard safety evaluation pipeline; do not assume the clarification process has resolved the safety concern. If the clarified request still triggers a refusal, escalate to human review with the full conversation history rather than looping again.

For evaluation, build a test harness with known gray-zone cases where clarification is appropriate (e.g., 'How do I access employee records?' from an HR manager versus a random employee) and cases where no clarification should be offered (e.g., requests that are clearly unsafe regardless of context). Measure two key metrics: the clarification appropriateness rate (does the prompt ask clarifying questions only when the ambiguity is genuine and resolvable?) and the circumvention teaching rate (do any generated questions inadvertently suggest unsafe rephrasing?). Run these evals on every prompt version change. If the circumvention teaching rate exceeds zero, block the release. For production monitoring, sample 5% of clarification interactions for human review, focusing on cases where the user's clarified response was ultimately accepted—these are your highest-risk paths for policy boundary erosion.