Multi-Source Contact Record Reconciliation Prompt Template

This prompt is designed for Customer Data Platform (CDP) operators and data engineers who need to merge contact records arriving from multiple AI pipelines, APIs, or batch ingestion jobs into a single golden record. The job-to-be-done is not simple deduplication—it is conflict resolution across sources with different freshness, reliability, and completeness profiles. Use this prompt when you have two or more partial or conflicting contact records for the same person or entity and you need a single reconciled output that preserves source precedence rules, field-level provenance, and staleness handling. The ideal user has already run identity resolution to cluster records belonging to the same entity and now needs to collapse each cluster into one trustworthy record.

Do not use this prompt for initial identity matching or pairwise deduplication—those are upstream tasks covered by the Contact Record Deduplication Prompt Template. Do not use it when all sources agree, as the reconciliation overhead adds latency without benefit. This prompt is also inappropriate when source reliability is unknown or unquantified; you must supply explicit source precedence rules and freshness metadata. If your pipeline cannot provide source_priority_order, record_timestamps, or field_completeness per source, stop and instrument your ingestion layer before attempting reconciliation. For regulated contact data (GDPR, CCPA), always route the final golden record through human review before committing to a system of record—this prompt produces a candidate record, not an audited decision.

The prompt expects structured inputs: a list of candidate records with source identifiers, timestamps, and optional confidence scores. It outputs a reconciled record with a survivorship_map showing which source won each field and why. Before deploying, build a test harness that validates: (1) the highest-priority source wins when it has a non-null value, (2) stale records lose to fresher records from lower-priority sources when staleness thresholds are exceeded, (3) the output never invents fields not present in any input, and (4) the provenance map is complete and auditable. Start with a small set of known-conflict clusters, verify the reconciliation logic matches your business rules, then scale to batch processing with a human-in-the-loop checkpoint for low-confidence merges.

This prompt template is designed to be copied directly into your application code or prompt management system. It accepts multiple contact records from different sources, applies configurable precedence rules, resolves conflicts, and produces a reconciled golden record with field-level provenance. The template uses square-bracket placeholders that you must replace with your actual data and configuration before sending to the model. Every placeholder is documented so you can wire this into a CDP pipeline, CRM ingestion flow, or identity resolution system without guessing what each variable should contain.

textCopy
You are a contact record reconciliation engine. Your task is to merge multiple contact records that may represent the same person into a single reconciled golden record.

## INPUT RECORDS
[RECORDS]

## SOURCE PRECEDENCE RULES
When the same field has conflicting values across sources, resolve using this priority order:
[SOURCE_PRECEDENCE]

## CONFLICT RESOLUTION POLICY
[CONFLICT_POLICY]

## STALENESS THRESHOLD
Records older than [STALENESS_DAYS] days should be treated as low-confidence and flagged for review unless corroborated by a fresher source.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "golden_record": {
    "contact_id": "string (generated UUID v4)",
    "fields": {
      "[FIELD_NAME]": {
        "value": "any",
        "confidence": "high | medium | low",
        "source": "string (source identifier)",
        "conflict_resolved": true | false
      }
    }
  },
  "provenance": {
    "source_records_used": ["source_id"],
    "source_records_discarded": ["source_id"],
    "discard_reasons": {"source_id": "string"},
    "reconciliation_timestamp": "ISO 8601"
  },
  "conflicts": [
    {
      "field": "string",
      "conflicting_values": ["value"],
      "resolution_method": "precedence | recency | majority_vote | manual_review_required",
      "selected_value": "any",
      "justification": "string"
    }
  ],
  "review_required": true | false,
  "review_reasons": ["string"]
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Identify which input records likely represent the same person using available identifiers.
2. For each field, select the best value using source precedence rules and conflict resolution policy.
3. Flag any field where confidence is low or where automated resolution is unreliable.
4. Track exactly which source contributed each field value.
5. If staleness rules apply, downgrade confidence on old records.
6. Set review_required to true if any conflict requires human judgment.
7. Output only the JSON object. No markdown, no commentary.

To adapt this template, replace each bracketed placeholder with your actual data and rules. [RECORDS] should contain the raw contact records as JSON objects, each with a source identifier and timestamp. [SOURCE_PRECEDENCE] should be an ordered list of source names from most to least trusted. [CONFLICT_POLICY] defines your resolution strategy: precedence uses source ranking, recency picks the newest value, majority_vote requires agreement across sources, and manual_review_required escalates to a human. [CONSTRAINTS] lets you add domain-specific rules like "email must be RFC 5322 compliant" or "phone must be E.164 format." [EXAMPLES] should include at least one clean reconciliation and one conflict-heavy case to anchor model behavior. Before deploying, validate that the model reliably produces the exact output schema by running at least 20 test cases through your eval harness and checking for missing provenance fields, hallucinated source identifiers, and incorrect conflict resolution.

This prompt is designed to be called as a single step within a larger contact ingestion or merge pipeline. The application layer should first collect all candidate records for a given entity, assemble them into the [SOURCE_RECORDS] array with explicit source identifiers and timestamps, and inject the [SOURCE_PRECEDENCE] list based on your data trust hierarchy (e.g., CRM > Enrichment API > Manual Entry). The [CONFLICT_RESOLUTION_RULES] should be templated from your master data management policy, specifying field-level tiebreakers such as 'prefer most recent non-null value' or 'prefer source A for phone, source B for address'. Do not rely on the model to infer these rules from examples alone.

After receiving the model's output, validate the JSON structure against your golden record schema before ingestion. Check that provenance arrays reference only valid source_id values from the input, that conflict_resolution entries map to actual conflicting fields, and that the staleness_flag is present for any field sourced from a record older than your configured threshold. Implement a retry loop with a maximum of two additional attempts: on the first retry, include the validation errors in the [PREVIOUS_ERRORS] field; on the second retry, lower the temperature to 0 and request only the fields that failed validation. If the output still fails validation after three attempts, route the record to a human review queue with the original sources, the failed outputs, and the validation error log attached.

For model selection, use a model with strong JSON mode and instruction-following capabilities. Avoid models that tend to hallucinate source attributions or merge fields without clear provenance. Log every reconciliation attempt—including input sources, model output, validation results, and final disposition—to an audit table. This log becomes your evidence trail for governance reviews and your dataset for tuning source precedence rules over time. Never allow an unreviewed golden record to overwrite a system of record without human approval on the first 100 merges, and maintain a rollback path for at least 30 days after deployment.