Assistant Claim Reversal Prompt Template

This prompt is for product teams building AI assistants that must walk back an incorrect statement after a user correction. The job-to-be-done is generating a corrected response that acknowledges the specific error, reverses the exact claim, provides the corrected information, and preserves user trust—all without over-apologizing, deflecting blame, or leaving parts of the original error uncorrected. The ideal user is an AI engineer or conversation designer wiring this into a correction-handling pipeline where the system has already detected that a correction occurred and identified which prior assistant claim needs reversal.

Use this prompt when the assistant has made a factual error, a logical mistake, a misattributed source, or an outdated claim that the user has explicitly or implicitly corrected. It requires the following inputs to be effective: the original assistant claim that was wrong, the user's correction turn, any relevant retrieved evidence or sources, and the desired tone calibration. Do not use this prompt for handling new user requests that merely change topics, for cases where the assistant's confidence remains high and the correction should be escalated for human review, or for situations where the correction invalidates downstream state that requires a separate state-rollback operation. This prompt handles the response generation layer, not the dialogue state management layer.

Before deploying this prompt, ensure your pipeline has already classified the user turn as a correction and extracted the specific claim that needs reversal. Pair this prompt with eval checks for three common failure modes: over-apology that erodes user confidence, incomplete reversal that leaves part of the original error standing, and deflection language that shifts blame to the user or external factors. In high-stakes domains such as healthcare, legal, or financial advice, always route the corrected output through human review before sending it to the user. The next step after implementing this prompt is to wire it into your correction-handling state machine and test it against your regression suite of correction scenarios.

This template is the core instruction set for an assistant that must walk back an incorrect statement. It is designed to be inserted into a larger system prompt or used as a standalone correction-generation step. The prompt forces the model to isolate the exact claim being reversed, preventing the common failure mode where the assistant issues a vague apology without actually correcting the misinformation. Use this template when your detection system has already classified a user turn as a correction and identified the target claim. Do not use it for initial response generation or for handling clarifications that are not corrections.

textCopy
You are an assistant that has just been corrected by a user. Your previous claim was incorrect. Your job is to generate a corrected response that rebuilds user trust.

## Previous Assistant Output
[PREVIOUS_ASSISTANT_OUTPUT]

## User Correction
[USER_CORRECTION_TURN]

## Correction Details
- **Corrected Claim**: [INCORRECT_CLAIM_SPAN]
- **Correction Type**: [CORRECTION_TYPE]
- **Correct Information**: [CORRECTED_INFORMATION]
- **Evidence for Correction**: [CORRECTION_EVIDENCE]

## Response Requirements
1. **Acknowledge the error explicitly.** Reference the specific incorrect claim. Do not use vague language like "I misspoke" without stating what was wrong.
2. **State the corrected information clearly.** Provide the accurate fact, figure, or statement without hedging unless uncertainty genuinely remains.
3. **Preserve uncontested content.** Any part of your previous response not related to the corrected claim should remain intact. Do not over-correct.
4. **Match the user's tone.** If the user is frustrated, be concise and direct. If neutral, be professional. Never be defensive or overly apologetic.
5. **Transition back to the task.** After the correction, return to the user's underlying goal without lingering on the error.

## Tone Calibration
- **Apology Level**: [APOLOGY_LEVEL: minimal | brief | sincere]
- **Formality**: [FORMALITY_LEVEL: casual | professional | formal]

## Constraints
- Do not fabricate new evidence to support the correction.
- Do not deflect blame to the user, the training data, or external factors.
- If [CORRECTED_INFORMATION] is marked as "UNKNOWN," state that you do not have the correct information and offer to find it.
- Do not repeat the incorrect claim in a way that reinforces it. Reference it only to acknowledge the error.

## Output Format
Return only the corrected assistant response as plain text. Do not include meta-commentary, prefixes, or labels.

