Deep Battle Cards A–F
A — Reference Data vs Master Data
Definition: Reference Data is controlled permissible/classifying values and mappings. Master Data represents persistent core business entities reused across processes.
Purpose: standardize meaning/classification vs establish consistent entity identity/context.
Scope: Reference is generally smaller/less volatile; Master may require matching, IDs, relationships, survivorship.
Inputs: code sets/standards/mappings vs source entity records + identity evidence + DQ.
Outputs: lists/crosswalks/taxonomies/versions vs trusted entity records/Global IDs/X-Refs.
When used: “What allowed value describes this?” → Reference. “Which entity is this?” → Master.
Common confusion: shared data is not automatically Master Data.
Scenario: Active/Inactive/Pending = Reference; Customer 84721 = Master.
Trap: do not solve duplicate customers with a code crosswalk or code translation with entity resolution.
Memory: Reference describes the choices; Master describes the thing.
Source: pp. 332–340.
B — System of Record vs System of Reference
Definition: SOR is authoritative for create/maintain; System of Reference is authoritative for consumer access.
Purpose: separate write authority from read authority.
Inputs: original business updates vs replicated/reconciled data.
Outputs: authoritative source values vs governed shared views/services.
When used: ask where the official change begins vs where consumers should obtain the shared data.
Scenario: CRM creates Customer; MDM publishes enterprise Customer → CRM SOR, MDM System of Reference.
Changed fact: all updates move to MDM → hub can become both.
Trap: a trusted published hub is not automatically SOR.
Memory: Record = writes begin; Reference = readers begin.
Source: pp. 339–340, 349–351.
C — Trusted Source vs Golden Record
Definition: Trusted Source = governed best-available source/view; Golden Record = reconciled record for one entity.
Purpose: establish confidence without claiming perfection; represent one enterprise entity instance.
Scope: environment/view vs entity-instance record.
Inputs: authority, DQ evidence, matching, survivorship, stewardship.
Outputs: trusted datasets/views vs reconciled entity records.
When used: “Where should consumers rely?” → Trusted Source; “What is Customer 123’s reconciled representation?” → Golden Record.
Trap: Golden does not mean 100% complete or accurate.
Memory: Trusted = where you trust; Golden = what you reconciled.
Source: pp. 339–340.
D — False Positive vs False Negative Match
Definition: false positive joins different real entities; false negative leaves the same entity separate.
Purpose: classify opposite match failures and drive remediation/tuning.
Inputs: candidate records, similarity evidence, rules/models, thresholds, steward review.
Outputs: match decisions, exceptions, reversal history, tuning evidence.
Scenario 1: two Jane Smiths share one Global ID → false positive.
Scenario 2: one customer has two Global IDs → false negative.
Trap: “positive” is not “good”; focus on whether the SAME decision is true.
Memory: false positive = false same; false negative = false different.
Source: pp. 343–346.
E — Deterministic vs Probabilistic Matching
Definition: deterministic uses explicit rules and repeatable results; probabilistic estimates statistical likelihood and can be trained/tuned.
Purpose: evaluate similarity evidence under different levels of variation.
Scope: matching method, not link/merge workflow.
Inputs: standardized attributes + fixed patterns or statistical features/training examples.
Outputs: match scores/decisions, thresholds, exception candidates.
Scenario 1: exact normalized SSN + DOB rule → deterministic.
Scenario 2: weighted evidence learned across imperfect name/address/phone data → probabilistic.
Trap: standardization is preparation, not itself a matching method.
Memory: deterministic = declared rule; probabilistic = estimated likelihood.
Source: pp. 344–345.
F — Duplicate Identification vs Match-Link vs Match-Merge
Definition: duplicate identification flags; match-link establishes identity relationship while preserving source content; match-merge reconciles values into a unified record.
Purpose: choose intervention strength that matches confidence/business need.
Inputs: match results, thresholds, survivorship/trust rules, business risk.
Outputs: review queue vs links/X-Refs vs merged/golden record with history.
When used: uncertainty/high risk → flag; confirmed identity/no content reconciliation → link; confirmed identity + unified profile needed → merge.
Common confusion: “records match” does not automatically mean “merge.”
Reversibility: intervention and reversal complexity generally increase Flag → Link → Merge.
Trap: merge requires survivorship and robust history.
Memory: Flag → Link → Merge.
Source: pp. 345–346.