Source Conflict Root Cause Analysis Prompt

This playbook is for knowledge base operators, RAG pipeline engineers, and AI quality teams who need to move beyond detecting conflicts to understanding their origin. When your retrieval system surfaces contradictory claims from multiple documents, this prompt analyzes the conflicting passages and classifies the root cause: temporal drift, definitional differences, methodology variance, jurisdiction conflicts, or data quality issues. The ideal user is someone who already has a conflict detection step in place and needs a structured diagnosis to decide whether to update the knowledge base, adjust retrieval, or escalate to a subject matter expert.

Use this prompt after a conflict detection step has identified the conflicting source pairs. It is not a conflict detector itself. It assumes you already have two or more documents that disagree and need a structured diagnosis. The prompt requires the conflicting passages as input, along with any available metadata such as publication dates, document types, jurisdictions, and source identifiers. Without this context, the model cannot reliably distinguish between a genuine temporal update and a data quality error. The output is a root cause classification with supporting evidence drawn from the passages themselves, not a resolution of the conflict.

Do not use this prompt when you need to resolve conflicts, rank sources by credibility, or generate a final answer that reconciles disagreements. Those are separate workflows covered by sibling playbooks such as Source Credibility Weighting Prompt for Conflicts and Conflict-Aware RAG Answer Generation Prompt Template. Also avoid this prompt when the conflicting passages are not yet identified—start with Multi-Source Conflict Detection Prompt Template first. For high-stakes domains such as healthcare, legal, or finance, always route the root cause analysis output to a human reviewer before taking action on the knowledge base. The prompt provides a diagnosis, not a decision.

This template is designed to be copied directly into your prompt management system, IDE, or orchestration layer. It accepts a set of conflicting source passages and returns a structured root cause classification with supporting evidence. The prompt forces the model to distinguish between genuine contradictions and superficial disagreements caused by temporal drift, definitional variance, methodology differences, jurisdiction conflicts, or data quality issues. Use it when your RAG pipeline surfaces contradictory claims and you need to understand why before deciding how to resolve or surface the conflict to users.

textCopy
You are a root cause analyst for a knowledge base system. Your job is to examine conflicting source passages and classify the underlying reason for the disagreement. Do not resolve the conflict. Do not pick a winner. Classify the root cause and provide evidence.

## INPUT

[CONFLICT_DESCRIPTION]

## SOURCE PASSAGES

[SOURCE_PASSAGES]

## DOMAIN TAXONOMY

[DOMAIN_TAXONOMY]

## OUTPUT SCHEMA

Return a JSON object with the following structure:

{
  "conflict_id": "string identifier for this conflict instance",
  "root_cause_category": "TEMPORAL_DRIFT | DEFINITIONAL_DIFFERENCE | METHODOLOGY_VARIANCE | JURISDICTION_CONFLICT | DATA_QUALITY_ISSUE | SOURCE_BIAS | OTHER",
  "root_cause_explanation": "2-4 sentence explanation of why this category applies, referencing specific evidence from the source passages",
  "evidence": [
    {
      "source_id": "identifier from SOURCE_PASSAGES",
      "relevant_excerpt": "quoted text that supports the root cause classification",
      "rationale": "why this excerpt points to the classified root cause"
    }
  ],
  "is_genuine_contradiction": true or false,
  "genuine_contradiction_rationale": "if true, explain why the sources genuinely disagree on facts; if false, explain why the disagreement is superficial or resolvable",
  "recommended_resolution_strategy": "TEMPORAL_PRECEDENCE | AUTHORITY_WEIGHTING | MAJORITY_VOTE | ESCALATE_TO_HUMAN | FLAG_FOR_USER | NO_RESOLUTION_NEEDED",
  "confidence": 0.0 to 1.0,
  "uncertainty_notes": "optional string describing what would increase confidence"
}

## CONSTRAINTS

[CONSTRAINTS]

## EXAMPLES

[EXAMPLES]

## INSTRUCTIONS