To adapt this template, start by wiring the placeholders to your correction detection pipeline. [INCORRECT_CLAIM_SPAN] should be the exact substring from [PREVIOUS_ASSISTANT_OUTPUT] that was flagged as wrong. If your detection system cannot isolate the span, add a pre-processing step that extracts it before invoking this prompt. [CORRECTION_TYPE] should map to your classification taxonomy—factual, logical, procedural, or slot-value—so the model can calibrate its response structure. [APOLOGY_LEVEL] and [FORMALITY_LEVEL] should be set by a separate tone adaptation module based on detected user sentiment, not hardcoded. The most dangerous placeholder is [CORRECTED_INFORMATION]. If you populate it with a model-generated guess, you risk compounding the original error. Prefer sourcing this from a verified knowledge base, a re-retrieval step, or a human agent. If the correct information is unknown, set the value to "UNKNOWN" and let the constraint handle the abstention.

Before deploying, test this template against a golden set of correction scenarios that includes explicit corrections ("That's wrong, it's actually X"), implicit corrections ("What about X?" when X contradicts the prior claim), and partial corrections where only one part of a multi-claim response is disputed. Measure whether the output acknowledges the specific error, provides the correct information, preserves uncontested content, and transitions back to the task. Common failure modes include over-apology that derails the conversation, incomplete reversal where the assistant acknowledges the error but repeats the wrong information elsewhere, and deflection where the assistant blames ambiguity in the user's original request. Run these evals with an LLM judge using a rubric that scores acknowledgment accuracy, correction completeness, and tone appropriateness. If the correction involves regulated content, route the generated response to a human review queue before sending it to the user.

The claim reversal prompt is not a standalone chat instruction—it is a recovery module that fires after a correction detection system flags an assistant error. Wire it into your application as a synchronous repair step within the response generation pipeline. When your correction detection prompt (see sibling topic: User Correction Detection Prompt Template) identifies a factual, logical, or procedural error in the assistant's prior output, route the original context, the incorrect claim, and the user's correction into this reversal prompt. The output is a corrected response that replaces the original before it reaches the user, or—if the error was already surfaced—a follow-up correction message. Never call this prompt without first confirming a correction event exists; false-positive reversals for accurate claims destroy trust faster than uncorrected errors.

Validation and retry logic must be strict because reversal failures compound the original mistake. After the prompt returns, validate three things before the response reaches the user: (1) the output explicitly acknowledges the specific error, not a generic apology; (2) the corrected information is factually consistent with the evidence or user-provided correction; (3) the response does not introduce new unsupported claims while reversing the old one. Use a lightweight evaluator prompt or structured output schema with acknowledgment_text, corrected_claim, and unchanged_context fields to make validation programmatic. If validation fails, retry once with the failure reason injected into the prompt's [CONSTRAINTS] block—for example, 'Your previous reversal was too vague. Specify exactly which claim was wrong and what the correct information is.' After two failures, escalate to a human review queue rather than looping indefinitely. Log every reversal attempt with the original claim, the correction trigger, the reversal output, and the validation result for audit and regression testing.

Model choice and latency matter because reversals happen in the critical path of user-facing responses. Use a fast, instruction-following model (GPT-4o, Claude 3.5 Sonnet, or equivalent) rather than a slower reasoning model—the reversal task requires precise execution of a narrow template, not deep deliberation. Set a timeout of 5-8 seconds; if the reversal prompt exceeds this, fall back to a simpler acknowledgment template ('I've noted your correction and will update my response') and queue a full reversal for the next turn. For high-stakes domains like healthcare or finance, always route reversal outputs through a human approval step before they reach the user, regardless of validation scores. The prompt's [RISK_LEVEL] parameter should gate this behavior: set high to enforce human-in-the-loop, medium to require validation-only gating, and low for fully automated reversals in non-critical contexts. Wire this gating into your application's policy engine, not into the prompt itself—the model should not decide whether human review is needed.

State synchronization is the most common production failure mode for reversal prompts. After a successful reversal, you must update all downstream state that depended on the incorrect claim: dialogue slot values, retrieved context caches, pending tool call arguments, and session summaries. Use the sibling State Rollback After Correction Prompt to identify affected state keys, then apply those rollbacks atomically. If your application maintains a canonical session state object, the reversal handler should emit a state_rollback_event that downstream consumers can subscribe to. Without this synchronization, the assistant will contradict itself again in the next turn because stale state persists. Test this explicitly in your integration suite: inject a correction, verify the reversal response, then query the session state to confirm no incorrect values remain. This is the difference between a graceful recovery and a correction cascade.