Multi-Turn Source Conflict Resolution Prompt

This playbook is for knowledge base operators and RAG system builders whose sources disagree across conversation turns. When a user asks a follow-up question and the newly retrieved evidence contradicts what the system said earlier, the default behavior of most models is to either ignore the contradiction or silently switch positions. This prompt forces the model to surface the conflict, explain the difference in evidence, and let the user decide when resolution is not possible.

Use this prompt inside a multi-turn RAG harness where conversation history and prior answers are available alongside fresh retrieval results. It assumes your application layer already handles retrieval, turn tracking, and source metadata injection. This is not a single-turn fact-checking prompt and it is not a replacement for a retrieval pipeline. It is the synthesis step that makes conflict visible rather than hiding it.

Do not use this prompt when you need a simple fact-checking verdict, when the system should silently prefer the most recent source, or when the application cannot inject prior-turn answers and source metadata into the prompt context. For high-stakes domains such as healthcare or legal, always pair this prompt with a human review step and log the conflict resolution decision for audit purposes.

This prompt template is designed to be wired into your RAG pipeline after retrieval and before answer generation. It instructs the model to detect contradictions between evidence cited in the current turn and evidence cited in prior conversation turns, surface those conflicts transparently, explain likely reasons for the disagreement (such as temporal changes, source differences, or context shifts), and let the user decide when resolution isn't possible. Use this when your knowledge base contains documents that may disagree with each other and your users need to see those disagreements rather than have the model silently pick a side.

textCopy
You are a conflict-aware research assistant operating in a multi-turn conversation. Your job is to answer the user's current question using the provided evidence while checking for contradictions with evidence you cited in previous turns.

## CONVERSATION HISTORY
[CONVERSATION_HISTORY]

## CURRENT RETRIEVED EVIDENCE
[CURRENT_EVIDENCE]

## CURRENT USER QUESTION
[USER_QUESTION]

## INSTRUCTIONS
1. Identify any factual claims in the current evidence that directly contradict claims you made in prior turns based on previously cited sources.
2. If no contradictions exist, answer the question normally using the current evidence. Cite sources using the format [SOURCE_ID] for each claim.
3. If contradictions exist, structure your response as follows:
   a. **Current Evidence Answer**: Provide the answer supported by the current evidence with citations.
   b. **Conflict Detection**: Explicitly state what contradicts your prior answer and cite both the current source and the prior source.
   c. **Conflict Analysis**: Explain the most likely reason for the contradiction. Consider:
      - Temporal differences (e.g., one source is newer, policy changed, facts evolved)
      - Source differences (e.g., different authors, different methodologies, different scope)
      - Context differences (e.g., the prior answer addressed a different aspect of the question)
      - Genuine unresolved disagreement between authoritative sources
   d. **Resolution Guidance**: Tell the user what they should do next. Options include:
      - Prefer the newer source if a temporal change is confirmed
      - Request clarification on which source or context to prioritize
      - Acknowledge that the conflict cannot be resolved with available evidence and recommend human review
4. Never hide a contradiction. If sources disagree, the user must be told.
5. If the contradiction stems from a user correction in a prior turn, acknowledge the correction and do not treat it as a source conflict.
6. If the prior answer was marked as low-confidence or uncertain, note that the contradiction may reflect improved evidence rather than a true conflict.

## OUTPUT FORMAT
[OUTPUT_SCHEMA]

## CONSTRAINTS
[CONSTRAINTS]

Adapt this template by replacing each square-bracket placeholder with your application's specific inputs. [CONVERSATION_HISTORY] should contain the prior turns with their cited sources, not just the raw dialogue. [CURRENT_EVIDENCE] should be the retrieved passages for the current turn with their source identifiers. [OUTPUT_SCHEMA] can be a JSON schema, a markdown structure, or a free-text format depending on your downstream consumer. [CONSTRAINTS] should include domain-specific rules such as citation style requirements, tone policies, or escalation thresholds. Before shipping, test this prompt against a golden dataset of known conflicting source pairs and verify that the model surfaces conflicts rather than silently reconciling them. For high-stakes domains, add a human review step when the model flags a contradiction.

This prompt is designed to sit inside a multi-turn RAG pipeline where each user turn triggers retrieval, evidence ranking, and answer synthesis. The implementation harness must manage conversation state, track previously cited sources and their timestamps, and feed the prompt a structured [PRIOR_TURN_SUMMARY] that includes the prior answer, its sources, and any unresolved conflicts. The prompt expects [CURRENT_RETRIEVED_EVIDENCE] to be a ranked list of passages with source identifiers, publication dates, and relevance scores. Without this structured input, the model cannot reliably detect temporal conflicts or source disagreements across turns.

Wire the prompt into your application by building a pre-processing step that assembles the [CONVERSATION_HISTORY] and [PRIOR_TURN_SUMMARY] from your session store. After the model returns a response, run a conflict transparency validator that checks for the required output fields: conflict_detected (boolean), conflict_explanation (string, required if conflict detected), resolution_approach (enum: latest_wins, source_authority, user_choice, unresolvable), and answer (string with inline citations). If the validator fails, retry once with a repair prompt that includes the validation error. For high-stakes domains, route responses where conflict_detected is true and resolution_approach is unresolvable to a human review queue with the full evidence set and conversation context attached.

Model choice matters here. Use a model with strong instruction-following and long-context handling, such as claude-sonnet-4-20250514 or gpt-4o, because the prompt requires comparing evidence across turns and maintaining citation consistency. Set temperature low (0.0–0.2) to reduce variance in conflict detection. Log every response with the input context hash, conflict flag, resolution approach, and validator pass/fail status. This telemetry lets you monitor how often conflicts occur, which resolution strategies dominate, and whether the validator is catching real failures. Avoid deploying this prompt without the validator—models will occasionally smooth over contradictions rather than surface them, which defeats the purpose of a conflict-aware system.