1. Read the conflict description and all source passages carefully.
2. Identify whether the sources genuinely contradict each other or whether the disagreement stems from a resolvable difference in context, definitions, timeframes, methods, jurisdiction, or data quality.
3. Classify the root cause using exactly one category from the OUTPUT SCHEMA.
4. Provide at least one evidence item per source passage that supports your classification.
5. If you cannot determine the root cause with confidence above 0.7, set the category to OTHER and explain what additional information would help.
6. Do not fabricate facts not present in the source passages.
7. Do not resolve the conflict or declare one source correct unless the root cause category inherently implies precedence (e.g., TEMPORAL_DRIFT with a clear newer source).

Adaptation guidance: Replace [CONFLICT_DESCRIPTION] with a 1-3 sentence summary of what the sources appear to disagree about. Populate [SOURCE_PASSAGES] with each retrieved chunk, including source identifiers, publication dates, author metadata, and the full passage text. The [DOMAIN_TAXONOMY] placeholder should contain your organization's domain-specific categories for root causes—legal teams might add STATUTORY_CHANGE or CIRCUIT_SPLIT, while financial analysts might add RESTATEMENT or ACCOUNTING_STANDARD_CHANGE. Use [CONSTRAINTS] to inject domain-specific rules such as regulatory citation requirements, jurisdiction precedence rules, or minimum evidence thresholds. The [EXAMPLES] placeholder should contain 2-3 few-shot examples showing correct classifications for your domain. For high-stakes domains, wire the output into a human review queue when confidence falls below 0.8 or when recommended_resolution_strategy is ESCALATE_TO_HUMAN.

Validation and evals: Before deploying, build a test harness that validates the output JSON against the schema, checks that evidence array is non-empty, and confirms that root_cause_category matches one of the enumerated values. Run the prompt against a golden dataset of 20-30 known conflicts with labeled root causes and measure precision, recall, and F1 per category. Pay special attention to false positives where the model classifies superficial disagreements as genuine contradictions. Log every classification with the input passages, output, and confidence score for auditability. If your domain is regulated, require human sign-off on classifications where is_genuine_contradiction is true and the conflict severity is high.

The Source Conflict Root Cause Analysis prompt is designed for diagnostic, not real-time, workflows. It expects a batch of pre-identified conflicting documents and returns a structured root cause classification. Wire this prompt into a knowledge base maintenance pipeline, a scheduled audit job, or an internal operator tool—not into a customer-facing Q&A endpoint. The primary integration points are: a conflict detection step that identifies document pairs or clusters with contradictory claims, a retrieval or document fetch step that gathers the full text of those documents, and a downstream action step that routes the root cause analysis to the appropriate remediation queue (e.g., stale content refresh, terminology normalization, jurisdiction tagging).

Build a validation layer around the prompt's structured output. The expected schema includes root_cause_category (an enum of temporal drift, definitional difference, methodology variance, jurisdiction conflict, data quality issue, or unknown) and evidence (an array of source excerpts with document identifiers). Validate that the category is a recognized enum value and that each evidence item includes a non-empty source_id and excerpt. If validation fails, retry once with the validation errors injected into the prompt as additional [CONSTRAINTS]. Log all retries and validation failures for later prompt improvement. For high-stakes knowledge bases (legal, regulatory, clinical), route unknown classifications and low-confidence outputs to a human review queue rather than auto-applying remediation.

Model choice matters here. This prompt requires careful comparative reasoning across multiple documents, so prefer models with strong long-context and analytical capabilities. If the conflicting documents are long, consider a two-pass architecture: first, use a cheaper model to extract the specific conflicting claims from each document; second, pass only those extracted claims plus surrounding context to the root cause analysis prompt. This reduces token costs and improves focus. Store the full prompt, response, and validation results in an observability log keyed by document cluster ID. Over time, review misclassifications to refine the root_cause_category enum and the prompt's decision rules. Do not use this prompt to automatically resolve or hide conflicts—its job is diagnosis, not synthesis.