This prompt is designed for verification pipeline developers who need to compare factual claims across two or more source documents and identify genuine contradictions. Its primary job-to-be-done is pairwise comparison logic: given a set of pre-extracted claims from Document A and Document B, the prompt produces a structured report classifying each claim pair as a direct contradiction, a partial mismatch, or a compatible statement. The ideal user is an engineer integrating this prompt into a fact-checking pipeline's contradiction detection stage, sitting after claim extraction and before severity scoring or human review routing. You should use this prompt when you have already decomposed source documents into atomic, verifiable claims and need systematic conflict surfacing, not when you are starting from raw, unstructured text.

Do not use this prompt for single-document self-consistency checks without adapting the instructions; it is optimized for cross-document comparison and may miss rhetorical devices or conditional logic that a dedicated internal-consistency prompt would catch. It is also unsuitable for temporal sequence validation, where event ordering and date normalization require specialized reasoning, or for numerical tolerance analysis, where value comparisons need explicit unit conversion and significant-figure handling. If your source documents contain tables, charts, or images, extract and normalize those claims into text before invoking this prompt, as it lacks native multimodal reasoning. For high-stakes domains like healthcare or legal review, always route the prompt's output to a human reviewer and ensure the upstream claim extraction step preserves verbatim source text to ground the contradiction verdicts in evidence.

Before wiring this prompt into your application, confirm that your claim extraction step produces clean, atomic claims with stable identifiers and source provenance. The prompt expects claims as structured input, not raw paragraphs. If your pipeline skips this step, you will see high false-positive rates from the model comparing paraphrases rather than factual content. Next, review the output schema and evaluation criteria in the full playbook to integrate validation checks, retry logic, and human review routing. Start with a small, labeled dataset of known contradictions and non-contradictions to calibrate the prompt's conflict type classification thresholds before scaling to production volumes.

This template is designed to be copied directly into your verification pipeline. It instructs the model to act as a contradiction detection engine, comparing a set of target claims against a corpus of source documents. The prompt forces structured, machine-readable output that includes the conflicting claim pair, a precise conflict type classification, verbatim evidence excerpts, and a confidence score. Before using this template, ensure your upstream pipeline has already extracted discrete, atomic claims from your source documents using a dedicated claim extraction prompt. Feeding raw, unprocessed documents will produce noisy and unreliable results.

textCopy
You are a contradiction detection engine. Your task is to compare a set of [TARGET_CLAIMS] against a corpus of [SOURCE_DOCUMENTS] to identify direct contradictions. A contradiction exists only when two statements cannot both be true at the same time. Do not flag differences in phrasing, scope, or level of detail as contradictions.

# INPUT

