User Intent Re-Evaluation Prompt After Refusal

This prompt is designed for safety engineers and product managers who need a structured, auditable method to re-examine a user request that was initially refused by the system. The core job-to-be-done is determining if the refusal was a false positive caused by misinterpretation of the user's intent, rather than a correct enforcement of a safety policy. The ideal user is someone reviewing production refusal logs, tuning safety classifiers, or investigating user escalations. Required context includes the original user request, the model's refusal response, the specific safety policy that was triggered, and any conversation history leading up to the refusal. Without this full context, the re-evaluation cannot reliably distinguish between a legitimate refusal and a misinterpretation.

Deploy this prompt as an offline, asynchronous analysis step—not as a real-time user-facing response. It should be wired into a review queue or an observability pipeline where refused requests are batched for human or automated review. The prompt produces a structured output containing alternative interpretations of the user's intent, confidence scores for each interpretation, and a revised safety assessment. This output should be logged alongside the original refusal for auditability. Implement a mandatory human-review step for any case where the prompt suggests overturning a refusal, especially for high-risk categories like self-harm, child safety, or illegal content. The re-evaluation process must never automatically fulfill a previously refused request without explicit human approval.

Do not use this prompt when the original refusal was triggered by a capability limitation rather than a safety policy. If the model refused because it lacked the tools, knowledge, or context to fulfill the request, intent re-evaluation will not help—you need a capability gap analysis instead. Do not use this prompt for real-time refusal recovery in the same user session; that requires a different prompt design with tighter latency constraints and user-facing tone calibration. Most critically, never use this prompt as a mechanism for intent laundering, where a malicious user can rephrase an unsafe request to bypass safety policies. The prompt includes explicit guardrails against this, but the overall system design must ensure that genuinely unsafe requests remain refused regardless of how they are re-framed. If you observe a pattern of the re-evaluation prompt consistently overturning refusals in a specific category, pause the pipeline and investigate whether the prompt or the underlying safety policy has been compromised.

This prompt template is designed to be dropped into your analysis pipeline immediately after a model refuses a user request. Its job is to force a structured re-examination of the original intent, separating genuine safety violations from misinterpretations, ambiguous phrasing, or overly conservative policy application. The template uses square-bracket placeholders for all dynamic inputs, making it straightforward to wire into an application harness that injects the refused request, the original refusal response, your safety policy, and any relevant conversation context.

textCopy
You are a safety policy analyst reviewing a refused user request. Your task is to re-evaluate the user's original intent and determine whether the refusal was correct or whether the request was misinterpreted.

## INPUTS
[ORIGINAL_USER_REQUEST]
[REFUSAL_RESPONSE]
[SAFETY_POLICY_DOCUMENT]
[CONVERSATION_CONTEXT]

## INSTRUCTIONS
1. Extract the user's explicit stated goal from [ORIGINAL_USER_REQUEST].
2. Generate 2-4 alternative interpretations of what the user might have intended, ranging from the most benign to the most concerning reading.
3. For each interpretation, assign a confidence score (0.0 to 1.0) based on evidence in [CONVERSATION_CONTEXT] and the language used.
4. Map each interpretation against the specific policy clauses in [SAFETY_POLICY_DOCUMENT] that would permit or prohibit it.
5. Identify the single most likely interpretation and produce a revised safety assessment with one of these verdicts:
   - **CORRECT_REFUSAL**: The refusal was appropriate. No recovery needed.
   - **FALSE_POSITIVE**: The request was safe and should have been fulfilled. Provide a corrected response.
   - **AMBIGUOUS**: Intent is genuinely unclear. Provide clarification questions to ask the user.
   - **PARTIAL_FULFILLMENT**: Part of the request is safe. Provide the safe portion and refuse only the unsafe component.
6. If the verdict is FALSE_POSITIVE, AMBIGUOUS, or PARTIAL_FULFILLMENT, produce the corrected output or clarification questions in [OUTPUT_SCHEMA] format.

## CONSTRAINTS
- Do not re-interpret genuinely unsafe requests as safe. Intent laundering is prohibited.
- If the original request explicitly describes harm, illegal activity, or policy violations, the verdict must be CORRECT_REFUSAL.
- Confidence scores must be grounded in specific evidence from [CONVERSATION_CONTEXT], not assumptions.
- If no single interpretation exceeds 0.7 confidence, the verdict must be AMBIGUOUS.

