Cross-Document Contradiction Flagging Prompt

This prompt is designed for legal, compliance, and audit teams who need to systematically identify contradictory statements across a collection of documents. It takes a set of document excerpts and a specific topic or claim as input, then outputs a structured contradiction report with source citations, severity ratings, and recommended resolution actions. Use this prompt when your retrieval system has surfaced multiple documents that appear to address the same fact, policy, or obligation, and you need to surface disagreements rather than silently synthesizing a single answer.

This is not a general-purpose fact-checking prompt. It assumes you have already retrieved relevant passages and need to compare them for internal inconsistency. The prompt works best when documents share a common domain, such as contracts, regulatory filings, internal policies, or compliance evidence. It is not suitable for open-domain web search where sources have unknown provenance or when documents discuss entirely different subjects. The prompt requires at minimum two document excerpts and a defined topic or claim to compare against. Without a clear comparison target, the model will struggle to identify meaningful contradictions versus topical drift.

Do not use this prompt when you need to verify claims against an external ground truth, when you need to resolve contradictions through external research, or when documents span incompatible domains. The prompt flags contradictions for human review—it does not resolve them. For workflows requiring automated conflict resolution, pair this with the Temporal Conflict Resolution Prompt or Source Credibility Weighting Prompt. For customer-facing Q&A where you must present a single answer despite conflicts, use the Conflict-Aware RAG Answer Generation Prompt Template instead. Always route outputs through a human review step when contradiction severity is rated critical or when the documents carry regulatory weight.

This prompt template is designed to be copied directly into your application or evaluation harness. It expects a set of documents, a target claim or topic to check for contradictions, and configuration parameters that control detection sensitivity and output structure. Every placeholder is enclosed in square brackets—replace each one with your actual data before sending the prompt to the model. The template is structured to produce a machine-readable JSON output that downstream systems can parse for review routing, alerting, or audit logging.

textCopy
You are a contradiction detection analyst reviewing a collection of documents. Your task is to identify specific contradictory statements across documents, cite the conflicting sources, rate severity, and recommend resolution actions.

## INPUT DOCUMENTS
[DOCUMENTS]

## TARGET CLAIM OR TOPIC
[CLAIM_OR_TOPIC]

## DETECTION CONFIGURATION
- Minimum contradiction confidence threshold: [CONFIDENCE_THRESHOLD]
- Severity levels to report: [SEVERITY_LEVELS]
- Maximum contradictions to return: [MAX_CONTRADICTIONS]
- Domain context: [DOMAIN]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "contradictions": [
    {
      "id": "string",
      "claim_a": {
        "text": "string",
        "source_id": "string",
        "source_section": "string",
        "source_date": "string or null"
      },
      "claim_b": {
        "text": "string",
        "source_id": "string",
        "source_section": "string",
        "source_date": "string or null"
      },
      "contradiction_type": "direct_contradiction | partial_contradiction | definitional_conflict | temporal_conflict | numerical_conflict | jurisdictional_conflict",
      "severity": "[SEVERITY_LEVELS]",
      "confidence": 0.0,
      "explanation": "string",
      "recommended_action": "escalate_to_human_review | flag_for_audit | resolve_with_newer_source | resolve_with_authoritative_source | note_dissenting_view | no_action",
      "action_rationale": "string"
    }
  ],
  "no_contradictions_found": false,
  "analysis_notes": "string"
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Compare every pair of documents for statements that cannot all be true simultaneously.
2. Only flag contradictions where confidence meets or exceeds the threshold.
3. For each contradiction, extract the exact text from both sources with precise section references.
4. Classify the contradiction type and assign a severity based on domain impact.
5. Recommend a resolution action with clear rationale.
6. If no contradictions meet the threshold, set `no_contradictions_found` to true and explain why in `analysis_notes`.
7. Do not fabricate contradictions. If sources appear to conflict but could be reconciled through interpretation, note this in `analysis_notes` and reduce confidence accordingly.

To adapt this template for your workflow, start by replacing [DOCUMENTS] with your actual document collection, formatted with clear source identifiers, section markers, and dates where available. Set [CONFIDENCE_THRESHOLD] to a value between 0.0 and 1.0—start at 0.7 for high-precision workflows like legal review, or lower to 0.5 for exploratory analysis where you prefer false positives over missed contradictions. Replace [SEVERITY_LEVELS] with your domain-specific taxonomy such as critical, major, minor, informational. The [CONSTRAINTS] placeholder should contain any additional rules, such as ignoring contradictions below a certain monetary threshold in financial documents or excluding known acceptable discrepancies. The [EXAMPLES] placeholder is critical for few-shot performance—include at least two annotated examples showing a clear contradiction and a non-contradiction that the model should not flag. After generation, validate the JSON output against the schema before routing to human review queues or audit systems. For high-stakes domains, always route contradictions flagged as critical or major severity to human review regardless of confidence scores.

This prompt is designed to be called as part of a batch or streaming document review pipeline, not as a one-off chat interaction. The application layer is responsible for chunking source documents, pairing them for comparison, calling the LLM with this prompt, and then validating the structured output before routing flagged contradictions to a human review queue. The prompt itself handles the reasoning and structured extraction; the harness handles the orchestration, safety checks, and downstream actions.

Input assembly: Before calling the prompt, the application must assemble the [DOCUMENT_A] and [DOCUMENT_B] fields with full text of the sections under comparison, plus [DOCUMENT_A_METADATA] and [DOCUMENT_B_METADATA] containing at minimum a source identifier, document date, author or department, and jurisdiction if relevant. The [CONTRADICTION_THRESHOLD] should be set as a numeric value (e.g., 0.7) representing the minimum confidence required to flag a contradiction. The [DOMAIN_CONTEXT] field should describe the review domain (e.g., 'M&A due diligence', 'regulatory filing review') to help the model calibrate severity. Output validation: Parse the model's JSON response and validate that each contradiction object contains all required fields: claim_a, claim_b, source_a_citation, source_b_citation, contradiction_type, severity, confidence, and recommended_action. Reject and retry any response missing these fields or containing malformed JSON. Use a schema validator like Pydantic or Zod before the output enters any downstream system.

Routing and human review: After validation, route contradictions based on severity. Critical and major contradictions should be pushed to a human review queue with the full contradiction payload, source excerpts, and a link to the original documents. Minor and informational contradictions can be logged for audit but may not require immediate human action. Implement a review interface that allows the human reviewer to confirm, dismiss, or reclassify each flagged contradiction. Retry logic: If the model returns invalid JSON or fails to produce the expected schema after two retries, log the failure with the raw output and document pair identifiers, then escalate to a human operator. Do not silently drop failed extractions. Model choice: Use a model with strong structured output capabilities and a context window large enough to hold both document sections plus the prompt. For high-stakes legal or compliance use cases, prefer a model with proven instruction-following and low hallucination rates on extraction tasks. Logging: Log every contradiction flagging call with the document pair identifiers, the contradiction count, severity distribution, and whether the output passed validation. This creates an audit trail for compliance reviews and helps detect prompt drift over time.

What to avoid: Do not use this prompt to compare more than two documents at once—the pairwise design is intentional to keep the model focused and the output schema manageable. For multi-document collections, run pairwise comparisons and aggregate results in the application layer. Do not treat the model's severity classification as final without human review for critical contradictions. Do not skip output validation; even models with strong JSON mode can produce missing fields or type errors under edge-case inputs. Finally, do not use this prompt for real-time user-facing Q&A—it is designed for asynchronous document review workflows where latency tolerance is higher and accuracy is paramount.