## TARGET CLAIMS
A JSON array of claim objects, each with an `id` and `text` field.
```json
[TARGET_CLAIMS]

SOURCE DOCUMENTS

A JSON array of document objects, each with a doc_id and text field.

jsonCopy
[SOURCE_DOCUMENTS]

TASK

For each claim in [TARGET_CLAIMS], search the [SOURCE_DOCUMENTS] for any statement that directly contradicts it. A contradiction must meet these criteria:

1. Logical Incompatibility: The two statements assert mutually exclusive facts.
2. Subject Alignment: The statements must be about the same entity, event, or metric.
3. Temporal Alignment: The statements must refer to the same time period, or one must assert a state that is impossible given the other's timeframe.

CONSTRAINTS

• Ignore Paraphrasing: Do not flag a claim as contradictory if the source document expresses the same fact using different words.
• Ignore Scope Differences: A general statement in one document does not contradict a more specific statement in another unless the specific statement is a logical subset that is directly negated.
• Ignore Hedging: A statement containing "may," "could," or "reportedly" does not directly contradict a definitive statement, but flag it as a POTENTIAL_MISMATCH.
• Evidence is Mandatory: You must provide a verbatim excerpt from the source document for every flagged contradiction.

OUTPUT SCHEMA

You must return a valid JSON object with the following structure. Do not include any text outside the JSON object.

jsonCopy
{
  "contradictions": [
    {
      "claim_id": "string",
      "claim_text": "string",
      "conflicting_doc_id": "string",
      "conflicting_excerpt": "string",
      "conflict_type": "DIRECT_CONTRADICTION | PARTIAL_MISMATCH | POTENTIAL_MISMATCH",
      "confidence": 0.0,
      "rationale": "A brief explanation of why these statements cannot both be true."
    }
  ],
  "unmatched_claim_ids": ["list of claim IDs with no contradiction found"]
}

RISK LEVEL

[RISK_LEVEL]

FINAL INSTRUCTION

Execute the comparison now. Return only the JSON object specified in the OUTPUT SCHEMA.

To adapt this template, replace the square-bracket placeholders with your data. [TARGET_CLAIMS] should be a JSON array of the claims you want to verify, and [SOURCE_DOCUMENTS] should be a JSON array of the evidence documents. The [RISK_LEVEL] field is a control mechanism: set it to HIGH to instruct the model to default to flagging uncertain cases for human review, or STANDARD for automated pipelines. After receiving the output, you must validate the JSON schema and verify that every conflicting_excerpt is a verbatim substring of the provided source documents to prevent hallucinated evidence. For high-stakes domains like healthcare or finance, route all outputs with a confidence score below 0.9 for mandatory human review before any action is taken.

This prompt is designed to be a stateless function inside a larger verification pipeline. It expects pre-extracted claims and their source document contexts as input, not raw documents. The calling application is responsible for claim extraction, document chunking, and evidence pairing before invoking this prompt. A typical harness wraps the prompt in a service that accepts a batch of claim pairs, fans out to the LLM, collects structured responses, and routes results based on conflict severity and confidence scores. Because contradiction detection is a pairwise comparison task, the harness should implement batching with concurrency limits to stay within rate limits while processing document pairs efficiently. For high-stakes domains like legal or clinical verification, the harness must enforce a human-review gate for all detected contradictions above a configurable severity threshold before any downstream action is taken.

The implementation must include schema validation on every response. The prompt's output contract specifies a JSON object with fields for claim_a, claim_b, conflict_type, confidence, evidence_excerpts, and explanation. Before accepting a model response, validate that conflict_type is one of the enumerated values (direct_contradiction, partial_mismatch, temporal_inconsistency, numerical_disagreement, compatible, unrelated), that confidence is a float between 0.0 and 1.0, and that evidence_excerpts contains non-empty strings that can be traced back to the provided source documents. Failed validations should trigger a retry loop with the original prompt plus the validation error message appended as feedback. Cap retries at three attempts, then escalate to a human review queue with the full context attached. Log every attempt, the raw model output, validation errors, and final disposition for auditability and prompt debugging. For model selection, use a model with strong instruction-following and structured output capabilities; GPT-4o or Claude 3.5 Sonnet are suitable defaults. Avoid smaller or older models that may collapse conflict_type into binary true/false or omit required fields under token pressure.

When integrating with a RAG pipeline, the harness should pre-filter document pairs before invoking this prompt. Only pass claim pairs where both documents have been retrieved with sufficient relevance scores, and where the claims share a common topic or entity. Blind pairwise comparison across all document pairs in a large corpus is computationally prohibitive and generates excessive false positives from unrelated claims. Implement a lightweight pre-screening step—either a simpler prompt or a vector similarity threshold—to select candidate pairs for detailed contradiction analysis. The harness should also track false positive patterns over time: if certain conflict types or source pairs consistently generate contradictions that human reviewers overturn, feed those examples back into few-shot examples or adjust confidence thresholds. Finally, never treat the model's confidence score as a calibrated probability without empirical validation against human judgments on your specific data distribution. Run periodic eval batches against a golden dataset of known contradictions and non-contradictions to monitor drift and recalibrate thresholds.