Contradiction Resolution Report Prompt

This prompt is designed for a specific, high-stakes moment in an automated fact-checking pipeline: the point where a single claim has been matched against multiple sources, and those sources disagree. It is not a general-purpose verification tool. Its sole job is to take a pre-identified claim and a set of conflicting evidence records, analyze the nature of the contradiction, compare the authority and recency of the sources, and produce a structured resolution report. The ideal user is a developer or engineer building a verification system who has already solved claim extraction and evidence retrieval, and now needs a reliable module to handle conflict arbitration before a final verdict is reached.

You should use this prompt when your system has already surfaced a direct contradiction—for example, Source A states a revenue figure of $10M while Source B reports $12M for the same period, or two credible outlets give opposing accounts of an event. The prompt assumes you have at least two evidence objects, each with a source identifier, a publication date, and the specific text that supports or contradicts the claim. Do not use this prompt for initial claim extraction, single-source verification, or for scoring the overall truthfulness of a document. It is also a poor fit for resolving vague, subjective disagreements where the conflict is a matter of interpretation rather than a verifiable factual clash. In those cases, the output will be noisy and the resolution logic will fail to add value.

Before integrating this prompt, ensure your upstream pipeline provides clean, structured inputs. The prompt's effectiveness is directly tied to the quality of the evidence objects you supply. A common failure mode is feeding it evidence that is topically related but does not directly address the same atomic claim, which causes the model to hallucinate a conflict or produce a false resolution. To mitigate this, implement a pre-check that validates evidence relevance to the specific claim before calling this prompt. After generation, you must validate the output against a strict schema and run an evaluation to confirm that the reported contradiction type is logically consistent with the provided evidence. In high-risk domains like finance or healthcare, the final resolution recommendation should always be treated as a draft for human review, not an automated decision.

This section provides a copy-ready prompt template that you can paste directly into your system. The template is designed to produce a structured contradiction resolution report when you have two or more sources making conflicting claims about the same factual matter. Replace the square-bracket placeholders with your specific claims, evidence sources, and output requirements before sending to the model. The template includes explicit instructions for comparing source authority, analyzing the nature of the contradiction, and recommending resolution or escalation paths.

textCopy
You are a contradiction resolution analyst. Your task is to examine conflicting claims across multiple evidence sources and produce a structured resolution report.

## INPUT

### Primary Claim Under Review
[CLAIM_TEXT]

### Conflicting Sources
For each source, provide the conflicting statement, source metadata, and the nature of the conflict.

Source A:
- Statement: [SOURCE_A_STATEMENT]
- Source Name: [SOURCE_A_NAME]
- Source Type: [SOURCE_A_TYPE] (e.g., peer-reviewed study, government report, news article, expert testimony, internal document)
- Publication Date: [SOURCE_A_DATE]
- Authority Indicators: [SOURCE_A_AUTHORITY] (e.g., author credentials, institutional affiliation, citation count)

Source B:
- Statement: [SOURCE_B_STATEMENT]
- Source Name: [SOURCE_B_NAME]
- Source Type: [SOURCE_B_TYPE]
- Publication Date: [SOURCE_B_DATE]
- Authority Indicators: [SOURCE_B_AUTHORITY]

[ADDITIONAL_SOURCES] (Optional: include up to [MAX_SOURCES] additional conflicting sources using the same format)

### Context
[CONTEXT] (Optional: background information, domain context, or related claims that help interpret the contradiction)

## OUTPUT SCHEMA

Produce a JSON object with the following structure:

{
  "report_id": "string (unique identifier for this resolution report)",
  "claim_under_review": "string (the original claim being examined)",
  "contradiction_summary": "string (one-sentence description of what the contradiction is about)",
  "contradiction_type": "string (one of: direct_factual_disagreement, temporal_inconsistency, numerical_discrepancy, definitional_conflict, methodological_disagreement, interpretation_divergence, scope_mismatch, other)",
  "source_comparison": {
    "source_a": {
      "authority_score": "string (one of: high, medium, low, unable_to_determine)",
      "authority_rationale": "string (brief explanation of the authority assessment)",
      "recency_assessment": "string (assessment of whether the source is current enough for this claim)",
      "relevance_score": "string (one of: directly_relevant, partially_relevant, tangentially_relevant)"
    },
    "source_b": {
      "authority_score": "string",
      "authority_rationale": "string",
      "recency_assessment": "string",
      "relevance_score": "string"
    },
    "comparative_analysis": "string (explanation of which source carries more weight and why)"
  },
  "resolution_analysis": {
    "can_resolve": "boolean (whether the contradiction can be resolved with available evidence)",
    "resolution": "string (explanation of how the contradiction can be resolved, or why it cannot)",
    "preferred_interpretation": "string (which source is more likely correct, with reasoning)",
    "confidence_level": "string (one of: high, medium, low, insufficient_evidence)",
    "remaining_uncertainties": ["string (list of specific uncertainties that remain after analysis)"]
  },
  "recommended_action": "string (one of: accept_source_a, accept_source_b, accept_neither, escalate_for_human_review, request_additional_evidence, flag_as_unresolvable)",
  "escalation_rationale": "string (if escalation is recommended, explain what specific expertise or evidence is needed)",
  "evidence_gaps": ["string (list of missing evidence that would help resolve the contradiction)"],
  "caveats": ["string (list of limitations, assumptions, or caveats in this analysis)"]
}

