User Correction Override Prompt Template

This prompt template is designed for one specific job: handling explicit user corrections during multi-turn conversations. The trigger is unambiguous—a user directly contradicts a prior assistant statement, points out a factual error, or demands a correction. When this happens, the assistant's credibility is on the line. A weak or evasive response erodes trust permanently. An over-apologetic response signals incompetence. The correct response requires three things: validating the user's correction without groveling, identifying exactly which prior claims or decisions must be rolled back, and producing an updated response that incorporates the correction without repeating or dwelling on the original error. This prompt produces all three as structured output, making it suitable for production chat assistants, copilots, and support bots where correction handling directly determines whether users continue the conversation or abandon the system.

The ideal deployment context is a stateful assistant that maintains session history and can act on a rollback plan. The prompt expects access to the conversation history containing the error, the user's correction message, and any relevant session state that might be affected by the rollback. It works best when the assistant has a clear mechanism for updating its internal state—whether that's a slot-filling dialogue manager, a RAG session context, or a planning agent's task list. Without state-update capability, the rollback plan becomes documentation rather than action, and the assistant will repeat the same error in subsequent turns. This prompt is not a general-purpose correction handler. It assumes the user is correct. If the user might be mistaken, use the sibling prompt for correction with confidence scoring instead.

Do not use this prompt for ambiguous user feedback, implicit dissatisfaction signals, or policy violations. A user saying 'that doesn't seem right' without specifying the error requires a clarification prompt, not a correction override. A user expressing frustration without pointing to a specific claim requires sentiment handling, not state rollback. A user demanding the assistant violate its safety policies requires a refusal template, not an acknowledgment and update. Using this prompt in those scenarios will produce inappropriate acknowledgments that validate incorrect user assumptions or dangerous requests. The prompt also assumes the correction is contained—if a single correction could cascade through multiple dependent decisions, pair this prompt with the User Correction Cascade Prevention Prompt to scope the rollback correctly. For high-stakes domains like healthcare, finance, or legal, always route the updated response through human review before it reaches the user, regardless of how confident the correction handling appears.

This template is designed for assistant product teams that need a reliable way to process user corrections during a conversation. When a user explicitly points out an error in the assistant's previous response, the system must acknowledge the correction, identify what went wrong, roll back affected state, and produce a corrected response without over-apologizing or triggering cascading changes to unrelated context. The template uses square-bracket placeholders that you replace with actual values before sending to the model. Each placeholder maps to a specific input your application must supply.

textCopy
SYSTEM: You are an assistant that handles user corrections carefully. When a user corrects a previous response, you must:
1. Acknowledge the correction briefly without over-apologizing.
2. Identify the specific error from the prior turn.
3. Determine which session state elements are affected by the correction.
4. Produce a corrected response that addresses the user's actual intent.
5. Confirm which parts of the prior context remain unchanged.

Do not repeat the incorrect statement unless the user asks for it. Do not over-correct by changing unrelated facts or decisions. If the correction is ambiguous, ask one clarifying question before proceeding.

---

USER: [CONVERSATION_HISTORY]

The user has just sent this correction: "[USER_CORRECTION]"

Your previous response that the user is correcting was: "[PREVIOUS_RESPONSE]"

Current session state before the correction: [SESSION_STATE]

Active constraints that must still be respected: [CONSTRAINTS]

---

Produce a JSON response with this schema:
{
  "acknowledgment": "Brief acknowledgment of the correction",
  "error_identified": "Specific error from the prior turn",
  "affected_state_elements": ["list of state keys that need updating"],
  "unchanged_state_elements": ["list of state keys that remain valid"],
  "corrected_response": "The corrected assistant response to the user",
  "clarification_needed": false,
  "clarification_question": null
}

If the correction is ambiguous, set clarification_needed to true and provide a targeted clarification question. Do not guess.

To adapt this template, replace each placeholder with data from your application. [CONVERSATION_HISTORY] should include the last N turns formatted consistently with your chat structure. [USER_CORRECTION] is the raw text of the user's correction message. [PREVIOUS_RESPONSE] is the exact assistant response being corrected, which helps the model identify the error without scanning the full history. [SESSION_STATE] should be a structured representation of tracked slots, intents, or facts your application maintains. [CONSTRAINTS] includes any system policies, tone rules, or output requirements that must survive the correction. Before deploying, validate that the output JSON parses correctly and that affected_state_elements references keys that actually exist in your state model. For high-stakes domains, route corrections that touch safety-critical state to human review before applying the state rollback.

The User Correction Override prompt template is not a standalone artifact—it is a stateful component that must be integrated into a conversation management loop. When a user issues a correction (e.g., "No, I said the Q3 report, not Q2"), the application must detect the correction intent, extract the corrected value, call this prompt to generate an acknowledgment and state rollback plan, apply the state changes, and regenerate the response that was invalidated. This section covers the implementation harness: routing, validation, retry logic, state reconciliation, and observability hooks that turn the prompt into a reliable production workflow.

Routing and invocation trigger. The prompt should fire only when the system has high confidence that the user is issuing a correction, not a clarification or new instruction. Implement a lightweight classification step before invocation: check for explicit correction markers ("no, I meant," "that's wrong," "change that to"), contrastive stress on a specific entity, or direct contradiction of a prior assistant claim. If confidence is below a threshold (suggested: 0.85), route to a clarification prompt instead. The correction prompt expects [CURRENT_STATE] (the assistant's last response and the facts it relied on), [USER_CORRECTION] (the raw correction utterance), and [SESSION_CONTEXT] (the last N turns for reference resolution). Assemble these from your conversation state store before calling the model.

Output validation and state application. The prompt produces a structured output containing acknowledgment, correction_scope (which state fields are affected), rollback_plan (ordered list of state changes), and updated_response. Validate this output before applying any state changes: confirm that correction_scope references real state fields, that rollback_plan does not touch fields outside the declared scope, and that updated_response does not repeat the original error. If validation fails, retry once with the validation errors appended to [CONSTRAINTS]. If the second attempt also fails, escalate to a human review queue rather than silently applying a corrupted state update. For high-stakes domains (healthcare, finance, legal), always require human approval before applying state changes from a correction override.

Retry and loop prevention. Correction cascades are the primary failure mode: a user corrects one fact, the assistant over-corrects and changes unrelated state, the user corrects the over-correction, and the loop continues. Implement a correction depth counter per session. After two corrections on the same topic within three turns, stop auto-applying corrections and surface a structured summary to the user: "I want to make sure I have this right before continuing. Here's what I've updated..." This breaks the cascade and shifts to explicit confirmation. Log every correction event with correction_id, session_id, trigger_utterance, scope, validation_result, and human_review_required flag for later audit and prompt improvement.

Model choice and latency budget. Correction handling is latency-sensitive—users who correct the assistant are already experiencing friction, and slow correction acknowledgment compounds frustration. Use a fast model (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned small model) for the correction prompt. Reserve larger models for the regenerated response if domain complexity demands it. The acknowledgment and rollback plan can be generated by a smaller model; the updated response may benefit from a more capable model if the original task is complex. Cache the pre-correction state so you can diff the rollback plan against it and verify that only intended fields changed. Wire the correction prompt into your observability pipeline: emit metrics on correction frequency, validation failure rate, retry rate, and cascade incidents per session. These metrics will tell you whether your correction handling is reducing user frustration or creating new failure modes.