Pairwise Source Comparison Prompt with Conflict Output Contract

This prompt is designed for API developers and verification engineers who need to integrate a deterministic fact-checking step into a production pipeline. The core job-to-be-done is comparing two source documents—typically raw text or structured evidence records—and receiving a structured JSON output that identifies factual conflicts. The ideal user is building a system where downstream services, databases, or monitoring dashboards consume conflict records programmatically. You should use this prompt when you need typed conflict fields (e.g., direct_contradiction, numerical_discrepancy), explicit provenance links that map each conflicting claim back to its source document and location, and a machine-actionable verdict that requires no human parsing. The required context includes two complete source documents, a defined output schema, and a clear specification of what constitutes a reportable conflict versus an acceptable paraphrase or stylistic difference.

Do not use this prompt for open-ended editorial analysis where a human reader expects a narrative summary, nor for single-document review workflows that lack a comparative source. It is also unsuitable for end-user-facing chat interfaces where the raw JSON output would be confusing or where the latency of a structured generation step degrades the user experience. Avoid this prompt when the source documents contain primarily subjective claims, opinions, or speculative statements that lack a ground-truth reference; the prompt's conflict typing logic relies on verifiable factual assertions. If your workflow requires resolving contradictions across three or more sources, use a multi-source triangulation prompt instead, as this pairwise design does not handle weighted consensus or majority-rules logic. Finally, if your application cannot tolerate a structured output failure—for example, in a synchronous user-facing flow with no retry budget—consider whether a simpler classification prompt or a human-in-the-loop review step is more appropriate before committing to a strict schema contract.

To implement this successfully, you must pair the prompt with a validation harness that checks the output against the expected JSON schema before the response is passed downstream. The harness should verify required fields (conflict_id, claim_a, claim_b, conflict_type, verdict, provenance), validate enum values for conflict_type and verdict, and confirm that provenance links reference the correct source identifiers provided in the input. Integration test cases should include known contradictory document pairs, known consistent pairs, and edge cases such as empty documents, identical documents, and documents that differ only in formatting or synonym choice. For high-stakes verification domains—such as legal, financial, or clinical evidence review—always route the structured output through a human approval queue before any automated action is taken based on the conflict verdict. The prompt itself is a component, not a complete solution; its reliability depends on the surrounding validation, retry, and review infrastructure you build around it.

This prompt template is the core instruction set for a pairwise source comparison task. It is designed for API developers and verification engineers who need a machine-readable output contract, not a prose summary. The prompt forces the model to identify only factual conflicts—statements that cannot both be true—while ignoring differences in phrasing, scope, or interpretation. Use this when you need to feed conflict data directly into a downstream system, such as a fact-checking dashboard, a RAG pipeline's post-retrieval filter, or an automated evidence-grading service. Do not use this prompt for general document summarization or for generating human-facing reports without further processing; its value is in the strict JSON schema it enforces.

textCopy
You are a precise contradiction detection engine. Your task is to compare two provided source documents and identify all factual conflicts. A factual conflict exists when two statements assert incompatible facts about the same specific entity, event, time, or measurement, such that both cannot be true simultaneously.

Ignore differences in phrasing, writing style, level of detail, or scope. Do not flag a conflict if one source is merely silent on a detail mentioned by the other. Do not flag opinions, predictions, or interpretations as conflicts unless they contain a core factual assertion that is directly contradicted.

## INPUTS
- Source A: [SOURCE_A_TEXT]
- Source B: [SOURCE_B_TEXT]
- Source A Identifier: [SOURCE_A_ID]
- Source B Identifier: [SOURCE_B_ID]

## OUTPUT SCHEMA
Return ONLY a valid JSON object conforming to this exact schema. Do not include any text outside the JSON object.

