Pairwise Claim Comparison Prompt for Contradiction Flagging

This prompt is designed for a single, precise task within a larger fact-checking pipeline: comparing two atomic claims to determine if they contradict each other. It is not a document-level comparison tool, a multi-source triangulation engine, or a general-purpose fact-checker. The ideal user is a developer or engineer who has already decomposed source material into discrete, self-contained claims and now needs a reliable pairwise comparison logic. The prompt expects two clean claim strings as input and returns a structured verdict with a relationship label—such as 'direct contradiction', 'partial mismatch', 'compatible', or 'unrelated'—and a confidence score. This output is a building block for downstream evidence matching, conflict resolution, or human review routing.

Use this prompt when your workflow requires a high-precision filter for conflicting information before you invest in expensive retrieval or human review steps. It is particularly effective in pre-processing stages where you need to flag direct contradictions (e.g., 'The event occurred on Tuesday' vs. 'The event occurred on Wednesday') and distinguish them from partial mismatches that may arise from different scopes or levels of detail (e.g., 'The project cost $5 million' vs. 'The initial phase cost $2 million'). The prompt's confidence score allows you to set a threshold for automated action: high-confidence contradictions can be routed for immediate correction, while low-confidence mismatches can be queued for human review. You should not use this prompt for claims that are not atomic, for comparing more than two claims at once, or for making final editorial judgments in high-stakes domains like legal filings or medical diagnoses without human oversight.

Before integrating this prompt, ensure your upstream claim extraction process produces truly atomic statements. A common failure mode is feeding this prompt compound claims that contain multiple assertions, which degrades the relationship classification accuracy. The next step after reading this section is to review the prompt template and adapt its placeholders to your specific claim schema and output format requirements. If your use case involves comparing claims across more than two sources, you will need to compose this pairwise prompt into a broader orchestration layer, which is covered in the implementation harness section.

This prompt template is the core instruction set for a pairwise claim comparison task. It instructs the model to act as a precise contradiction detector, comparing two atomic claims and classifying their relationship. The prompt is designed to be self-contained; you can copy it directly into your system, replace the placeholders with your data, and receive a structured JSON output. The primary goal is to force a clear, non-ambiguous verdict on whether two claims conflict, while also capturing the nuance of partial mismatches and unrelated statements.

textCopy
You are a precise contradiction detection engine. Your task is to compare two atomic claims and determine their logical relationship. You must output only a single, valid JSON object with no surrounding text, markdown fences, or commentary.

### INPUT CLAIMS
Claim A: [CLAIM_A]
Claim B: [CLAIM_B]

### CONTEXT (Optional)
[CONTEXT]

### CLASSIFICATION RULES
Analyze the claims and assign one of the following relationship labels:
- **direct_contradiction**: The claims cannot both be true simultaneously. They assert mutually exclusive facts.
- **partial_mismatch**: The claims overlap in subject but differ on a specific detail, quantity, scope, or temporal aspect. They are not fully compatible.
- **compatible**: The claims can both be true. They do not conflict and may support or elaborate on each other.
- **unrelated**: The claims address different subjects, entities, or events with no meaningful overlap.

### OUTPUT SCHEMA
{
  "verdict": "direct_contradiction" | "partial_mismatch" | "compatible" | "unrelated",
  "confidence": 0.0-1.0,
  "explanation": "A concise, one-sentence explanation of the logical relationship, referencing specific details from both claims.",
  "conflict_details": {
    "subject": "The shared subject or entity, or null if unrelated.",
    "point_of_conflict": "The specific detail that is in conflict, or null if compatible or unrelated.",
    "resolution_possible": true | false
  }
}

### CONSTRAINTS
- Base your verdict strictly on the provided text and context. Do not introduce external knowledge.
- If the claims use different terminology for the same concept, treat them as compatible unless a factual conflict exists.
- For `partial_mismatch`, the `point_of_conflict` field is mandatory.
- Set `resolution_possible` to `true` only if the conflict can be resolved by clarifying scope, time, or definitions without changing the core facts.

