Correction Acknowledgment Response Prompt Template

This prompt serves a single, narrow purpose: generating the user-facing message that confirms a correction was understood and applied. It is designed for assistant product teams who have already built detection, classification, and state rollback logic and now need a reliable, testable way to communicate the update to the user. The ideal user is a dialogue manager or response generation module that has already received a structured correction event—containing the original claim, the user's correction, and the corrected information—and needs to produce a concise acknowledgment before resuming the main conversation flow. This is not a prompt for figuring out if a correction happened or what to change; it assumes those decisions are complete and focuses entirely on the communication layer.

Use this prompt when the system has definitively reversed a prior claim and needs to tell the user. The required inputs are the original assistant statement that was wrong, a summary of the user's correction, and the verified correct information. The output is a short, declarative acknowledgment that states what changed without excessive apology ('I apologize for the confusion' is acceptable once; a paragraph of groveling is not), defensiveness ('I was only trying to...'), or ambiguity ('The information may have been updated'). The prompt is also appropriate when you need to maintain a consistent brand voice during error recovery, as it includes tone calibration controls. Do not use this prompt for detecting corrections, classifying their intent, rolling back database state, re-running tool calls, or deciding whether the user is actually correct—those are separate, upstream responsibilities covered by sibling playbooks like User Correction Detection and State Rollback After Correction.

Before wiring this prompt into your application, ensure you have a clear contract for the structured correction event that feeds it. The prompt will fail gracefully if given vague input, but it will fail loudly and obviously if given no input or contradictory input (e.g., a correction that doesn't actually reverse the original claim). The next step after implementing this acknowledgment is to build the eval harness described in the 'Testing & Evaluation' section, which checks for acknowledgment accuracy, brevity, and tone appropriateness. Avoid the common failure mode of using this prompt as a catch-all error handler; it is specifically for acknowledged and applied corrections, not for generic 'something went wrong' messages.

This template produces a correction acknowledgment response that confirms the assistant understood the user's correction, states what changed without excessive apology or defensiveness, and returns the conversation to productive task flow. The prompt is designed to be pasted directly into your prompt layer with square-bracket placeholders replaced by your application's runtime values. It works across tone variants—neutral, empathetic, and direct—and includes structural constraints that prevent common failure modes like over-apology, incomplete acknowledgment, or failure to transition back to the task.

textCopy
You are generating a correction acknowledgment response for an assistant that made an error and has been corrected by the user.

[CONSTRAINTS]
- Acknowledge the correction explicitly and confirm you understood what the user corrected.
- State what changed: identify the specific claim, value, or action that was incorrect and what the corrected understanding is.
- Do not over-apologize. One brief acknowledgment of the error is sufficient. Avoid defensive language, excuses, or excessive justification.
- Transition back to the task flow immediately after the acknowledgment. Do not dwell on the error.
- Match the tone specified in [TONE].
- Keep the response concise. Target [MAX_LENGTH] words or fewer.
- Do not introduce new information, claims, or actions beyond the correction acknowledgment and task resumption.

[INPUT]
Original assistant claim that was corrected: [ORIGINAL_CLAIM]
User's correction message: [USER_CORRECTION]
Current task context and progress: [TASK_CONTEXT]

[TONE]
[TONE_SELECTION]

[OUTPUT_SCHEMA]
Return a JSON object with these fields:
- "acknowledgment": string confirming the correction was understood
- "change_statement": string describing what changed from incorrect to correct
- "task_resumption": string transitioning back to the task flow
- "full_response": string combining all three components into the final assistant message

[EXAMPLES]
Example 1 (Neutral tone):
User correction: "No, the deadline is Friday, not Thursday."
Original claim: "The deadline is Thursday."
Response: "You're right, the deadline is Friday, not Thursday. Let me update that. Continuing with the project plan for a Friday deadline..."

Example 2 (Empathetic tone):
User correction: "That's not what I asked. I need the Q3 numbers, not Q2."
Original claim: Assistant provided Q2 financial data.
Response: "I apologize for pulling the wrong quarter. Let me get the Q3 numbers instead. Here's what I found for Q3..."

[RISK_LEVEL]
[RISK_LEVEL]

Adapting the template: Replace [ORIGINAL_CLAIM] with the specific assistant statement or output that the user is correcting. [USER_CORRECTION] should contain the user's exact correction message. [TASK_CONTEXT] needs enough context about the current task state so the assistant can resume coherently—include the last few turns, active goals, and any pending actions. [TONE_SELECTION] should be one of neutral, empathetic, or direct, with corresponding instructions for each variant. [MAX_LENGTH] controls verbosity; start with 150 words and adjust based on your application's UX requirements. [RISK_LEVEL] should be low, medium, or high—for high-risk corrections (financial, medical, legal), add an instruction to recommend human verification before acting on the corrected information. The [OUTPUT_SCHEMA] provides structured fields for logging and audit; if you only need the final message, extract full_response. For production, validate that change_statement actually differs from [ORIGINAL_CLAIM] and that task_resumption connects to [TASK_CONTEXT] without introducing new errors.

The Correction Acknowledgment Response prompt is designed to sit inside a dialogue management pipeline, triggered immediately after a User Correction Detection and Correction Intent Classification step confirms that the user has pushed back on a prior assistant claim. It should not be called in isolation; the upstream detection step must provide the [CORRECTION_TYPE], [ORIGINAL_CLAIM], and [CORRECTED_FACT] fields so the acknowledgment prompt can reference the specific error without hallucinating what went wrong. The prompt's job is narrow: produce a concise acknowledgment that confirms understanding, states what changed, and transitions back to the task flow. It is not responsible for re-executing tool calls, re-retrieving evidence, or rolling back state—those actions belong to separate prompts in the correction repair pipeline.

Wire this prompt into your application as a synchronous post-correction step with the following harness: (1) Input validation: before calling the model, assert that [CORRECTION_TYPE] is a non-empty string matching one of your defined correction categories (factual, logical, procedural, format, slot-value, intent-misclassification). Reject calls where [ORIGINAL_CLAIM] and [CORRECTED_FACT] are identical or where [CONVERSATION_CONTEXT] is missing the turn where the error occurred. (2) Model selection: use a fast, instruction-following model for this task (GPT-4o-mini, Claude Haiku, or equivalent). The acknowledgment is a low-complexity generation task that benefits from low latency; a larger model adds cost without meaningful quality improvement. (3) Output validation: parse the response and check that it contains an explicit reference to the corrected claim, does not exceed 3 sentences, and does not include phrases like 'I apologize for the confusion' more than once. Use a regex or lightweight LLM-as-judge check to flag over-apology, defensiveness ('I was actually correct because...'), or failure to state the corrected fact. (4) Retry logic: if validation fails, retry once with the same prompt but append the validation failure reason as a [CONSTRAINTS] update. If the second attempt fails, fall back to a canned acknowledgment template to avoid blocking the user.

For high-stakes domains (healthcare, legal, finance), insert a human review gate before the acknowledgment is shown to the user. Route any correction where [RISK_LEVEL] is 'high' or where the [CORRECTED_FACT] contradicts a source document to a review queue. The reviewer should confirm that the correction is accurate and that the acknowledgment does not introduce new errors. Log every correction event—including the original claim, user correction turn, detection confidence, acknowledgment generated, and whether human review was triggered—to your observability pipeline with a correlation ID that ties back to the session. Monitor acknowledgment brevity (target: under 60 tokens), over-apology rate (target: under 5% of corrections), and correction loop exits (if a user corrects the same claim more than twice, escalate to a human agent rather than regenerating another acknowledgment).