## OUTPUT_SCHEMA
Return a JSON object with this exact structure:
{
  "explicit_goal": "string",
  "interpretations": [
    {
      "reading": "string",
      "confidence": number,
      "evidence": ["string"],
      "policy_clauses": ["string"],
      "would_violate_policy": boolean
    }
  ],
  "selected_interpretation_index": number,
  "verdict": "CORRECT_REFUSAL" | "FALSE_POSITIVE" | "AMBIGUOUS" | "PARTIAL_FULFILLMENT",
  "verdict_rationale": "string",
  "corrected_output": "string | null",
  "clarification_questions": ["string"] | null,
  "safe_portion": "string | null",
  "refused_portion_rationale": "string | null"
}

## RISK_LEVEL
[HIGH] — Incorrect re-evaluation can either weaken genuine safety constraints or perpetuate false refusals that degrade user experience. Human review is required for AMBIGUOUS verdicts and recommended for FALSE_POSITIVE verdicts in production.

To adapt this template, replace the square-bracket placeholders with your application's live data. [ORIGINAL_USER_REQUEST] should contain the exact user message that triggered the refusal. [REFUSAL_RESPONSE] should be the full model response that refused the request. [SAFETY_POLICY_DOCUMENT] should be your organization's safety policy text, not a summary — the model needs specific clauses to cite. [CONVERSATION_CONTEXT] should include prior turns in the conversation, user history if available, and any metadata that helps disambiguate intent. The [OUTPUT_SCHEMA] is already defined inline, but you can replace it with a reference to your own schema registry if you maintain one externally. The [RISK_LEVEL] tag is a signal to your harness about whether to enforce human review gates. For high-risk domains like healthcare, legal, or finance, keep this at HIGH and route AMBIGUOUS and FALSE_POSITIVE verdicts to a review queue before returning anything to the user. Before deploying, run this prompt against a golden dataset of known-correct refusals and known false positives to calibrate your confidence thresholds and verify that the model isn't laundering unsafe requests through the alternative-interpretation mechanism.

The User Intent Re-Evaluation Prompt is designed to sit behind a refusal event, not to replace the initial safety classifier. When your primary policy layer returns a refusal, this prompt acts as a second-pass re-evaluator that examines whether the user's intent was misinterpreted. The harness must treat this as a recovery path, not a bypass. The model that runs this prompt should be the same or a more capable variant of the model that issued the original refusal, and it must receive the full original user request, the refusal response, and the relevant policy text as context. Do not strip context to make the request appear safer—that creates a circumvention vector.

Integration flow: 1) Primary safety check returns a refusal. 2) The harness extracts the refusal reason code, the original user message, and the specific policy clause triggered. 3) The re-evaluation prompt is assembled with [ORIGINAL_REQUEST], [REFUSAL_RESPONSE], [POLICY_TEXT], and [CONVERSATION_CONTEXT] if available. 4) The model returns a structured JSON output containing intent_interpretations, revised_safety_assessment, and recommended_action. 5) The harness validates the JSON schema before acting on it. If recommended_action is fulfill, the harness routes to a separate generation prompt that produces the actual response—never use the re-evaluation output directly as a user-facing message. If recommended_action is still_refuse, log the case and optionally escalate to human review. If recommended_action is clarify, surface targeted clarification questions to the user.

Validation and safety checks: Before acting on a fulfill recommendation, run a lightweight secondary classifier on the re-evaluated intent to confirm it doesn't match known unsafe patterns. This is your intent-laundering guardrail. If the re-evaluation prompt produces confidence below your threshold (we recommend starting at 0.85 for fulfill decisions), escalate to human review rather than auto-fulfilling. Log every re-evaluation decision with the original refusal reason, the re-evaluated intent, the confidence score, and the final action taken. These logs become your audit trail for policy boundary tuning and false-positive rate measurement.

Retry and escalation: This prompt should run exactly once per refusal event. If the output fails JSON schema validation, retry once with a repair instruction appended. If it fails again, escalate to human review with the original request and refusal context intact. Do not loop re-evaluation attempts—each retry increases the risk of the model drifting toward unsafe fulfillment. For high-risk domains (healthcare, legal, finance), require human approval on all fulfill recommendations regardless of confidence score. Wire the human review queue to surface the original refusal, the re-evaluation output, and a diff view of the policy interpretation change.

Model choice and latency: This prompt benefits from models with strong instruction-following and structured output capabilities. The re-evaluation step adds latency to the user experience, so design your UX to show a brief "reviewing your request" state rather than a silent delay. If latency is critical, run the re-evaluation prompt in parallel with a lightweight embedding-based similarity check against known safe request patterns, and only proceed with the full re-evaluation if the similarity check is ambiguous. Cache re-evaluation decisions for identical or near-identical requests to avoid redundant processing, but expire the cache when policy text changes.