Survivorship

Given five rows for the same customer, which field value wins? Survivorship rules are how Golden Suite decides — explicitly, per-field.

Entity resolution tells you that five rows refer to the same customer. Survivorship tells you which value wins for each field on the golden record.

The naive approach (and why it breaks)

A first guess: "just pick the most recent value". This works for some fields (phone number, address) and breaks for others (legal name shouldn't bounce around every time a salesperson types it differently).

A second guess: "trust whichever source has the highest confidence". Works for legal data (the CRM is authoritative for company name). Breaks for behavioral data (Stripe knows last-payment-date better than the CRM does).

The honest answer is that different fields need different rules, and survivorship is the explicit list of those rules.

The built-in rule set

Golden Suite ships with these survivorship rules. Each one is a function from "list of candidate values, with source + timestamp metadata" to "winner".

• most_recent — most recently updated value wins. Default for contact info (phone, email, address).
• source_priority — pick the highest-ranked source's value. You define the source ranking once per entity type. Default for fields with a clear system of record.
• most_complete — pick the longest non-empty value (favors "Acme Corporation, LLC" over "Acme"). Default for names and free-text descriptions.
• highest_confidence — pick the value from the cluster member with the highest match confidence. Default when you don't know which rule applies — it picks the "most central" member.
• majority_vote — value that appears most often wins, ties broken by most_recent. Useful for categorical fields like industry or country.
• custom — your own function. Takes the candidate list, returns the winner. Used for one-off cases like "legal name must come from the registry of incorporation, fall back to CRM".

Per-tenant overrides

The defaults are fine for a demo. Real customers configure their own rules per entity type in the Survivorship editor. The editor shows a per-field row with a rule dropdown and a preview of what the rule would have produced on the last 100 clusters.

When you change a rule, the change is logged in the audit log with the before/after rule definitions and the user who changed it. The audit log is cryptographically chained — see Lineage for why that matters.

Why this is its own concept

Survivorship is the layer where "we merged five rows" turns into "here's the one canonical customer record". A merge without survivorship rules isn't a golden record — it's a question.

Some MDM products bury survivorship inside the resolution algorithm. Golden Suite keeps it separate on purpose: the rules are inspectable, editable, and auditable as a first-class artifact.