Evidence-Answer Contradiction Detection Prompt Template

This prompt is designed for safety-critical AI applications where a generated answer must be verified against source evidence before it reaches a user. It detects direct contradictions, subtle inconsistencies, and polarity reversals between an answer and the provided evidence. Use this prompt as a guardrail in RAG pipelines, medical summarization, legal analysis, financial reporting, or any system where a contradiction could cause harm. It is not a general-purpose hallucination detector; it focuses specifically on contradiction, not on unsupported claims or fabrications.

The prompt assumes you already have a generated answer and a set of evidence passages. It returns structured contradiction spans with the conflicting evidence excerpts, making it suitable for automated blocking, human review queues, or audit logging. You should wire this prompt into your output validation pipeline after answer generation but before the response reaches the user. For systems with strict latency requirements, consider running this check asynchronously and flagging the response for retrospective review if a contradiction is found after delivery.

Do not use this prompt when you need to detect unsupported claims that lack evidence entirely—that requires a separate faithfulness audit prompt. Do not use it when you need to verify citation accuracy or check whether a specific source actually says what the answer claims. This prompt is also not a substitute for human review in regulated domains; it should feed into a review queue with clear escalation paths. If your evidence set is large, pre-filter to the most relevant passages before running contradiction detection to avoid diluting the model's attention across irrelevant context.

This template is designed to catch contradictions before they reach users in safety-critical applications. It compares a generated answer against provided evidence passages and returns a structured report identifying direct contradictions, subtle inconsistencies, and polarity reversals. The prompt expects you to supply the answer text, the evidence passages, and your desired output schema. It is not a general-purpose fact checker—it only detects contradictions between the answer and the specific evidence you provide, not contradictions within the evidence itself or against external knowledge.

textCopy
You are a contradiction detection system. Your task is to compare a generated answer against provided source evidence and identify any statements in the answer that directly contradict, reverse, or are inconsistent with the evidence.

## INPUT

**Generated Answer:**
[ANSWER_TEXT]

**Source Evidence Passages:**
[EVIDENCE_PASSAGES]

## INSTRUCTIONS

1. Decompose the generated answer into individual factual claims.
2. For each claim, search the evidence passages for supporting or contradicting information.
3. Flag any claim that contradicts the evidence. A contradiction occurs when:
   - The answer states a fact that is the opposite of what the evidence says (polarity reversal).
   - The answer asserts a value, date, name, or quantity that differs from the evidence.
   - The answer draws a conclusion that the evidence explicitly rules out.
   - The answer implies a relationship or causation that the evidence denies.
4. Do NOT flag claims that are merely absent from the evidence. Only flag contradictions.
5. For each contradiction found, extract the exact span from the answer and the exact span from the evidence that conflict.

## OUTPUT SCHEMA

Return a JSON object with this structure:
{
  "contradictions_found": boolean,
  "contradictions": [
    {
      "answer_span": "exact text from the answer that contradicts evidence",
      "evidence_span": "exact text from the evidence that conflicts",
      "contradiction_type": "polarity_reversal | value_mismatch | ruled_out_conclusion | relationship_conflict",
      "severity": "critical | major | minor",
      "explanation": "one-sentence description of the contradiction"
    }
  ],
  "claims_without_contradiction": integer,
  "claims_checked": integer
}

## CONSTRAINTS

- Only report contradictions where the evidence directly conflicts with the answer.
- Do not hallucinate contradictions. If unsure, do not flag.
- If the evidence is insufficient to verify a claim, do not flag it as a contradiction.
- Preserve exact text spans. Do not paraphrase the answer_span or evidence_span fields.
- If no contradictions are found, return an empty contradictions array and set contradictions_found to false.

To adapt this template, replace [ANSWER_TEXT] with the full generated answer you need to verify and [EVIDENCE_PASSAGES] with the retrieved or provided source documents. Format evidence passages with clear identifiers (e.g., [Source 1] ..., [Source 2] ...) so the model can reference them precisely in evidence_span fields. If your application requires a different output schema—such as inline annotations instead of a JSON report—modify the OUTPUT SCHEMA section accordingly. For high-stakes domains like healthcare or legal review, add a [RISK_LEVEL] parameter that adjusts the severity thresholds and consider routing critical contradictions to human review before any automated action is taken.

Before deploying, validate that the model returns parseable JSON matching the schema. Run this prompt against a golden dataset of known contradiction and non-contradiction pairs to measure precision and recall. Common failure modes include the model flagging unsupported claims as contradictions (false positives) and missing subtle polarity reversals in long answers (false negatives). If false positives are high, strengthen the CONSTRAINTS section. If false negatives are high, add few-shot examples of subtle contradictions in an [EXAMPLES] section. Always log contradiction detection results alongside the original answer and evidence for auditability.

This prompt is designed as a safety gate, not a user-facing response generator. It should sit between answer generation and delivery in your inference pipeline. The model receives a generated answer and the source evidence used to produce it, then returns a structured contradiction report. The application layer must parse this report and decide whether to block, rewrite, or escalate the answer before it reaches the user. For safety-critical domains—clinical documentation, legal analysis, financial reporting—this gate should be mandatory and its decisions logged for audit.

Wire the prompt into a post-generation validation step with the following contract. Inputs: [ANSWER] (the full generated text), [EVIDENCE] (the source passages with identifiers), and [CONTRADICTION_THRESHOLD] (the minimum severity that triggers a block). Output: a JSON object containing a contradictions array, each entry with answer_span, evidence_excerpt, contradiction_type (direct, polarity_reversal, temporal_mismatch, subtle_inconsistency), and severity (critical, high, medium, low). Parse this output with a strict schema validator. If parsing fails, retry once with a repair prompt that includes the raw output and the expected schema. If the retry also fails, log the failure and escalate to human review. For model choice, use a capable instruction-following model (GPT-4, Claude 3.5 Sonnet, or equivalent) with low temperature (0.0–0.1) to maximize consistency. Do not use smaller or faster models for this task—contradiction detection requires careful comparative reasoning that weaker models perform poorly on.

Build decision logic around the parsed output. If any contradiction has severity critical or high, block the answer and either regenerate with corrected grounding or escalate. If only medium or low contradictions exist, flag the answer for review but optionally allow delivery with a confidence warning. Log every contradiction detection result—including negative results (no contradictions found)—for monitoring drift in your generation or retrieval quality over time. Common failure modes to watch for: the model flagging stylistic differences as contradictions (tune your prompt's definition of contradiction to exclude phrasing variations), missing contradictions when evidence is long (chunk evidence and run detection per chunk if context windows are tight), and producing unparseable JSON under pressure (add a repair step and monitor parse failure rates). For regulated use cases, retain the full prompt input, output, and decision trail as audit evidence. This prompt is a detection tool, not a correction tool—when contradictions are found, use a separate rewriting or regeneration step to fix the answer rather than asking this prompt to do both jobs at once.