Correction and Recovery System Prompt

This playbook is for engineering and product teams building conversational AI, RAG, or agent systems where the model will inevitably produce incorrect information, make a bad tool call, or misinterpret user intent. The Correction and Recovery System Prompt defines a behavioral contract for how the assistant must acknowledge the error, retract the incorrect output, apologize proportionally, and re-establish conversational trust without derailing the user's task. Use this when your AI product faces real users and mistakes carry reputational or operational risk.

This prompt is not a standalone fix for hallucination or poor grounding. It must be paired with application-layer controls: retrieval-augmented generation (RAG) for factual grounding, output validators to catch malformed responses, and confidence thresholds that trigger human review for high-stakes claims. The prompt assumes the underlying model is capable of recognizing a mistake when presented with contradictory evidence or a user correction. It will not save a system that confidently generates fluent falsehoods without any mechanism to detect them. Before deploying this prompt, ensure you have logging that captures the original error, the model's correction, and the user's subsequent response so you can measure recovery effectiveness over time.

Do not use this prompt in one-shot, stateless completion workflows where there is no opportunity for a recovery turn. It is designed for multi-turn chat, copilot, and agent interactions where the user can push back and the assistant can self-correct. Also avoid this prompt in systems where an apology or retraction would be more damaging than silently moving on—such as low-stakes creative generation or internal tooling where users prefer a simple retry over a verbose mea culpa. If your domain is regulated (healthcare, legal, finance), the recovery language must be reviewed by domain experts to ensure it does not inadvertently admit liability or create a compliance risk. Start by injecting controlled errors in a staging environment and measuring whether the model follows the recovery contract before exposing it to real users.

This template establishes a behavioral contract for correction and recovery. It instructs the model to detect its own mistakes, retract them clearly without defensiveness, apologize proportionally, and rebuild user trust through corrected information and explicit next steps. The prompt is designed to be pasted into your system message and assembled at runtime by replacing square-bracket placeholders with your application's specific policies, escalation paths, and output constraints.

textCopy
You are an AI assistant operating in a production system where accuracy and trust recovery are critical. Your correction and recovery behavior must follow these rules exactly.

## Error Detection and Acknowledgment
- Before finalizing any factual claim, internally verify it against [CONTEXT] and [TOOLS].
- If you detect a prior error in your own response, immediately pause and acknowledge it before continuing.
- Use explicit acknowledgment language: "I need to correct something I said earlier" or "That was incorrect. Here is the accurate information."
- Never ignore, deflect, or minimize your own errors.

## Retraction Protocol
- When retracting, state clearly what was wrong and why.
- Provide the corrected information immediately after the retraction.
- If the error affects downstream reasoning, explicitly walk through the corrected reasoning chain.
- Do not over-apologize. One clear apology is sufficient. Excessive apology erodes user confidence.

## Apology Calibration
- For minor factual errors: "I apologize for that error. Here is the correction."
- For errors that could cause harm or wasted effort: "I'm sorry. That mistake could have led you down the wrong path. Let me fix this carefully."
- For repeated errors on the same topic: Acknowledge the pattern, escalate if appropriate, and suggest verification steps.
- Never use apologetic language to avoid providing corrected information.

## Trust Recovery Actions
- After correction, offer a concrete next step: "Would you like me to re-run that analysis with the corrected data?"
- When appropriate, suggest external verification: "You can confirm this at [VERIFICATION_SOURCE]."
- If the error suggests a gap in your capability, be transparent: "This type of calculation is error-prone for me. I recommend double-checking with [ALTERNATIVE_TOOL]."

## Escalation Triggers
- If you make [ERROR_THRESHOLD] errors in a single conversation, escalate: "I've made multiple errors in this conversation. I recommend [ESCALATION_ACTION] to ensure you get accurate information."
- If an error involves [HIGH_RISK_DOMAIN], immediately flag it and recommend human review.
- If the user expresses frustration or lost trust, acknowledge it directly and offer [RECOVERY_PATH].

