Glossary
Survivorship rules
Survivorship rules specify which source value appears in a consolidated record when sources disagree.
Identity and entity resolution
Survivorship rules govern attribute selection after records have been judged to refer to the same entity. A rule may prefer a designated authority, a verified observation or a value current for a specified date. It must be defined per attribute and purpose: no source is automatically best for every property. The selected value is a decision under a policy, not an erasure of the other claims.
A practical rule includes eligibility conditions, precedence, treatment of ties and what to do when no source qualifies. It should account for effective dates and the difference between an empty field and an explicit negative. Changes to the rule can change displayed values even when sources do not change, so the governing rule version belongs in the decision record.
An organization defending a value needs to show both the selected source and the rejected alternatives. This makes a survivorship result reviewable when a source is corrected or a policy changes. Golden records display selected values; truth discovery studies credibility under uncertainty; survivorship rules express an organization's explicit selection policy for a defined use.
Example
For Halden Therapeutics AG (fictional), a registered address comes from the current company register, while a study-site address follows trial documentation.
Common rule types
Survivorship rules decide which of several competing values appears in a consolidated record. The common types are source priority, in which one source outranks another for a field; recency, in which the most recently updated value wins; completeness, in which a non-empty value beats an empty one; frequency, in which the most common value among sources wins; and quality-based rules, in which a value that passes validation beats one that fails. Most real rule sets combine them per field: legal name by source priority, phone number by recency, email by validity then recency. The point of listing the rules explicitly is that each carries an assumption: recency assumes that later is better, which fails when a stale feed overwrites a correction.
Rules can also compute a value, such as the earliest date among sources or the sum of balances, or can decline to choose and retain several values. The data-fusion literature treats the same decision as conflict resolution; Wikidata's model of preferred, normal and deprecated ranks shows a design in which the system marks a preferred value and still keeps the others, with their references.
Writing rules that can be tested
A rule is testable if it can be stated as a function of the inputs: given these source values, with these dates and quality flags, the output is this value. Collect a set of example cases for each field, including awkward ones: a null in the preferred source, two sources with the same timestamp, a value that fails validation but is more recent. Run the rules against the cases whenever they change. Keep a version number on the rule set and record, with each consolidated value, the version that produced it, so that a later change can be assessed and, if needed, the earlier value reproduced.
Every rule should state its fallback when it cannot decide. A tie, a missing priority or a failed validation should lead to a defined outcome: hold the existing value, retain both, or queue for review. A rule that falls through silently to an arbitrary choice produces values that nobody can explain. The article on truth discovery with copying sources is a reminder that source priority also needs to account for sources that derive from one another.
A worked example
Three sources give a supplier's contact email for Halden Therapeutics AG (fictional): the registry extract holds none, the finance system holds an address last updated in January, and the procurement system holds a different address updated in May. The rule for email is: prefer a value that passes validation, then the most recent. Both pass validation, so the May value survives. A review later finds that the May address is a shared mailbox and the January address belongs to the named contact. The rule is then revised, for contacts with roles, to prefer a named mailbox over a shared one, and the change is versioned. The earlier consolidated value remains reproducible from the old rule version and the retained source values.
Related terms and boundaries
Survivorship is the field-level policy of data fusion for a golden record in master data management. Where a disagreement reflects a real change over time, valid time and not survivorship is the right tool, since both values are correct for their period. Where the disagreement is about fact, truth discovery and data conflict handling apply.
Common misreadings
- Applying one precedence order to unrelated fields.
- Using recency without checking effective date.
- Deleting values that lost selection.
Appears in
- Master data management vs knowledge fusion
MDM governs shared business entities; knowledge fusion reconciles assertions drawn from multiple sources.
References
- Otto (2012), How to design the master data architecture: Findings from a case study at Bosch, International Journal of Information Management 32(4).
- DAMA International, DAMA-DMBOK: Data Management Body of Knowledge.
- Wikipedia, Master data management.
- Wikidata, Help:Ranking (preferred, normal and deprecated statements).
- Wikidata, Help:Sources (references on statements).
Found an error on this page? See corrections for what counts as one, how to report it and the dated log.
Enquiry
Where does "Survivorship rules" bear on a decision of yours?
This entry sits under identity and entity resolution. If a decision in your organization turns on it, send the entity concerned, the sources you fuse to describe it and who may read which of them. We reply with what a first record would cover.
Or write to [email protected] in your own words.