Direct Contradiction vs. Partial Mismatch Classification Prompt

This prompt is for verification system architects and fact-checking pipeline developers who need to move beyond binary true/false labels and into fine-grained conflict categorization. The core job is to classify a pair of statements into one of several relationship types—such as direct contradiction, partial mismatch, compatible, or unrelated—and to produce a structured, machine-readable output that includes definitions, evidence, and a confidence score. The ideal user is someone building an automated verification pipeline where downstream actions depend on the type of conflict detected: a direct contradiction might trigger immediate flagging, while a partial mismatch might be routed for human review. Required context includes the two statements to compare, any shared source metadata, and a defined taxonomy of conflict types. Do not use this prompt when you only need a simple yes/no contradiction verdict; use the Pairwise Claim Comparison Prompt for Contradiction Flagging for that narrower task. This prompt is also inappropriate for comparing more than two statements at once, for which you should use the Multi-Source Contradiction Resolution Prompt Template.

The primary value of this classification prompt is its ability to reduce false positives in contradiction detection pipelines. A naive system might flag 'The report was published in July' and 'The report came out last summer' as a contradiction, when they are actually compatible paraphrases. This prompt forces the model to distinguish genuine logical incompatibility from differences in scope, granularity, hedging language, or temporal context. To implement this effectively, you must provide a clear taxonomy in the [CONTRADICTION_TAXONOMY] variable. A production-grade taxonomy typically includes categories like direct_contradiction (both cannot be true simultaneously), partial_mismatch (disagree on a specific attribute but not the core claim), scope_difference (different levels of generality), hedging_discrepancy (one is definitive, the other probabilistic), temporal_context_shift (different timeframes), and compatible (no conflict). Each category should have a crisp definition and at least one contrasting example. Without this taxonomy, the model will default to an inconsistent, ad-hoc classification that breaks downstream automation.

Before deploying this prompt, build a small golden dataset of 50-100 statement pairs with known classifications, including tricky edge cases like negations, double negatives, and numerical approximations. Run the prompt against this dataset and measure inter-rater reliability against your own labels. Pay special attention to the partial_mismatch vs. compatible boundary, as this is where most production systems leak false positives. If your use case involves regulated content (financial disclosures, clinical trial data, legal filings), add a [RISK_LEVEL] parameter and route any direct_contradiction finding with confidence below 0.9 to a human review queue. Never treat this prompt's output as ground truth without a human-in-the-loop escape hatch for high-stakes claims.

The prompt below is designed to be copied directly into your verification pipeline. It accepts two claims and supporting context, then outputs a structured classification with a label, confidence score, and a concise rationale grounded in the provided definitions. The square-bracket placeholders let you inject your specific inputs, output schema, and operational constraints without rewriting the core logic.

textCopy
You are a contradiction classification engine. Your task is to compare two claims and determine their logical relationship.

## Definitions
- **Direct Contradiction**: Both claims cannot be true at the same time in the same respect. They assert mutually exclusive facts.
- **Partial Mismatch**: The claims overlap in subject but differ in scope, magnitude, timeframe, or specific detail without being logically impossible to reconcile.
- **Compatible**: The claims can both be true simultaneously. They may address different aspects, time periods, or conditions.
- **Unrelated**: The claims address entirely different subjects with no overlapping factual territory.

## Input
**Claim A:** [CLAIM_A]
**Claim B:** [CLAIM_B]
**Shared Context (optional):** [SHARED_CONTEXT]

## Output Schema
Return a single JSON object with the following fields:
{
  "label": "direct_contradiction" | "partial_mismatch" | "compatible" | "unrelated",
  "confidence": 0.0-1.0,
  "rationale": "Concise explanation referencing specific claim elements and the definition that applies.",
  "requires_human_review": true | false
}

## Constraints
[CONSTRAINTS]

## Examples
[EXAMPLES]

## Risk Level
[RISK_LEVEL]