## What Not to Do
- Do not blame the user, the context, or tool outputs for your errors.
- Do not continue as if an error didn't happen once you've detected it.
- Do not fabricate corrections. If you don't know the right answer, say so.
- Do not refuse to engage after an error unless the conversation has become unsafe.

## Output Format for Corrections
When issuing a correction, structure your response as:
1. Correction marker: "[CORRECTION]"
2. Clear statement of what was wrong
3. Corrected information with source grounding
4. Impact assessment if the error affected prior reasoning
5. Next step or verification offer

Adapt this template by replacing the placeholders with your application's specific policies. [CONTEXT] should be replaced with your retrieved evidence or knowledge base reference. [TOOLS] should list available tool schemas the model can use for verification. [ERROR_THRESHOLD] defines how many errors trigger escalation—start with 2 for high-stakes domains, 3 for general use. [HIGH_RISK_DOMAIN] should enumerate your regulated or safety-critical areas such as medical, financial, or legal topics. [ESCALATION_ACTION] and [RECOVERY_PATH] should point to your human review queue, support channel, or fallback workflow. [VERIFICATION_SOURCE] and [ALTERNATIVE_TOOL] give users concrete paths to independent verification.

Before deploying, validate this prompt against your existing system message for conflicts. If you already have a refusal policy or tone guide, ensure the correction protocol doesn't contradict those instructions. Test with error injection scenarios: deliberately feed the model context that will produce a wrong answer, then provide corrected context in a follow-up turn and verify the model follows the retraction protocol. Log correction events in your observability pipeline with the [CORRECTION] marker so you can monitor error rates and recovery quality in production. For high-risk domains, route all correction events to a human review queue for the first week of deployment to calibrate the threshold and escalation behavior.

The Correction and Recovery System Prompt is not a standalone artifact. It must be embedded in an application harness that detects errors, triggers recovery, and prevents the model from compounding mistakes. The harness should intercept model outputs that contain correction markers (such as 'I need to correct myself' or 'I apologize, my previous answer was wrong'), log them separately, and route them through a recovery flow that re-presents the corrected context to the user. Without this harness, the prompt's recovery instructions will fire but the application will treat them as ordinary turns, missing the opportunity to update downstream state, notify monitoring systems, or trigger human review when corrections exceed a severity threshold.

Wire the prompt into a stateful conversation manager that maintains a correction ledger per session. Each time the model emits a correction, the harness should: (1) parse the correction statement and the original claim being retracted, (2) append both to a structured correction log with timestamps and turn IDs, (3) increment a correction counter, and (4) evaluate whether the correction count or the severity of the retracted claim crosses a configured threshold. If the threshold is breached, escalate to a human reviewer with the full correction ledger and the last N turns of conversation context. Use a lightweight parser—regex patterns for phrases like 'I apologize', 'I was wrong about', 'Let me correct that', and 'I need to retract'—to detect corrections without requiring the model to emit structured metadata. For high-stakes domains, require the model to wrap corrections in a predictable format such as [CORRECTION: <original claim> -> <corrected claim>] and validate that format before surfacing the corrected answer to the user.

Model choice matters. Smaller or older models may acknowledge errors but fail to fully retract the original claim, leaving contradictory information in the conversation. Test your chosen model against the error injection scenarios described in the Testing and Evaluation section before deploying. If the model's correction rate falls below 90% on injected errors, add a post-generation validation step that compares the corrected output against the original claim using an LLM judge or a simple entailment check. For production, log every correction event with the session ID, turn number, correction text, and whether the correction was surfaced to the user or escalated. This log becomes your audit trail for recovery quality and helps identify prompt drift or model regressions over time. Avoid wiring this prompt into stateless, single-turn systems where there is no conversation history to correct—the prompt's recovery instructions depend on the model having access to its own prior outputs.