Cross-Document Fact Alignment Prompt

This prompt is designed for knowledge graph engineers, entity resolution pipeline builders, and RAG system architects who need to determine whether two or more documents are making the same factual claim or genuinely conflicting claims. It handles paraphrasing, synonymy, granularity differences, and numerical tolerance. Use this prompt when your system must align facts before merging knowledge bases, deduplicating entities, or surfacing conflicts to downstream systems.

This is not a general question-answering prompt. It assumes you have already extracted candidate claims and need to align them. It does not perform extraction, retrieval, or conflict resolution. It produces alignment judgments with explicit reasoning that your pipeline can act on. Do not use this prompt when you need to extract claims from raw text, resolve conflicts by choosing a winner, or generate end-user-facing answers. Those tasks belong to separate prompts in the Multi-Source Conflict and Consistency family.

Before deploying, pair this prompt with validation checks that verify the output schema contains both the alignment judgment and the reasoning field. For high-stakes domains such as legal or clinical knowledge bases, route low-confidence alignments to human review. The prompt works best when claims are already normalized to a common schema with fields for the claim text, source document identifier, and any numerical values with units.

This template is designed to be dropped directly into your entity resolution or knowledge graph construction pipeline. It takes a set of factual claims extracted from multiple documents and determines whether they refer to the same underlying fact, even when expressed through paraphrasing, synonymy, or different levels of granularity. The prompt distinguishes between sources that genuinely agree on a fact and those that appear to conflict due to wording differences or scope. Copy the template below, replace each square-bracket placeholder with your pipeline's data, and integrate the output into your downstream alignment resolver.

textCopy
You are a fact alignment engine. Your job is to compare factual claims extracted from multiple documents and determine whether they refer to the same underlying fact.

## INPUT
Claims to align:
[CLAIMS]

Each claim includes:
- claim_id: unique identifier
- source_document_id: document the claim came from
- claim_text: the factual statement as written
- extraction_date: when the claim was extracted
- entity_tags: entities referenced in the claim

## ALIGNMENT RULES
1. Two claims refer to the SAME fact if they assert the same real-world proposition, even if:
   - They use different words (paraphrasing)
   - They use synonyms or alternate entity names
   - One is more specific than the other (granularity difference)
   - They express the same value in different units or formats
2. Two claims CONFLICT if they make mutually exclusive assertions about the same entity, property, or event.
3. Two claims are DISTINCT if they address different facts entirely.
4. Claims from the SAME source document should not be flagged as conflicts unless the document internally contradicts itself.
5. When temporal information differs, check whether the claims refer to different time periods before flagging as conflict.

## OUTPUT SCHEMA
Return a JSON object with this structure:
{
  "alignment_groups": [
    {
      "group_id": "string",
      "canonical_fact": "string - the normalized statement of the agreed fact",
      "relationship": "same_fact | conflict | distinct",
      "claims": [
        {
          "claim_id": "string",
          "source_document_id": "string",
          "role": "supporting | conflicting | primary",
          "paraphrase_type": "exact_match | synonym_substitution | granularity_difference | unit_conversion | none",
          "confidence": 0.0-1.0
        }
      ],
      "alignment_notes": "string - explanation of why these claims are grouped"
    }
  ],
  "unmatched_claims": ["claim_id"],
  "conflicts_requiring_review": [
    {
      "group_id": "string",
      "conflict_type": "direct_contradiction | temporal_drift | definitional_difference | scope_mismatch",
      "severity": "critical | major | minor",
      "recommendation": "string"
    }
  ]
}

## CONSTRAINTS
- Do not invent facts to resolve conflicts.
- If two claims cannot be confidently aligned, place them in unmatched_claims.
- Flag any conflict where the resolution would change a downstream decision as severity "critical".
- For claims with confidence below 0.7, add them to conflicts_requiring_review.
- Never merge claims that differ on numerical values outside a 5% tolerance band.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

Adapt this template by adjusting the alignment rules to match your domain's tolerance for numerical variance, temporal granularity, and entity synonymy. The [EXAMPLES] placeholder should contain 2-4 annotated claim pairs showing clear same-fact alignment, genuine conflict, and granularity differences. For high-risk domains such as legal or clinical fact alignment, set [RISK_LEVEL] to high and add an explicit instruction requiring human review for any conflict group where severity is critical or major. The output schema is designed to feed directly into a downstream resolver or human review queue—do not modify the JSON structure without updating your ingestion pipeline accordingly. Before deploying, run this prompt against a golden set of pre-aligned claim pairs and measure both pairwise alignment accuracy and conflict detection recall.

This prompt is a component in a batch processing pipeline, not a real-time chat interface. It expects pre-retrieved document pairs or clusters containing potentially overlapping factual claims. The harness must handle document chunking, pair selection, and output normalization before the aligned facts enter a downstream knowledge graph or entity resolution system. Treat each invocation as a single alignment task for a specific set of claims or entity mentions across a bounded set of documents.

Input Assembly: The harness should construct the [DOCUMENTS] placeholder as a structured list of document objects, each containing doc_id, text (the relevant passage), and optional metadata (publication date, source authority, jurisdiction). For large document collections, pre-filter candidate pairs using embedding similarity or entity co-mention to avoid quadratic pair explosion. The [FOCUS_CLAIMS] placeholder should contain the specific factual statements or entity mentions to align, extracted by an upstream extraction step. Model Selection: Use a model with strong reasoning and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro). For high-throughput pipelines, consider a fine-tuned smaller model if alignment patterns are consistent. Validation: Parse the JSON output immediately. Validate that every aligned_fact has a non-empty source_claims array, that alignment_type is one of the allowed enum values (exact_match, paraphrase, more_specific, more_general, conflict, complementary), and that conflicting facts include a conflict_explanation string. Reject and retry outputs that fail schema validation.

Retry and Fallback Logic: If validation fails, retry with the same input and an appended error message in the [CONSTRAINTS] section specifying the exact validation failure. Limit retries to 2 attempts. If the model consistently fails to align certain fact pairs, log the raw input and output to a review queue for human annotation—these are likely genuinely ambiguous cases that need a canonical resolution rule. Logging and Audit: Log every alignment decision with the input document IDs, the raw model output, the validated output, and any retry attempts. For knowledge graph construction, this log serves as provenance evidence for every edge in the graph. Human Review Routing: Route outputs with alignment_type: "conflict" and confidence below 0.7 to a human review queue. Also route any fact where the model marks requires_human_judgment: true. The review interface should display the source passages side-by-side with the model's proposed alignment and conflict explanation, allowing annotators to confirm, override, or refine the alignment.

Downstream Integration: After validation, transform the alignment output into knowledge graph triples or entity resolution merge/split operations. For exact matches and paraphrases, this typically means merging entity nodes or linking them with an owl:sameAs relationship. For conflicts, create a :conflictsWith edge with the conflict explanation as a property. For complementary facts, link them with a :complements relationship. Eval Harness: Before production deployment, run this prompt against a golden dataset of 200+ document pairs with human-annotated alignments. Measure precision and recall on each alignment type separately—conflict detection often has lower recall than exact match detection. Set acceptance thresholds per alignment type based on the downstream tolerance for missed conflicts versus over-flagged conflicts in your domain.