Cross-Document Entity Resolution Prompt Template

This prompt is designed for intelligence, investigation, and data engineering teams who need to link entity references across multiple documents, deduplicate records, and produce a single merged profile with source citations. Use it when you have a collection of documents that mention the same real-world entity (person, organization, location, product) using different names, partial details, or conflicting attributes. The prompt instructs the model to act as a resolution engine: it identifies which mentions refer to the same entity, merges their attributes, flags conflicts, and attaches a confidence score to every link decision.

This is not a single-document extraction prompt. It assumes you have already extracted entity mentions from each document and are now feeding those mentions into the resolution step. The output is a structured entity profile ready for insertion into a master data management system, knowledge graph, or investigative case file. The ideal user is a data engineer or analyst who controls the extraction pipeline upstream and needs a reliable, auditable resolution step before ingestion.

Do not use this prompt when you need real-time streaming resolution, when entity mentions have not been pre-extracted, or when the documents share no common entity references. It is also unsuitable for resolving entities where the ground truth is unknowable without external authoritative databases—this prompt resolves mentions, not identities against a golden master. For high-stakes compliance or legal workflows, always route low-confidence merges to a human review queue and log every resolution decision with its evidence chain.

This template is designed for intelligence analysts, investigation teams, and data engineers who need to resolve entity references across multiple documents into a single merged profile. The prompt expects pre-extracted entity fragments from each source document—not raw text—and produces a structured output that includes the canonical entity, field-level provenance, merge confidence, and explicit conflict flags. Before using this prompt, ensure you have already run per-document extraction and have a list of candidate entity mentions that may refer to the same real-world person, organization, or object. Do not use this prompt when you need real-time streaming resolution, when source documents are not yet extracted, or when the entity type requires domain-specific normalization rules that haven't been applied upstream.

textCopy
You are an entity resolution specialist. Your task is to merge multiple partial entity profiles extracted from separate documents into a single canonical record. Each input profile represents a mention of what may be the same real-world entity. You must decide which profiles refer to the same entity, produce a merged canonical record, and document your evidence for every field.

## INPUT
You will receive a list of entity mention objects. Each object contains:
- mention_id: unique identifier for this mention
- source_document_id: identifier for the source document
- entity_type: PERSON, ORGANIZATION, LOCATION, PRODUCT, or OTHER
- fields: a dictionary of extracted attributes (may include name, aliases, date_of_birth, address, phone, email, identifiers, role, description, etc.)
- extraction_confidence: 0.0 to 1.0 confidence score from the extraction step
- source_span: the text span from which this entity was extracted

[ENTITY_MENTIONS]

## CONSTRAINTS
- Merge mentions only when you have sufficient evidence they refer to the same entity. When uncertain, keep them separate and flag the relationship as POSSIBLE_MATCH.
- For each merged field, cite the mention_id(s) that provided the value.
- If two mentions provide conflicting values for the same field (e.g., different birth dates), do not silently pick one. Record both in a conflicts array with source citations.
- Assign a merge_confidence score (0.0 to 1.0) reflecting your certainty that all merged mentions refer to the same entity.
- Flag any fields that are missing from all mentions as null with a reason: MISSING.
- Do not hallucinate values. Every output field must be traceable to an input mention.

## OUTPUT SCHEMA
Return a JSON object with this structure:
{
  "canonical_entities": [
    {
      "canonical_id": "string, a unique ID you generate for this merged entity",
      "entity_type": "PERSON | ORGANIZATION | LOCATION | PRODUCT | OTHER",
      "merged_fields": {
        "field_name": {
          "value": "the resolved value or null",
          "source_mentions": ["mention_id"],
          "confidence": 0.0
        }
      },
      "conflicts": [
        {
          "field_name": "string",
          "values": [
            {"value": "string", "source_mention": "mention_id"}
          ],
          "resolution_note": "string explaining why resolution wasn't possible"
        }
      ],
      "merge_confidence": 0.0,
      "merge_rationale": "string explaining the evidence for this merge",
      "unmerged_mentions": ["mention_id"]
    }
  ],
  "possible_matches": [
    {
      "mention_id_a": "string",
      "mention_id_b": "string",
      "similarity_score": 0.0,
      "evidence": "string describing why these might match",
      "recommendation": "HUMAN_REVIEW"
    }
  ],
  "processing_notes": ["string"]
}

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
[HIGH_RISK_FLAG: false]

