Correction in RAG Context Prompt Template

This prompt is designed for retrieval-augmented generation (RAG) assistants where a user challenges a sourced claim. When a user says 'that's wrong' or provides contradictory information, this prompt re-evaluates the original retrieved evidence against the correction, determines whether the retrieval was insufficient or misinterpreted, and produces a corrected answer with explicit re-retrieval triggers if needed. Use this when your assistant must maintain source faithfulness after user pushback, when you need structured correction decisions that downstream systems can act on, and when correction handling determines whether users trust your system enough to continue using it. This prompt belongs in the correction-handling layer of your RAG pipeline, after correction detection but before response generation. It assumes you already have the original query, the original retrieved passages, the assistant's prior answer, and the user's correction message available as inputs.

Do not use this prompt when the user is asking a clarifying question rather than issuing a correction, when the correction targets a non-sourced claim (use the Assistant Claim Reversal Prompt instead), or when the user provides new evidence that requires fresh retrieval before re-evaluation (use the Correction with New Evidence Prompt Template). This prompt is also inappropriate for corrections that span multiple prior turns or require state rollback across tool calls—those scenarios need the State Rollback After Correction or Correction Cascade Prevention prompts. The ideal user is an AI engineer or product developer building a RAG system where source citations are surfaced to users and where incorrect citations directly damage credibility. You need four structured inputs at minimum: the original user query, the retrieved passages with source identifiers, the assistant's prior answer with citation mappings, and the user's correction text.

Before implementing, verify that your correction detection step reliably distinguishes corrections from follow-up questions and topic shifts. False positives here will route benign clarification requests into this re-evaluation flow, wasting latency and context budget. Also confirm that your retrieval system can accept re-retrieval triggers programmatically—this prompt may output a re_retrieval_needed flag with modified query parameters that your harness must act on before generating the final response. If your RAG pipeline cannot perform mid-turn re-retrieval, configure the prompt to operate in 'evidence-only' mode where it works solely with the already-retrieved passages and flags insufficient evidence for human review rather than requesting new retrieval.

This prompt template is the core instruction set for a retrieval-augmented generation (RAG) assistant that must handle a user challenging a previously sourced claim. It forces the model to re-examine the original retrieved evidence, compare it against the user's correction, and determine whether the error stemmed from insufficient retrieval, misinterpretation of a source, or a correct source that the user is now disputing. The output is a structured correction that includes a re-verification of source faithfulness, preventing the assistant from simply agreeing with the user without evidence.

textCopy
You are an assistant that answers questions using only the provided retrieved context. You have just given a previous answer based on that context. The user is now correcting a specific claim you made.

Your task is to re-evaluate the original evidence against the user's correction and produce a corrected answer.

## INPUTS

[ORIGINAL_USER_QUESTION]
[YOUR_PREVIOUS_ANSWER]
[RETRIEVED_CONTEXT_USED]
[USER_CORRECTION]

## CONSTRAINTS

- You must ground every factual statement in the provided [RETRIEVED_CONTEXT_USED].
- If the user's correction is supported by the original context, acknowledge the error and provide the corrected information with a direct quote from the source.
- If the user's correction is not supported by the original context, politely explain that the provided evidence does not confirm their correction, and restate what the evidence actually says.
- If the original context is silent or ambiguous on the point of correction, state that clearly and do not fabricate a resolution.
- Do not use any outside knowledge.
- Maintain a professional, non-defensive tone.

## OUTPUT SCHEMA

Respond with a valid JSON object matching this schema:
{
  "correction_analysis": {
    "original_claim": "The specific claim from your previous answer that is being challenged.",
    "user_correction_summary": "A concise summary of the user's correction.",
    "evidence_evaluation": "supported_by_context | contradicted_by_context | context_is_silent",
    "evidence_quote": "The exact text from [RETRIEVED_CONTEXT_USED] that supports this evaluation, or null."
  },
  "requires_re_retrieval": true or false,
  "re_retrieval_query": "A new search query to find better evidence, only if requires_re_retrieval is true. Otherwise, null.",
  "corrected_response": "The full, corrected answer to the user, incorporating the analysis above."
}

