Contact Record Deduplication Prompt Template

This prompt is designed for CDP and CRM engineering teams who need to deduplicate contact records that arrive from upstream model outputs, extraction pipelines, or multi-source ingestion. It handles pairwise comparison of contact records, assigns match confidence scores, applies survivorship rules to resolve conflicting field values, and produces a single deduplicated record with provenance tracking. Use this when you have two or more contact records that may represent the same person and you need a programmatic, auditable merge decision.

This prompt belongs in a post-extraction repair loop, not in initial record creation. It assumes contact records have already been normalized for email, phone, name, and address formatting. Pair this with the Email Address Normalization and Phone Number Canonicalization prompts earlier in your pipeline for best results. The prompt expects structured JSON input containing the candidate records to compare, along with your configured survivorship rules and match thresholds. It is not designed for bulk deduplication across millions of records—use it for pairwise or small-cluster resolution within a larger deduplication pipeline.

Do not use this prompt when you need real-time matching against a master database (use a vector search or deterministic matching service instead), when records lack any common identifiers to compare, or when legal or compliance requirements demand a human review every merge decision. For high-stakes merges in regulated domains, route low-confidence matches to a human review queue rather than relying solely on the model's survivorship decisions. The prompt's value is in making merge logic explicit, auditable, and consistent—not in replacing your MDM system.

This prompt template is designed to be pasted directly into your system instructions for an LLM tasked with merging duplicate contact records. It expects a pair of contact records and a set of business rules, and it returns a single deduplicated record with a detailed merge audit trail. The template uses square-bracket placeholders that you must replace with your specific data, schemas, and policies before use.

textCopy
You are a contact record deduplication engine for a Customer Data Platform (CDP).
Your task is to compare two contact records and produce a single, deduplicated golden record.

## INPUT
You will receive two contact records in [INPUT_FORMAT, e.g., JSON] format.
Record A: [RECORD_A]
Record B: [RECORD_B]

## OUTPUT_SCHEMA
Return a single JSON object with the following structure:
{
  "golden_record": {
    // The merged contact object conforming to [TARGET_SCHEMA]
  },
  "match_decision": {
    "is_match": boolean,
    "confidence_score": number (0.0 to 1.0),
    "match_reasoning": "string explaining the evidence for the match decision"
  },
  "merge_audit": [
    {
      "field_name": "string",
      "selected_source": "A" | "B" | "MERGED" | "CONFLICT",
      "value_a": "original value from Record A",
      "value_b": "original value from Record B",
      "resolved_value": "final value in golden_record",
      "resolution_rule": "string referencing the specific survivorship rule applied"
    }
  ]
}

## SURVIVORSHIP_RULES
Apply the following rules in order of precedence to resolve conflicts:
[SURVIVORSHIP_RULES, e.g.,
1. Prefer the most recently updated record's value.
2. Prefer the longer, more complete value.
3. Prefer the value from the record with a verified email or phone.
4. If still in conflict, flag for human review.]

## MATCHING_RULES
Two records are considered a match if they satisfy [MATCHING_CRITERIA, e.g.,
- Email addresses match exactly after normalization.
- OR, first name, last name, and phone number all match after normalization.
- Fuzzy name matching is allowed only if another strong identifier matches.]

## CONSTRAINTS
- Do not invent any contact data. Only use values present in Record A or Record B.
- If a field is missing in both records, set its value to null in the golden_record.
- For any field where the resolution rule results in a CONFLICT, set the resolved_value to null and flag it for human review.
- If the confidence_score is below [CONFIDENCE_THRESHOLD, e.g., 0.85], set is_match to false and do not produce a merged record. Instead, return both records unchanged in a "review_queue" array.
- Normalize all email addresses and phone numbers according to [NORMALIZATION_RULES] before comparison.

To adapt this template, start by replacing the [TARGET_SCHEMA] placeholder with the exact field definitions your downstream system expects. Then, codify your business's survivorship rules in [SURVIVORSHIP_RULES]—this is the most critical customization, as it encodes your data governance policy directly into the model's behavior. Finally, calibrate [CONFIDENCE_THRESHOLD] using a labeled evaluation set to balance merge throughput against the cost of false merges. For high-risk domains like healthcare or finance, set a high threshold and route all CONFLICT flags to a human review queue rather than attempting automatic resolution.

This prompt is designed to operate as a stateless function within a larger deduplication pipeline. It expects a pre-clustered pair of contact records as input, meaning your application must handle the initial blocking and candidate pair generation before invoking the model. The prompt should be called once per candidate pair, with results aggregated and resolved downstream. Do not use this prompt for list-wise deduplication of more than two records at a time; the pairwise comparison logic degrades when given more than two records, and the model will often hallucinate a consensus record rather than performing true pairwise analysis.

The implementation harness must enforce strict input validation before calling the model. Verify that both [RECORD_A] and [RECORD_B] contain the required fields specified in the prompt template, and reject any pair where mandatory identifiers are missing. After receiving the model output, validate the JSON structure against the expected schema: match_confidence must be a float between 0.0 and 1.0, is_match must be a boolean, merged_record must be present when is_match is true, and conflict_resolutions must be an array of objects with field, resolution, and reasoning keys. If validation fails, implement a retry loop with a maximum of two additional attempts, appending the validation error message to the prompt context. After two failed retries, route the pair to a human review queue rather than silently accepting a malformed output. Log every validation failure, retry attempt, and escalation event with the original input pair and the model's raw response for debugging.

Model choice matters for this workflow. Use a model with strong JSON output capabilities and a context window large enough to hold both records plus the prompt instructions. For high-volume pipelines, consider batching pairwise comparisons and using asynchronous calls with a concurrency limit to avoid rate limiting. Implement a confidence threshold in your application logic: pairs with match_confidence above 0.85 can be auto-merged, pairs between 0.5 and 0.85 should be flagged for human review, and pairs below 0.5 should be treated as non-matches. This threshold should be calibrated against your own labeled dataset, not assumed from generic benchmarks. Store the model's reasoning field alongside every decision to enable post-hoc audit and threshold tuning. Never auto-merge records in regulated domains (healthcare, finance) without a human-in-the-loop step, regardless of confidence score.