## CONSTRAINTS

1. Do not fabricate evidence or source details. If information is missing, mark it as "unavailable" or "unknown" rather than inventing it.
2. When comparing source authority, consider: institutional credibility, author expertise, publication venue rigor, recency, and relevance to the specific claim.
3. If the contradiction stems from different definitions, timeframes, or scopes rather than factual disagreement, classify it accordingly rather than forcing a binary resolution.
4. For numerical discrepancies, note the magnitude of difference and whether it falls within reasonable tolerance.
5. If both sources could be partially correct under different interpretations, explain those interpretations.
6. Never claim certainty when evidence is insufficient. Use "insufficient_evidence" confidence level when appropriate.
7. If the contradiction involves regulated domains (legal, medical, financial, safety-critical), always recommend human review unless the resolution is trivially verifiable.

## RISK LEVEL: [RISK_LEVEL] (one of: low, medium, high, critical)
- Low: General knowledge, non-controversial topics
- Medium: Topics with moderate stakes or public interest
- High: Regulated domains, safety implications, financial decisions
- Critical: Life-safety, legal liability, or major financial impact

If RISK_LEVEL is high or critical, add an additional field "human_review_required": true to the output and include specific review instructions.

To adapt this template for your pipeline, replace each square-bracket placeholder with actual data from your claim extraction and evidence retrieval stages. The [CLAIM_TEXT] should be the exact claim being verified, preserving original wording. Source fields should be populated from your evidence database or retrieval system. The [RISK_LEVEL] placeholder controls whether the output includes mandatory human-review flags—set this based on your domain's regulatory requirements and the claim's potential impact. If you have more than two conflicting sources, use the [ADDITIONAL_SOURCES] placeholder and adjust [MAX_SOURCES] to your pipeline's capacity. The output schema is designed for direct ingestion into verification databases, audit trails, or reviewer dashboards.

Before deploying this prompt into production, validate that your upstream systems can reliably populate all required source metadata fields. Missing authority indicators or publication dates will degrade the model's ability to compare sources accurately. Implement pre-flight validation that checks for empty placeholders and rejects malformed inputs before they reach the model. For high-risk domains, add a post-processing step that verifies the human_review_required field is present and correctly set before any automated action is taken based on the resolution recommendation.

The Contradiction Resolution Report prompt is designed to be a single step within a larger fact-checking pipeline. It should be invoked only after claim extraction and evidence matching have been completed for a specific claim. The prompt expects a pre-assembled set of conflicting evidence sources, not raw documents. In a production system, a retrieval step should first gather candidate evidence, an evidence matching step should pair it with the claim, and a contradiction detection step should flag the claim as having conflicting evidence before this prompt is called. Calling this prompt on claims without verified conflicts wastes compute and can produce misleading 'no contradiction found' reports that mask real evidence gaps.

Wire this prompt into your application as a gated step. The input should be a structured object containing the original claim, an array of conflicting evidence sources with their authority scores, and the verification context. The output must be validated against a strict JSON schema before being stored or forwarded. Implement a validation layer that checks for required fields: contradiction_id, claim_id, conflicting_sources, resolution_recommendation, and escalation_flag. If the model returns malformed JSON, use a repair prompt from the Output Repair and Validation playbook to fix structural errors before retrying. For high-stakes domains like healthcare or finance, always set escalation_flag to true by default in your application logic and require human review before accepting any automated resolution. Log every invocation with the model version, input hash, output, and validation result for audit trails.

Model choice matters for this task. Use a model with strong reasoning capabilities and a large context window, as the prompt requires comparing multiple evidence sources and their authority metadata. GPT-4o or Claude 3.5 Sonnet are suitable defaults. For cost-sensitive pipelines, consider routing only high-authority-conflict claims to a larger model and handling low-stakes contradictions with a smaller model. Implement a retry strategy with exponential backoff for transient failures, but cap retries at three attempts. If the output fails validation after three retries, route the claim to a human review queue with the raw evidence and a failure note. Never silently accept an unvalidated contradiction resolution report in production—an incorrect resolution can propagate false confidence downstream into verification summaries and audit packages.