Policy Misinterpretation Self-Correction Prompt

This prompt is for safety engineers and product managers who need to recover from a model that misapplied a safety policy to a legitimate request. The model refused or blocked a request that should have been allowed under the intended policy boundaries. This playbook provides a self-correction instruction that identifies the misinterpretation, cites the correct policy interpretation, and regenerates the response. It also produces an audit trail for policy improvement. Use this when you have a clear policy document and a specific request that was incorrectly refused.

Do not use this for requests that were correctly refused under policy but need a tone adjustment; use the Overly Conservative Refusal Rewrite Prompt for that case. This prompt assumes you have access to the original request, the refusal response, and the relevant policy text. Before deploying, validate that the corrected response does not weaken genuine safety constraints by running it through your standard safety eval suite. For ambiguous cases where the policy itself is unclear, prefer the Ambiguous Safety Boundary Resolution Prompt instead.

After using this prompt, log the misinterpretation pattern for policy improvement. If the same policy section generates repeated false refusals, the policy language likely needs clarification. Feed these patterns into the Safety Policy Gap Detection Prompt to systematically improve your policy documents.

This template is designed to be injected immediately after a model has misapplied a safety policy to a legitimate request. Instead of asking the model to simply 'try again,' it forces a structured self-correction loop. The model must first identify the specific misinterpretation, then cite the correct policy interpretation, and only then regenerate the response. This creates an audit trail that safety engineers can use to improve policy language and reduce future false refusals.

textCopy
You previously refused the following request by misapplying a safety policy. Your task is to self-correct.

[ORIGINAL_USER_REQUEST]
[REQUEST]

[YOUR_PREVIOUS_REFUSAL_RESPONSE]
[REFUSAL]

[RELEVANT_POLICY_DOCUMENT]
[POLICY]

Perform the following steps in order:

1. MISINTERPRETATION ANALYSIS
Identify the exact policy clause you applied incorrectly. Explain why the original request does not violate this clause. Quote the specific text from the policy document that you misinterpreted.

2. CORRECT POLICY INTERPRETATION
State the correct interpretation of the policy clause for this request. If the request falls into an explicitly permitted category, cite that permission. If the policy is silent on this case, state that explicitly and default to fulfilling the request while noting the policy gap.

3. REGENERATED RESPONSE
Provide a new response that fulfills the original request. Do not include unnecessary safety disclaimers unless the policy explicitly requires them for this category of request. If the request can only be partially fulfilled, clearly separate the fulfilled portion from any remaining boundary concerns.

[OUTPUT_FORMAT]
Return your response as a JSON object with the following schema:
{
  "misinterpretation_analysis": "string (detailed explanation with policy quotes)",
  "correct_interpretation": "string (correct policy application)",
  "regenerated_response": "string (the corrected response to the user)",
  "policy_gap_flag": boolean (true if the policy was silent or ambiguous on this case)
}

[CONSTRAINTS]
- Do not repeat the original refusal or apologize excessively. A brief acknowledgment is acceptable.
- If the policy document does not contain a clause that actually prohibits the request, you must state that the refusal was unfounded.
- If you are uncertain about the policy interpretation after re-analysis, set policy_gap_flag to true and fulfill the request while noting the ambiguity for human review.

Adaptation guidance: Replace [REQUEST] with the original user input that was refused. Replace [REFUSAL] with the full text of the model's refusal response. Replace [POLICY] with the relevant section of your safety policy document—include enough context that the model can quote specific clauses. The [OUTPUT_FORMAT] block enforces structured JSON output, which is critical for logging and audit trails. If your application cannot parse JSON from the model, replace this block with a plain-text format specification. The policy_gap_flag field is essential for safety teams: it surfaces cases where the policy itself is ambiguous, enabling continuous policy improvement. For high-stakes domains, route any response where policy_gap_flag is true to a human reviewer before returning the regenerated response to the user.

This prompt is designed to be invoked after a primary model response has been flagged as a potential policy misinterpretation—either by an automated classifier, a user appeal, or a downstream validation check. It is not a standalone chat prompt; it is a correction step inside a larger harness. The harness must supply the original user request, the model's refused or misapplied response, the relevant policy text, and any clarifying context that was available at decision time. Without these inputs, the self-correction prompt cannot produce a reliable audit trail or a trustworthy corrected response.

Integration flow: 1) The primary model generates a response. 2) A policy_misinterpretation_detector (which can be a separate classifier prompt, a keyword heuristic, or a user-reported flag) identifies a potential false positive. 3) The harness assembles the correction payload: [ORIGINAL_REQUEST], [MODEL_RESPONSE], [POLICY_TEXT], and [CONTEXT]. 4) The self-correction prompt runs and returns a structured JSON object with misinterpretation_identified, correct_policy_interpretation, corrected_response, and audit_trail. 5) The harness validates the output schema and checks that misinterpretation_identified is true before replacing the original response. If misinterpretation_identified is false, the original refusal stands and the case is logged for policy review.

Validation and safety gates: Before the corrected response reaches the user, the harness must run at least two checks. First, a schema validator confirms the JSON structure is complete and all required fields are present. Second, a safety regression check compares the corrected response against the original policy boundaries to ensure the correction hasn't introduced a genuine safety violation. This can be implemented as a separate classifier prompt that scores the corrected response against the policy text. If the safety score drops below a configured threshold, the correction is blocked and the case is escalated for human review. Never ship a self-corrected response without this regression gate.

Retry and escalation logic: If the self-correction prompt produces invalid JSON, set a retry with the error message injected into [PREVIOUS_ERROR]. Limit retries to 2 attempts. If both fail, log the failure, surface the original refusal to the user with a note that the decision is under review, and create an escalation ticket. For high-risk domains (healthcare, legal, finance), all self-corrections should route to a human review queue by default unless the system has been explicitly configured for automated correction with audited safety thresholds. The audit_trail field in the output should be written to an immutable log alongside the original request, the original response, and the corrected response for downstream policy improvement analysis.

Model selection: This prompt benefits from models with strong instruction-following and nuanced reasoning. GPT-4, Claude 3.5 Sonnet, and Gemini 1.5 Pro are suitable. Avoid smaller or faster models for this correction step unless you've validated their ability to distinguish policy misinterpretation from genuine safety violations on your specific policy set. The cost of a false correction (weakening a real safety boundary) is far higher than the latency cost of a more capable model. If latency is critical, run the detector on a fast model and reserve the correction step for a more capable model only when a misinterpretation is flagged.

Observability: Log every invocation with: request_id, original_response_id, misinterpretation_detected, correction_applied, safety_regression_score, human_review_required, and escalation_created. These fields enable you to measure your false-positive rate over time, identify policy sections that generate the most misinterpretations, and track whether self-corrections are actually improving user experience without introducing safety regressions. If your correction rate exceeds 5% of total refusals, prioritize a policy rewrite rather than relying on self-correction as a permanent fix.