Survivorship Rules

When several systems hold a record for the same customer, each may carry a different address, a different legal name and a different contact preference. Survivorship rules decide which value becomes the master value.

The distinguishing property of good rules is that they are per attribute, not per source. A global source ranking says "the CRM wins" — and the CRM is authoritative for contact preference and demonstrably worse than the billing system for addresses. One ranking is wrong for roughly half the fields.

Why this determines adoption

A golden record that contradicts what a business user sees in their own system is not used. They keep working from the source they trust, the master data becomes a parallel copy nobody consults, and the programme's value disappears while its cost continues.

Getting survivorship right per attribute — with the reasoning traceable — is what makes the master value defensible when someone disputes it, and disputes are the normal case rather than the exception.

Implementation patterns

• A rule per attribute, stated as source precedence, recency, completeness, or a validation-based rule such as "the address that passes verification wins".
• Lineage on every mastered attribute, recording which source supplied the surviving value and when. A disputed value that cannot be traced cannot be defended.
• A stewardship queue for the cases rules cannot settle, staffed and worked. The uncertain band is permanent, and an unstaffed queue makes the whole system decorative.
• Match thresholds tuned toward false splits, because [[entity-resolution]] has two errors with very different costs: a false merge combines two real customers, which is a privacy incident and hard to unpick; a false split leaves a duplicate, which is annoying and safe.
• Feedback to sources, so a corrected value flows back. Where corrections are only applied centrally, the sources keep producing the same errors and the remediation effort is permanent.

Industry example

Large enterprises consolidating customer data across a dozen systems consistently find that the technical matching is the easier half. The programme succeeds or fails on whether the business agrees with the surviving values — which is a negotiation with each domain about their own attributes, not a modelling exercise.

The consequence for sequencing is that survivorship should be agreed attribute by attribute with the owning function before the golden record is published, rather than derived by the platform team and defended afterwards.

Failure scenarios

• A global source ranking, wrong for many attributes and therefore distrusted for all of them.
• No lineage, so disputes cannot be resolved and each one becomes an investigation.
• Thresholds tuned to minimise duplicates, producing false merges — the expensive error.
• An unstaffed stewardship queue, leaving the uncertain band permanently unresolved.
• No feedback loop, making remediation a permanent operating cost rather than a decreasing one.

Trade-offs

Per-attribute rules are more work to define, agree and maintain than a single ranking, and they require a conversation with every owning function. That effort is the price of a golden record anyone uses.

The pragmatic scoping move is to master only the attributes that genuinely need consistency across systems. Mastering everything multiplies the negotiation surface for attributes nobody compares.

Interview question

"Your golden customer record says one address and the billing team's system says another. Both are 'correct' in their own system. Who decides, on what basis, and how does the person querying the golden record know why?"