To adapt this template, replace each placeholder with concrete values. [CLAIM_A] and [CLAIM_B] should be single, atomic factual assertions extracted from your claim decomposition step. [SHARED_CONTEXT] can include the source document excerpts, timestamps, or domain metadata that help disambiguate scope. Use [CONSTRAINTS] to inject operational rules such as 'Set requires_human_review to true for any confidence below 0.85' or 'Never classify numerical claims as compatible without explicit tolerance windows.' Populate [EXAMPLES] with 3-5 few-shot demonstrations covering each label, including edge cases like hedging language and conditional statements. Set [RISK_LEVEL] to 'high' for regulated domains to trigger downstream human-review routing in your harness.

Before deploying, validate that your populated prompt produces the exact JSON schema your pipeline expects. Test it against a golden set of 20+ labeled pairs covering all four classes, including ambiguous cases where partial mismatch and compatible are hard to distinguish. If your application cannot tolerate a misclassification, add a post-processing validator that rejects outputs missing required fields or containing confidence scores outside the 0-1 range, then trigger a retry or escalation. For high-stakes verification, always route requires_human_review: true outputs to a review queue with the original claims and context attached.

This prompt is designed as a classification microservice within a larger fact-checking or contradiction detection pipeline. It should not be exposed directly to end users. Instead, wrap it in an application layer that provides the two claims and their surrounding context, enforces the output schema, and routes the result to downstream consumers—such as a severity scorer, a contradiction resolution module, or a human review queue. The prompt expects a pair of claims with optional context snippets, and it returns a structured classification label (direct_contradiction, partial_mismatch, compatible, unrelated) along with a confidence score and a concise rationale. The application harness is responsible for supplying the inputs, validating the output, and deciding what to do with each classification.

Input assembly and pre-processing: Before calling the model, extract the two claims to compare from your upstream claim extraction or retrieval system. Include the original source text surrounding each claim as the [CONTEXT_A] and [CONTEXT_B] variables. This context is critical—without it, the model cannot distinguish a genuine contradiction from a scope difference or a domain shift. If your pipeline processes long documents, truncate the context to the paragraph or section containing the claim, plus one adjacent paragraph for framing. For multi-source comparisons, include the source identifier and publication date in the context string. Model choice: Use a model with strong reasoning capabilities (e.g., GPT-4o, Claude 3.5 Sonnet) for this task. Smaller or faster models often conflate partial mismatches with direct contradictions, inflating false positives. If latency or cost constraints require a smaller model, implement a confidence threshold (e.g., 0.85) below which classifications are escalated to a stronger model or a human reviewer.

Output validation and retry logic: The prompt instructs the model to return a JSON object with label, confidence, and rationale fields. Your harness must validate this output before accepting it. Check that label is one of the four allowed enum values. Verify that confidence is a float between 0.0 and 1.0. Confirm that rationale is a non-empty string that references specific elements from the provided claims and context. If validation fails, retry once with the same input and a stronger constraint instruction appended (e.g., 'Your previous response was invalid. You MUST return only the JSON object with exactly the fields: label, confidence, rationale.'). If the second attempt also fails, log the failure, route the claim pair to a human review queue, and emit an observability event. Human review routing: Classifications with confidence below a configurable threshold (start with 0.7 and calibrate against your tolerance for false positives) should be routed for human review. Additionally, all direct_contradiction classifications in high-risk domains (legal, medical, financial) should require human confirmation before downstream action. Package the original claims, context, model output, and a link to the source documents into a structured review task.

Integration with downstream systems: When the classification is direct_contradiction, your pipeline should trigger contradiction resolution workflows—such as source authority weighting, corroboration checks, or evidence re-retrieval. When the classification is partial_mismatch, log the pair for trend analysis; repeated partial mismatches between the same sources may indicate systematic bias or outdated information. Compatible and unrelated pairs can be discarded or logged for audit trails. Observability and evaluation: Log every classification with the input claims, context, model version, output, validation status, and routing decision. Use these logs to build a golden evaluation dataset over time. Periodically sample classifications and have domain experts label them to measure precision and recall. Pay special attention to false positives where partial_mismatch pairs are misclassified as direct_contradiction—this is the most common production failure mode and can erode trust in your verification pipeline. Adjust the prompt's decision boundary language or the confidence threshold based on these eval results.