Correction with New Evidence Prompt Template

Use this prompt when a user challenges a RAG-augmented assistant's response by providing their own counter-evidence, such as a document, link, or specific data point. The core job-to-be-done is not simply accepting the correction or re-retrieving, but performing a structured comparison between the user's provided evidence and the assistant's original sources. The assistant must assess which evidence is stronger based on criteria like recency, authority, and direct relevance, then produce a corrected response that explicitly explains the resolution and updates citations accordingly. The ideal user is a developer building a high-stakes assistant for research, legal, or compliance workflows where source trustworthiness is paramount and users are domain experts who can supply better information.

This prompt is essential when the cost of an incorrect resolution is high. For example, a financial analyst might correct a market summary by providing a link to a more recent SEC filing, or a legal researcher might supply a specific case that overrules the assistant's cited precedent. In these cases, the assistant must not blindly trust the user or stubbornly defend its retrieval. Instead, it must execute a transparent evidence evaluation step. The required context includes the assistant's original full response with citations, the user's correction message, and the user's new evidence. Without all three inputs, the comparison logic will fail. The prompt template includes placeholders for [ORIGINAL_RESPONSE], [USER_CORRECTION_MESSAGE], and [USER_EVIDENCE] to enforce this.

Do not use this prompt for simple factual corrections where no new evidence is provided. If a user says 'that date is wrong' without offering a source, a different prompt for claim reversal or state rollback is more appropriate. Similarly, avoid this prompt if the correction only requires re-retrieving from the same knowledge base with a better query. This prompt is specifically for the conflict-resolution scenario where two competing sources exist and a judgment call is required. Before implementing, ensure you have a logging mechanism to capture these evidence-comparison decisions, as they create a critical audit trail for understanding why the assistant changed its position.

This template is designed for RAG-augmented assistants where a user challenges a previous answer with new evidence. The prompt instructs the model to act as an evidence arbiter, not just a polite apologizer. It forces a structured comparison between the assistant's original sources and the user's new information, determines which evidence prevails based on quality criteria, and generates a corrected response with updated citations. Use this as your system prompt or as a dedicated correction-handling turn instruction.

codeCopy
You are an evidence-arbitration assistant. Your task is to re-evaluate a prior answer after a user provides counter-evidence.

## ORIGINAL CONTEXT
- Original User Question: [ORIGINAL_QUESTION]
- Assistant's Prior Answer: [PRIOR_ANSWER]
- Original Source Citations: [ORIGINAL_SOURCES]

## USER CORRECTION
- User's Correction Statement: [USER_CORRECTION]
- User-Provided Evidence: [USER_EVIDENCE]

## EVIDENCE EVALUATION RULES
1. Compare the user's evidence against each original source for relevance, recency, authority, and specificity.
2. Classify the conflict for each disputed claim as one of:
   - `user_evidence_prevails`: User's source is more authoritative, recent, or specific.
   - `original_source_prevails`: Original source is stronger; user evidence is outdated, misinterpreted, or from a weaker authority.
   - `insufficient_to_decide`: Neither source is clearly superior; acknowledge uncertainty.
3. Do not automatically defer to the user. Evaluate evidence quality, not politeness.

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "conflict_assessment": [
    {
      "disputed_claim": "string (the specific claim being challenged)",
      "original_source": "string (citation from original sources)",
      "user_evidence": "string (relevant excerpt from user's evidence)",
      "resolution": "user_evidence_prevails | original_source_prevails | insufficient_to_decide",
      "rationale": "string (brief explanation of why this resolution was chosen)"
    }
  ],
  "corrected_answer": "string (the full corrected response, incorporating prevailing evidence)",
  "updated_citations": ["string (list of citations supporting the corrected answer)"],
  "retracted_claims": ["string (list of original claims that are now withdrawn)"],
  "needs_re_retrieval": true | false,
  "re_retrieval_query": "string | null (suggested query if original retrieval was insufficient)"
}

## CONSTRAINTS
- If the user's evidence is weaker, politely explain why the original answer stands. Do not fabricate agreement.
- If the original retrieval was incomplete and the user's evidence reveals a gap, set `needs_re_retrieval` to true and suggest a better query.
- Never cite the user's evidence as a source unless you can verify it independently. Mark unverified user evidence clearly.
- If the correction reveals a factual error in the original answer, acknowledge it directly without over-apologizing.
- Preserve any parts of the original answer that are not disputed.

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace the square-bracket placeholders with your application's runtime values. [ORIGINAL_QUESTION], [PRIOR_ANSWER], and [ORIGINAL_SOURCES] should be pulled from your conversation state or session store. [USER_CORRECTION] and [USER_EVIDENCE] come from the current user turn. Set [RISK_LEVEL] to high for regulated domains to enforce stricter evidence standards and require human review for insufficient_to_decide outcomes. For low-risk applications, you can simplify the output schema to just corrected_answer and updated_citations. Before deploying, validate that your application layer can parse the JSON output, log conflict assessments for audit, and trigger re-retrieval when needs_re_retrieval is true. Test against cases where the user provides weak evidence, strong evidence, and no evidence at all to ensure the model doesn't default to blind agreement.

The Correction with New Evidence prompt operates inside a retrieval-augmented generation loop. When a user correction arrives with counter-evidence—a link, a document snippet, or a specific factual claim—the harness must first extract that evidence, then invoke this prompt with both the original retrieved sources and the user-provided evidence. The prompt's job is to evaluate which evidence prevails and produce a corrected response with updated citations. The harness is responsible for feeding the right inputs, validating the output, and deciding whether to re-retrieve, escalate, or commit the correction to session state.

Wire the prompt into your application as a dedicated correction handler that fires when the User Correction Detection prompt flags a turn as containing counter-evidence. Before calling this prompt, extract the user's evidence payload: if the user pasted a URL, fetch and chunk it; if they quoted text, capture the exact string; if they referenced a document already in your knowledge base, retrieve it fresh. Pass the original assistant response, its source citations, and the user's evidence into the [ORIGINAL_RESPONSE], [ORIGINAL_SOURCES], and [USER_EVIDENCE] placeholders respectively. On the output side, validate that the response contains: (1) an evidence assessment with a clear prevailing-evidence decision, (2) a corrected response that addresses the specific disputed claim, and (3) updated citations that include the user's evidence where it prevailed. If the output is malformed or the prevailing-evidence field is missing, retry once with a stricter schema constraint. If the prompt determines that neither evidence set is sufficient, route to a clarification or human escalation path rather than forcing a low-confidence correction.

Log every correction event with the original claim, user evidence, prevailing-evidence decision, and corrected output. This audit trail feeds the Correction Audit Trail Generation prompt and enables observability into correction failure patterns. Watch for two common harness-level failure modes: first, the prompt may accept user evidence that is itself incorrect or outdated—consider adding an evidence freshness check before calling this prompt. Second, the prompt may produce a corrected response that contradicts other session state—run the output through the State Rollback After Correction prompt to identify downstream state fields that need recomputation. For high-stakes domains, always require human review before committing a correction that reverses a sourced claim, especially when the original sources are authoritative and the user evidence is unverified.