{
  "conflicts": [
    {
      "conflict_id": "string, unique identifier for this conflict, e.g., 'C01'",
      "claim_a": "string, the exact verbatim text from Source A that contains the conflicting assertion",
      "claim_b": "string, the exact verbatim text from Source B that contains the conflicting assertion",
      "entity_or_event": "string, the specific subject the conflict is about",
      "conflict_type": "enum, one of: 'direct_numerical', 'direct_factual', 'temporal_ordering', 'entity_identity'",
      "verdict": "string, a brief, machine-readable explanation of why these statements cannot both be true",
      "provenance": {
        "source_a_id": "[SOURCE_A_ID]",
        "source_b_id": "[SOURCE_B_ID]",
        "claim_a_char_start": "integer or null",
        "claim_a_char_end": "integer or null",
        "claim_b_char_start": "integer or null",
        "claim_b_char_end": "integer or null"
      }
    }
  ],
  "unresolvable_ambiguities": [
    {
      "claim_a": "string",
      "claim_b": "string",
      "reason": "string, explanation of why a conflict could not be definitively confirmed or ruled out"
    }
  ]
}

## CONSTRAINTS
- If no conflicts are found, return an empty 'conflicts' array.
- If a potential conflict is ambiguous due to missing context, place it in 'unresolvable_ambiguities', not 'conflicts'.
- For provenance fields, provide character start and end indices for the exact conflicting text within the original source strings. If you cannot determine the exact location, use null.
- Do not invent conflicts. Your precision is more important than recall.

To adapt this template, replace the square-bracket placeholders with your actual data before sending the request. The [SOURCE_A_TEXT] and [SOURCE_B_TEXT] fields should contain the full document bodies you are comparing. The [SOURCE_A_ID] and [SOURCE_B_ID] should be persistent, unique identifiers (like a document UUID or database key) that will travel with the output to maintain a clear chain of custody. In a production harness, you must validate the model's response against this JSON schema before accepting it. A common failure mode is the model omitting the provenance fields or adding commentary outside the JSON object; your application logic should retry or repair the output if schema validation fails. For high-stakes verification, always route outputs with a high number of conflicts or unresolvable ambiguities for human review before taking action.

The Pairwise Source Comparison Prompt is designed for API integration, not a one-off chat. Its primary value is the structured JSON conflict output contract, which downstream systems can parse, log, and act on. To use it in production, wrap the prompt in a service that manages the full lifecycle: input assembly, model invocation, output validation, retry logic, and result routing. The prompt itself expects two source texts ([SOURCE_A] and [SOURCE_B]), an optional [CLAIM_FOCUS] to narrow the comparison scope, and a [CONFLICT_OUTPUT_SCHEMA] that defines the exact JSON shape you need. The schema should include typed fields for the conflict verdict, conflicting excerpts, relationship classification, confidence score, and provenance links back to each source.

The implementation harness must enforce output contract compliance before the result reaches any consumer. After the model returns a response, run a JSON schema validator against the expected [CONFLICT_OUTPUT_SCHEMA]. Check that all required fields are present, enum values match allowed sets, confidence scores fall within the 0.0–1.0 range, and excerpt strings are non-empty when a conflict is flagged. If validation fails, implement a retry loop with a maximum of two additional attempts, appending the validation error to the prompt context so the model can self-correct. For high-stakes verification pipelines, route outputs with confidence scores in an ambiguous band (e.g., 0.4–0.6) to a human review queue with the full prompt context and raw model response attached. Log every invocation—including model, latency, token counts, validation pass/fail, and retry count—to enable prompt observability and regression testing over time.

Model choice matters for this workflow. The prompt requires precise, schema-adherent JSON generation and careful semantic comparison of potentially long source texts. Use models with strong instruction-following and structured output capabilities, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Avoid smaller or older models that may hallucinate conflict fields or drop required provenance links. If your application compares sources that exceed the model's context window, pre-process with a chunking strategy that preserves paragraph boundaries and overlap, then run pairwise comparisons across aligned chunks and aggregate results. Do not use this prompt for real-time user-facing chat without first wrapping it in the validation harness—raw model output without schema enforcement will produce brittle, unparseable results in production.