To adapt this template for your workflow, replace the square-bracket placeholders before sending it to the model. The [ENTITY_MENTIONS] placeholder should contain your pre-extracted entity fragments as a JSON array—ensure each object includes the required fields (mention_id, source_document_id, entity_type, fields, extraction_confidence, source_span). The [FEW_SHOT_EXAMPLES] placeholder is optional but strongly recommended: include 2-4 worked examples showing correct merges, correct non-merges, and conflict handling. If your use case involves high-stakes decisions—such as watchlist matching, financial investigations, or legal proceedings—set the [HIGH_RISK_FLAG] to true and add an additional constraint requiring human review before any merge is finalized. For production deployments, validate the output against the schema before ingestion, log every merge decision with the input mentions and model response, and consider running a second-pass verification prompt on low-confidence merges (merge_confidence below 0.7) or any entry in the possible_matches array.

The Cross-Document Entity Resolution prompt is not a standalone tool—it is a component inside a larger entity resolution pipeline. The prompt expects a batch of document excerpts and a target entity type, and it returns a set of merged entity profiles. In production, you will typically call this prompt after a document ingestion step and before writing resolved entities to a master record store. The application layer is responsible for chunking documents, assembling the input context, calling the model, validating the output schema, and deciding what to do with low-confidence merges.

Input assembly and batching. Before calling the prompt, collect document excerpts that contain entity mentions. Each excerpt should include a stable document identifier and a snippet of surrounding text. The prompt template uses the [DOCUMENTS] placeholder, which expects a JSON array of objects with doc_id, text, and optional metadata fields. If you are processing a large corpus, batch documents into groups of 5–15 per prompt call to stay within context limits while giving the model enough cross-document signal. Avoid sending hundreds of documents in a single call—the model will miss cross-document links and hallucinate merges. For very large corpora, pre-cluster documents by shared attributes (date range, geography, topic) before sending them to the resolution prompt.

Output validation and schema enforcement. The prompt returns a JSON object with a resolved_entities array. Each resolved entity must contain canonical_name, entity_type, mentions (with doc_id and source_span), confidence_score, and merge_rationale. Validate the output against this schema immediately after the model responds. Use a JSON Schema validator to catch missing fields, type errors, and malformed structures. If validation fails, retry the prompt once with the validation error message appended to the [CONSTRAINTS] section. If the retry also fails, log the failure and route the batch to a human review queue. Do not silently accept malformed entity records into your master store.

Confidence thresholds and human review. The prompt produces a confidence_score between 0.0 and 1.0 for each resolved entity. Configure a threshold in your application (start with 0.7) below which merges are flagged for human review. For high-stakes domains like due diligence or compliance, route all merges below 0.9 to a review interface where an analyst can confirm, reject, or modify the merge decision. Log every human override to build a feedback dataset for future prompt improvements. The merge_rationale field is critical here—it gives the reviewer enough context to make a fast decision without re-reading all source documents.

Model choice and tool integration. This prompt works best with models that have strong reasoning and structured output capabilities, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Avoid smaller or older models that struggle with multi-document reasoning and consistent JSON output. If your application already uses a retrieval system, pass the top-k retrieved document excerpts directly into the [DOCUMENTS] placeholder rather than asking the model to search. For entity resolution at scale, consider pairing this prompt with a lightweight mention-extraction step that runs first, so the resolution prompt receives pre-extracted entity mentions rather than raw text. This reduces token usage and improves merge accuracy.

Logging, monitoring, and iteration. Log every prompt call with the input document count, output entity count, confidence distribution, validation pass/fail status, and human review rate. Monitor these metrics over time to detect drift—if the average confidence score drops or the human rejection rate rises, your source documents may have changed or the model may need a prompt update. Store resolved entities with their doc_id and source_span references so downstream systems can always trace a merged entity back to its original evidence. When you update the prompt template, run a regression test against a golden set of known entity pairs to catch regressions in merge quality before deploying to production.