Cross-Chunk Contradiction Detection Prompt

This prompt is for knowledge base operators and RAG pipeline builders who need to surface factual conflicts before answer generation. The job-to-be-done is detecting contradictory claims across multiple retrieved chunks, flagging the specific conflicting statements with source references, and recommending a resolution path—escalate for human review, suppress the conflicting context, or note the disagreement in the final answer. The ideal user is an AI engineer or platform operator managing a multi-document retrieval system where sources may disagree due to version drift, author disagreement, temporal changes, or ingestion errors. Required context includes a set of retrieved passages and the original user query that triggered retrieval.

Do not use this prompt when you need a single authoritative answer from a curated, internally consistent knowledge base. If your documents are pre-validated for consistency or you are operating in a low-risk domain where contradictions are acceptable noise, this prompt adds latency and token cost without proportional value. Also avoid this prompt when the retrieved context is too short to contain meaningful contradictions—single-chunk or very small context windows rarely benefit from contradiction detection. For real-time chat systems with strict latency budgets under 500ms, run this as an async pre-processing step rather than inline before answer generation.

This prompt is a pre-answer safety check, not a post-hoc fact verification tool. It operates on retrieved context alone and does not access ground-truth databases or external knowledge. The output is a structured contradiction report that downstream systems can consume: an answer generator can use it to add caveats, a router can escalate to human review, or a monitoring pipeline can log conflict frequency as a data quality signal. Wire this into your RAG pipeline after retrieval and deduplication but before answer synthesis. If contradictions are found, decide whether to abort, warn, or proceed with explicit uncertainty language. For regulated domains—legal, clinical, financial—always route detected contradictions to human review rather than attempting automated resolution.

This prompt template is designed to be dropped into a RAG pipeline after retrieval and before answer synthesis. Its job is to compare claims across multiple chunks, identify where they conflict, and produce a structured contradiction report. The template uses square-bracket placeholders for all variable inputs—swap these with your actual retrieved context, output schema, and operational constraints before use.

textCopy
You are a contradiction detection system operating on retrieved document chunks from a knowledge base. Your task is to compare factual claims across the provided chunks and identify contradictions.

## INPUT
[CHUNKS]

## INSTRUCTIONS
1. Extract all factual claims from each chunk. A factual claim is a verifiable statement about an entity, event, date, measurement, policy, or relationship.
2. Compare claims across chunks. A contradiction exists when two or more chunks assert mutually exclusive facts about the same subject.
3. For each contradiction found, produce a structured entry following the [OUTPUT_SCHEMA].
4. If no contradictions are found, return an empty contradictions array.
5. Do not flag differences in opinion, interpretation, or emphasis as contradictions. Only flag mutually exclusive factual statements.
6. If a contradiction involves a temporal dimension (e.g., one chunk describes a state before a change and another describes it after), classify it as a temporal variance, not a contradiction, unless the timestamps overlap.

## OUTPUT_SCHEMA
Return a JSON object with the following structure:
{
  "contradictions": [
    {
      "contradiction_id": "string",
      "subject": "string (the entity, event, or concept the contradiction is about)",
      "claim_a": {
        "text": "string (exact claim from source)",
        "chunk_id": "string",
        "source_reference": "string (document title, section, or identifier)"
      },
      "claim_b": {
        "text": "string (exact conflicting claim from source)",
        "chunk_id": "string",
        "source_reference": "string"
      },
      "contradiction_type": "direct_factual | temporal_variance | definitional | numerical | categorical",
      "severity": "critical | high | medium | low",
      "resolution_recommendation": "escalate_for_human_review | prefer_most_recent_source | prefer_most_authoritative_source | flag_in_answer_with_caveat | suppress_both_claims",
      "rationale": "string (brief explanation of why this is a contradiction and why the resolution is recommended)"
    }
  ],
  "unresolvable_contradictions_count": 0,
  "chunks_with_no_contradictions": ["chunk_id"],
  "overall_confidence": "high | medium | low",
  "summary": "string (one-sentence summary of findings)"
}

## CONSTRAINTS
- Only flag contradictions where both claims are stated with confidence. Ignore hedged or speculative claims unless they directly conflict with a confident claim.
- If three or more chunks conflict on the same subject, group them under one contradiction entry with the two most directly opposed claims, and note additional conflicting chunks in the rationale.
- Do not fabricate contradictions. If claims are complementary or describe different aspects of the same subject, do not flag them.
- Respect [RISK_LEVEL]. For high-risk domains, prefer escalation over automated resolution.

## EXAMPLES
[EXAMPLES]

## RISK_LEVEL
[RISK_LEVEL]

To adapt this template, replace [CHUNKS] with your retrieved passages formatted as chunk objects containing chunk_id, text, and source_reference fields. Populate [EXAMPLES] with 2–3 annotated contradiction examples from your domain to calibrate the model's detection threshold. Set [RISK_LEVEL] to high for legal, clinical, or financial use cases where false negatives are dangerous, or standard for general knowledge base maintenance. The output schema is designed to feed directly into a downstream answer synthesis step or a human review queue—do not modify the field names without updating your consuming application code.

Before deploying, validate the output against the schema using a JSON schema validator in your application harness. Run this prompt against a golden dataset of known contradictions and non-contradictions to measure precision and recall. In high-risk domains, route all critical severity contradictions to human review before any answer is shown to users. If your retrieval pipeline frequently returns chunks with overlapping temporal contexts, consider adding a temporal_context field to each chunk input to improve temporal variance classification.