To adapt this template, replace the bracketed placeholders with your application's actual data. [ORIGINAL_USER_QUESTION] and [YOUR_PREVIOUS_ANSWER] come from your session history. [RETRIEVED_CONTEXT_USED] is the raw text of the chunks that were provided to the model in the previous turn. [USER_CORRECTION] is the user's latest message. The requires_re_retrieval boolean is a critical control signal for your application harness; if true, your system should execute the re_retrieval_query and run this entire prompt again with the new context before showing the user the corrected_response. For high-stakes domains, always log the full JSON output and consider flagging cases where evidence_evaluation is context_is_silent for human review, as this indicates a knowledge gap that retrieval alone cannot fix.

The Correction in RAG Context prompt is not a standalone component; it is a decision node inside a larger retrieval-augmented generation pipeline. When a user challenges a sourced claim, the application must pause the normal answer flow, invoke this prompt with the original query, the disputed assistant response, the retrieved evidence that supported it, and the user's correction text. The prompt's output—a structured decision about whether retrieval was insufficient or misinterpreted, plus a corrected answer or a re-retrieval trigger—must then be acted on by the surrounding harness. This means the harness is responsible for supplying clean, timestamped evidence records, enforcing the output schema, and routing the result to either the user or a re-retrieval loop.

Start by validating the prompt's output against a strict schema before any user-facing action. The expected output should include at minimum: a correction_accepted boolean, a correction_type enum (e.g., retrieval_insufficient, source_misinterpreted, user_evidence_override, no_correction_needed), a corrected_answer string, a re_retrieval_needed boolean, an optional re_retrieval_query string, and a source_faithfulness_check object listing each original source with a still_valid boolean and reason string. If the model's output fails to parse into this schema, do not show it to the user. Instead, log the raw output, increment a schema_violation metric, and retry with a stricter version of the prompt that includes the schema inline and a [CONSTRAINTS] block explicitly forbidding extra commentary. After two retries, fall back to a safe canned response: 'I wasn't able to verify the correction against the original sources. Let me re-check and get back to you.' This prevents malformed corrections from eroding trust.

The re-retrieval loop is the most dangerous part of this harness. If re_retrieval_needed is true, the application must execute the suggested re_retrieval_query (or a system-generated variant) against the same retrieval pipeline, then re-invoke the Correction in RAG Context prompt with the new evidence appended. Set a hard limit of two re-retrieval cycles per correction event. If the second cycle still produces re_retrieval_needed: true, break the loop and escalate to a human review queue with the full chain: original query, original evidence, user correction, first re-retrieval results, second re-retrieval results, and both prompt outputs. This prevents infinite loops and surfaces genuinely hard retrieval failures to the operations team. Log every cycle with a correction_loop_id for traceability.

Human review gates should be triggered by specific conditions, not just loop exhaustion. Escalate to a review queue when: (a) the source_faithfulness_check shows that more than half of the original sources are now marked still_valid: false, indicating a systemic retrieval failure; (b) the correction_type is user_evidence_override and the user's evidence directly contradicts a source from an authoritative internal knowledge base, which may indicate a knowledge base error; or (c) the correction involves a regulated domain such as healthcare, legal, or financial claims, where incorrect corrections carry compliance risk. In these cases, the harness should surface the correction event in a review tool with a structured payload, not just a raw log line. The human reviewer should be able to accept the corrected answer, modify it, or reject the correction and restore the original response with an explanation.

Model choice matters here. This prompt requires strong instruction-following and structured output discipline. Prefer models with native JSON mode or function-calling support, and set temperature to 0 or near-zero to reduce variance in the correction decision. If using a model without reliable JSON mode, wrap the prompt output in a parser that extracts JSON from markdown fences or free text, but log every parse failure as a near-miss. Finally, instrument the harness with metrics: correction acceptance rate, re-retrieval loop frequency, schema violation rate, human escalation rate, and time-to-correction-resolution. These metrics will tell you whether the correction flow is building user trust or creating a new failure mode.