Inferensys

Glossary

Survivorship Rules

Survivorship rules are the predefined logic applied during a merge process to select the single best value from conflicting data points when constructing a golden record, often based on source priority or data freshness.
Knowledge engineer constructing knowledge base on laptop, document hierarchy visible, casual office setup.
DATA MERGING LOGIC

What are Survivorship Rules?

Survivorship rules are the predefined, deterministic logic applied during a data merge process to select the single best value from a set of conflicting data points when constructing a canonical golden record.

Survivorship rules are the algorithmic decision logic that resolves data conflicts during entity resolution. When multiple source systems provide different values for the same attribute—such as a phone number or address—these rules dictate which value 'survives' the merge. The selection is typically based on criteria like source reliability ranking, data freshness (recency), or the completeness of the value, ensuring the final golden record is the most trusted representation.

Implementing survivorship rules requires a strict hierarchy of trust. An enterprise might configure a rule that always prefers data from a CRM over an ERP, unless the ERP record has a more recent last_modified timestamp. This logic prevents the creation of a master record by simple concatenation, instead using deterministic conflict resolution to automate the maintenance of a single, authoritative source of truth across the organization.

GOLDEN RECORD LOGIC

Key Characteristics of Survivorship Rules

Survivorship rules are the deterministic logic gates applied during entity resolution to resolve data conflicts. When multiple source records provide conflicting values for the same attribute, these rules select the single best value to populate the authoritative golden record.

01

Source Priority Hierarchy

The most common survivorship strategy assigns a trust score to each source system. When a conflict arises, the value from the highest-ranked source wins.

  • CRM > ERP: A customer's phone number from the CRM might survive over the billing system's record.
  • Certified > Inferred: A manually verified address overrides one generated by a fuzzy matching algorithm.
  • Implementation: A static lookup table maps source_id to an integer rank; the merge engine selects MAX(rank).
Tier 1
Typical Trust Level for CRM
02

Recency-Based Selection

This rule assumes the most recent update is the most accurate. The value with the latest modified_at timestamp survives the merge.

  • Use Case: Ideal for volatile attributes like job titles, stock quantities, or current location.
  • Granularity: Can be applied at the attribute level (e.g., phone changes frequently) rather than the whole record.
  • Risk: A system clock error or a batch backfill can incorrectly crown a stale value as the winner.
timestamp
Deciding Factor
03

Longest Value & Density Rules

When data completeness is the priority, survivorship logic selects the most information-rich value.

  • Longest String: Chooses the value with the highest CHAR_LENGTH. A full middle name survives over an initial.
  • Least Nulls: A sparse record from System A is rejected in favor of a fully populated record from System B.
  • Composite Density: A scoring function counts non-null fields; the record with the highest completeness score becomes the survivor.
04

Frequency & Consensus Voting

Also known as majority rules, this strategy selects the value that appears most often across all duplicate records.

  • Mechanism: If 4 out of 5 source records say NY and 1 says New York, NY survives.
  • Tie-Breaker: In a deadlock, a secondary rule (like recency or priority) is invoked.
  • Statistical Validity: Effective for crowdsourced or sensor data where individual errors are random, but the consensus is likely correct.
05

Attribute-Specific Strategy Matrix

Rarely does a single rule govern an entire entity. A survivorship matrix defines distinct logic per attribute.

  • Name: Longest value rule to preserve full legal names.
  • Phone Number: Recency rule to capture the latest mobile device.
  • Annual Revenue: Source priority rule (Finance system over Sales forecast).
  • Address: USPS-validated value always survives over unverified strings.
06

Survivorship Audit Trail

A non-negotiable requirement for data governance. The merge engine must log why a value survived and which values were deprecated.

  • Metadata: The golden record stores survivor_source, survivor_rule, and deprecated_values as JSON.
  • Lineage: Enables rollback if a survivorship rule is later found to be flawed.
  • Compliance: Essential for GDPR 'right to rectification' and financial auditing standards.
SURVIVORSHIP RULES

Frequently Asked Questions

Explore the deterministic logic that governs how conflicting data points are resolved during entity resolution, ensuring the construction of a single, authoritative golden record.

Survivorship Rules are the predefined, deterministic logic applied during a merge process to select the single best value from a set of conflicting data points when constructing a golden record. When multiple source systems provide different values for the same attribute—such as a phone number or address—the survivorship rule acts as an automated arbitrator. Rather than requiring manual review, the rule programmatically evaluates metadata like source reliability, data freshness (recency), or completeness to determine which value 'survives' the merge. This ensures that the final canonical record reflects the most trustworthy and accurate representation of an entity, eliminating ambiguity in master data management (MDM) systems.

Prasad Kumkar

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.