To adapt this template, replace the [CLAIM_A], [CLAIM_B], and [CONTEXT] placeholders with your data. The [CONTEXT] field is optional but highly recommended for domain-specific or ambiguous claims; it can include the source paragraph, document metadata, or a glossary of terms. For high-stakes verification pipelines, you should calibrate the confidence score by running this prompt against a golden dataset of labeled claim pairs and mapping the model's raw scores to your operational thresholds. The output schema is intentionally flat to simplify parsing in downstream code. If you need to integrate this into a larger pipeline, wrap this prompt in an application harness that validates the JSON, checks for required fields, and retries on malformed output before the verdict reaches any automated decision point.

The pairwise claim comparison prompt is designed as a single atomic step within a larger fact-checking pipeline. It expects two pre-extracted claims as input and returns a structured contradiction verdict. In production, this prompt should be called after a claim extraction step and before any evidence aggregation or report generation step. The harness is responsible for batching claim pairs, enforcing the output schema, handling model failures, and routing ambiguous results for human review. Do not use this prompt as a standalone fact-checking tool—it does not retrieve evidence, assess source authority, or resolve multi-source conflicts. Its job is narrow: compare two claims and classify their relationship.

Schema enforcement and validation are the first harness layer. The prompt template includes an [OUTPUT_SCHEMA] placeholder that should be populated with a strict JSON schema requiring fields such as claim_a, claim_b, relationship (enum: direct_contradiction, partial_mismatch, compatible, unrelated), confidence (float 0.0–1.0), explanation (string), and requires_review (boolean). After the model responds, validate the output against this schema before passing it downstream. Reject malformed JSON, missing required fields, enum violations, or confidence values outside bounds. For high-stakes domains, add a semantic validation step: if relationship is direct_contradiction but confidence is below 0.7, flag for review. If requires_review is true but no explanation is provided, reject and retry. Log every validation failure with the raw model output and the claim pair for debugging.

Retry and fallback logic should handle transient model failures and ambiguous outputs. Implement a retry policy with exponential backoff (starting at 1 second, max 3 retries) for HTTP errors, timeouts, and schema validation failures. On the second retry, append a brief correction instruction to the prompt: Your previous output was invalid. Ensure the response matches the required JSON schema exactly. If all retries fail, route the claim pair to a human review queue with the raw claims and any partial model output. For partial_mismatch verdicts with confidence between 0.4 and 0.6, consider a second pass with a different model or a more detailed prompt variant that asks the model to explain the specific dimension of mismatch before classifying. Do not silently accept low-confidence outputs as ground truth.

Threshold calibration and tie-breaking are critical for production accuracy. The prompt includes a [CONSTRAINTS] placeholder where you should specify decision boundaries: for example, 'Classify as direct_contradiction only when both claims cannot be true simultaneously under any reasonable interpretation. Classify as partial_mismatch when claims differ in scope, specificity, or condition but do not logically exclude each other.' Run a calibration set of 50–100 labeled claim pairs through the harness and plot confidence scores against human labels. Adjust the [CONSTRAINTS] language and the downstream routing thresholds until false positive and false negative rates meet your application's tolerance. For tie-breaking between partial_mismatch and compatible, add a rule: if the model's explanation mentions scope difference, temporal mismatch, or conditional qualifiers, default to partial_mismatch unless confidence in compatible exceeds 0.85.

Model choice and latency budgeting affect harness design. For high-throughput pipelines processing thousands of claim pairs, use a fast model (e.g., GPT-4o-mini, Claude Haiku) with a strict 2-second timeout and batch pairs into groups of 10–20 per request if the model supports it. For high-accuracy pipelines where each contradiction flag triggers an expensive human review, use a more capable model (e.g., GPT-4o, Claude Sonnet) and accept higher latency per pair. Implement a cost-aware router: if the claim pair comes from a low-risk content category, use the fast model; if it comes from a regulated domain or high-visibility content, escalate to the accurate model. Log model identity, latency, and token usage per comparison for cost attribution.

Integration with upstream and downstream steps requires clean handoffs. The harness should receive claims from an extraction step that guarantees atomicity—each claim is a single verifiable assertion with preserved source context. Before calling the comparison prompt, check that both claims are non-empty, under 500 characters, and contain at least one factual predicate. If either claim fails these checks, skip the comparison and flag the extraction step. After the comparison prompt returns a validated verdict, write the result to a structured log with a unique comparison_id, both claim IDs, the verdict, confidence, explanation, model version, and timestamp. Downstream steps—evidence matching, report generation, human review routing—should consume this log, not the raw model output. This decoupling lets you swap models, adjust thresholds, or replay comparisons without rebuilding the pipeline.