# Master Data Management Design: [Domain] at [Organisation]

> Solution design for a master data management (MDM) hub: domains and
> scope, the implementation style (registry, consolidation, coexistence
> or centralised), the master data model and golden record, the system
> of record matrix, match and merge, survivorship, stewardship workflow,
> hierarchies and reference data, quality KPIs, distribution, security
> and privacy, governance and rollout. The structure is aligned with the
> Reference and Master Data knowledge area of DAMA-DMBOK 2nd Edition
> Revised (2024). Replace every `[bracketed]` value and every row marked
> *Example*. Worked examples follow a customer domain for a retailer
> with four source systems.

<!--
Guidance: How to use this template
- Write one design per master data domain (customer, product, supplier,
  location, employee) or one design with a section per domain when they
  share a hub. Keep each domain's match rules and survivorship separate.
- Decide the implementation style (section 2) before choosing a product.
  The style decides which systems may create records, which is the
  hardest change to make later.
- Agree section 4 (who creates, reads, updates and deletes each entity)
  with every source owner in writing. Most MDM failures are ownership
  failures, not technology failures.
- Size the stewardship workload in section 5.4 before go-live; an
  unstaffed review queue turns the hub into another inconsistent copy.
- Related designs: Data Platform Architecture
  (`architecture/data-platform-architecture`), Data Dictionary
  (`architecture/data-dictionary`), Data Requirements
  (`requirements/data-requirements`), Data Migration Strategy
  (`architecture/data-migration-strategy`).
-->

## Document control

<!-- Guidance: Identify the domain, the hub and the accountable owners. A change of implementation style, golden record key or system of record is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [MDM-001] |
| Master data domain(s) | [Customer / Product / Supplier / Location / Employee] |
| Implementation style | [Registry / Consolidation / Coexistence / Centralised] |
| MDM product or build | [Product name and version / Custom build] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@mdm-architect] |
| Data owner (business) | [@domain-data-owner] |
| Approvers/reviewers | [@chief-data-officer], [@enterprise-architect], [@dpo], [@source-system-owners] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Business data owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Enterprise architecture | [@name] | [Decision] | YYYY-MM-DD |
| Data protection officer | [@name] | [Decision] | YYYY-MM-DD |
| Source system owners | [@names] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved for customer domain, consolidation style |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Moved to coexistence; CRM writes back golden attributes |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Scope, domains and drivers](#1-scope-domains-and-drivers)
2. [Implementation style](#2-implementation-style)
3. [Master data model and golden record](#3-master-data-model-and-golden-record)
4. [Sources and system of record](#4-sources-and-system-of-record)
5. [Match and merge](#5-match-and-merge)
6. [Survivorship](#6-survivorship)
7. [Stewardship workflow](#7-stewardship-workflow)
8. [Hierarchies and reference data](#8-hierarchies-and-reference-data)
9. [Data quality KPIs](#9-data-quality-kpis)
10. [Distribution and integration](#10-distribution-and-integration)
11. [Security and privacy](#11-security-and-privacy)
12. [Governance and RACI](#12-governance-and-raci)
13. [Non-functional requirements and sizing](#13-non-functional-requirements-and-sizing)
14. [Rollout, migration and risks](#14-rollout-migration-and-risks)
15. [Glossary and references](#15-glossary-and-references)

## 1. Scope, domains and drivers

<!-- Guidance: Say which entities are mastered, why, and which business processes depend on them. Questions: what does a duplicate or a wrong record cost today, who will notice the improvement? Pitfall: mastering every attribute of every entity instead of the attributes that several processes share. -->

### 1.1 Drivers

| ID | Driver | Current impact | Target |
|---|---|---|---|
| MDR-001 *(Example)* | The same customer exists in POS loyalty, e-commerce and CRM with different identifiers | Marketing sends duplicate mail; 8 % estimated duplicate rate | One customer identifier across channels; duplicate rate below 1 % |
| MDR-002 *(Example)* | Consent preferences differ between systems | Complaints and regulatory risk | Consent held once and distributed within 15 minutes |
| MDR-003 *(Example)* | Finance cannot report revenue per customer group | Manual spreadsheet mapping each quarter | Customer hierarchy maintained in the hub |
| [MDR-NNN] | [Driver] | [Impact] | [Target] |

### 1.2 Domain scope

| Entity | Mastered attributes | Not mastered (left in sources) | Consuming processes |
|---|---|---|---|
| Customer (person) *(Example)* | Name, date of birth, email, phone, postal address, consent flags, loyalty tier | Order history, payment tokens, web behaviour | Marketing, service, loyalty, finance reporting |
| Customer (organisation) *(Example)* | Legal name, registration number, VAT number, addresses, parent | Credit limit (owned by ERP) | B2B sales, invoicing |
| [Entity] | [Attributes] | [Attributes] | [Processes] |

Reference data (code lists such as country, currency, customer
segment) is in scope in section 8 because the golden record depends on
it.

## 2. Implementation style

<!-- Guidance: Choose a style per domain and record why. The four styles are widely described in industry literature; use the names consistently. Questions: may sources keep creating records, must the hub write back, how much organisational change can the programme carry? Pitfall: promising a centralised hub when source owners will not give up record creation. -->

### 2.1 Style comparison

| Style | How it works | Golden record stored | Write-back to sources | Typical use | Organisational impact |
|---|---|---|---|---|---|
| Registry | Hub holds identifiers and match links only; attributes stay in sources and are assembled at read time | No (virtual) | No | Fast cross-reference, read-only analytics | Low |
| Consolidation | Hub copies source records, matches and merges them into a golden record for downstream reading | Yes | No | Analytics and reporting on a single view | Low to medium |
| Coexistence | Golden record built as in consolidation and published back so sources align; several systems still create records | Yes | Yes | Operational alignment while keeping existing entry points | Medium to high |
| Centralised (transactional) | Records are created and maintained in the hub and distributed to sources, which stop creating them | Yes, authoritative | Hub is the source | Strong control, regulated data | High |

### 2.2 Decision

| Criterion | Weight | Registry | Consolidation | Coexistence | Centralised |
|---|---|---|---|---|---|
| Meets MDR-001 (single identifier) *(Example)* | 5 | 4 | 4 | 5 | 5 |
| Meets MDR-002 (consent distributed) *(Example)* | 5 | 1 | 2 | 5 | 5 |
| Source change effort *(Example)* | 3 | 5 | 5 | 3 | 1 |
| Time to first value *(Example)* | 3 | 5 | 4 | 3 | 2 |
| Weighted total *(Example)* | | 55 | 57 | 68 | 59 |

The weighted total is the sum of weight multiplied by score. Coexistence:
5 x 5 + 5 x 5 + 3 x 3 + 3 x 3 = 68. Centralised: 25 + 25 + 3 + 6 = 59.
Consolidation: 20 + 10 + 15 + 12 = 57. Registry: 20 + 5 + 15 + 15 = 55.
Add criteria for cost, product fit and regulatory control before deciding;
recompute every total when a score or weight changes.

*Example decision:* coexistence for the customer domain, starting as
consolidation in phase 1 (read-only golden record) and adding write-back
in phase 2. Record the decision as an ADR in the Architecture Decision
Log (`architecture/architecture-decision-log`).

## 3. Master data model and golden record

<!-- Guidance: Define the hub entities, the golden record identifier, the cross-reference to source keys and the attribute-level metadata. Pitfall: reusing a source system key as the master key, which ties the hub to that system forever. -->

### 3.1 Entities

The *Example* hub model uses a party pattern: one golden party with
addresses, contacts, consents and relationships, and one cross-reference
row per contributing source record.

```mermaid
erDiagram
  PARTY ||--o{ PARTY_XREF : "linked from"
  PARTY ||--o{ PARTY_ADDRESS : has
  PARTY ||--o{ PARTY_CONTACT : has
  PARTY ||--o{ PARTY_CONSENT : records
  PARTY ||--o{ PARTY_RELATIONSHIP : "parent or child"
  PARTY_XREF }o--|| SOURCE_SYSTEM : "comes from"
  PARTY {
    string master_id
    string party_type
    string status
    datetime last_merged_at
  }
  PARTY_XREF {
    string source_system_id
    string source_key
    string match_rule_id
    float match_score
  }
```

### 3.2 Golden record attributes

| Attribute | Type | Mastered from | Survivorship rule | Quality rule | Classification |
|---|---|---|---|---|---|
| master_id *(Example)* | String (opaque, generated) | Hub | Never changes; merged records keep a pointer to the survivor | Unique, not null | Internal |
| given_name, family_name *(Example)* | String | CRM, e-commerce, POS loyalty | SRV-001 | Not null, no digits | Personal |
| email *(Example)* | String | E-commerce, CRM | SRV-002 | Valid syntax, verified flag | Personal |
| postal_address *(Example)* | Structured address | CRM, e-commerce | SRV-003 | Validated against address reference | Personal |
| consent_marketing_email *(Example)* | Boolean plus timestamp and channel | Consent service | SRV-004 | Timestamp required | Personal, consent |
| loyalty_tier *(Example)* | Code (reference data) | POS loyalty | Source of record only | Code in list | Internal |
| [Attribute] | [Type] | [Sources] | [Rule ID] | [Rule] | [Class] |

Keep attribute definitions in the Data Dictionary
(`architecture/data-dictionary`) and link each attribute here to its
dictionary entry. Store, for every golden attribute, the contributing
source, the source timestamp and the rule that selected it, so that any
value can be explained to an auditor or a data subject.

### 3.3 Identifier policy

- Generate the master identifier in the hub; never derive it from
  personal data.
- When two golden records merge, keep the survivor's identifier and keep
  the retired identifier as an alias pointing to the survivor, so
  downstream systems that stored it can still resolve it.
- When a merge is reversed (unmerge), restore both identifiers and
  publish correction events (section 10).

## 4. Sources and system of record

<!-- Guidance: List each source and what it may do with each entity. Use C (create), R (read), U (update), D (delete or deactivate). Pitfall: two systems both marked as the authority for the same attribute with no tie-break rule. -->

| Source system | Owner | Records | Customer person | Customer organisation | Consent | Integration | Latency |
|---|---|---|---|---|---|---|---|
| CRM *(Example)* | @crm-owner | 3.5 million | C R U | C R U | R | Change events and API | Near real time |
| E-commerce *(Example)* | @ecom-lead | 5.0 million | C R U | None | C R U | CDC | Near real time |
| POS loyalty *(Example)* | @retail-ops | 2.8 million | C R U | None | R | Nightly file, then CDC in phase 2 | Daily |
| ERP *(Example)* | @erp-owner | 0.7 million | R | C R U | None | Batch API | Daily |
| MDM hub *(Example)* | @mdm-architect | Golden records | R U (golden) | R U (golden) | R | Publishes events and API | Under 15 minutes |
| [System] | [@owner] | [Count] | [CRUD] | [CRUD] | [CRUD] | [Method] | [Latency] |

The *Example* sources hold 3.5 + 5.0 + 2.8 + 0.7 = 12.0 million source
records. Section 5.4 sizes matching from this total.

## 5. Match and merge

<!-- Guidance: Define how candidate duplicates are found (blocking), compared (rules or probabilistic scores) and decided (thresholds). Test rules on a labelled sample before go-live. Pitfall: thresholds tuned on one country's data and applied to all. -->

### 5.1 Standardisation before matching

1. Normalise case, whitespace and diacritics in names.
2. Parse and validate addresses against the address reference service.
3. Normalise phone numbers to international format.
4. Lower-case email addresses and remove known alias patterns only where
   the provider documents them.
5. Keep the original value alongside the standardised one.

### 5.2 Blocking and match rules

| ID | Type | Blocking key | Comparison | Outcome |
|---|---|---|---|---|
| MR-001 *(Example)* | Deterministic | Verified email | Exact email and same family name | Auto-merge |
| MR-002 *(Example)* | Deterministic | Phone (international) | Exact phone and date of birth | Auto-merge |
| MR-003 *(Example)* | Probabilistic | Postcode plus first 3 letters of family name | Weighted score on name, address, birth date, phone | By threshold (5.3) |
| MR-004 *(Example)* | Organisation | VAT or registration number | Exact identifier | Auto-merge |
| [MR-NNN] | [Type] | [Key] | [Comparison] | [Outcome] |

### 5.3 Thresholds

| Score band | Decision | Owner |
|---|---|---|
| 0.92 and above *(Example)* | Auto-merge | System |
| 0.75 to below 0.92 *(Example)* | Steward review task | Data steward |
| Below 0.75 *(Example)* | No match | System |

Measure precision (merged pairs that are true duplicates) and recall
(true duplicates found) on a labelled sample of at least [2,000] pairs
per country. False merges are usually more harmful than missed matches:
they mix two people's personal data. Set the auto-merge threshold for
precision first.

### 5.4 Workload sizing *(Example)*

| Step | Calculation | Result |
|---|---|---|
| Comparisons without blocking | 12,000,000 x 11,999,999 / 2 | about 7.2 x 10^13 pairs (infeasible) |
| Blocks at an average of 20 records each | 12,000,000 / 20 | 600,000 blocks |
| Comparisons per block | 20 x 19 / 2 | 190 |
| Comparisons with blocking | 600,000 x 190 | 114,000,000 pairs |
| Records in the review band (0.5 %) | 12,000,000 x 0.005 | 60,000 review tasks |
| Steward capacity (5 stewards x 120 tasks per day) | 5 x 120 | 600 tasks per day |
| Initial backlog duration | 60,000 / 600 | 100 working days |

Consequence: a 100-day backlog is longer than the phase 1 timeline. Raise
the auto-merge band only if the labelled sample still shows precision of
at least [99.5 %], add temporary stewards for the initial load, or
prioritise review tasks for active customers (purchase in the last 12
months) first. Ongoing daily volume is much smaller: size it from new
records per day multiplied by the review-band rate.

## 6. Survivorship

<!-- Guidance: For each golden attribute, state which source value wins. Typical rule types: source priority, most recent, most complete, most frequent, validated value wins, steward override. Pitfall: "most recent wins" for a field that one system overwrites with defaults. -->

| ID | Attribute | Rule type | Rule | Tie-break |
|---|---|---|---|---|
| SRV-001 *(Example)* | Names | Source priority with recency | CRM over e-commerce over POS loyalty, unless the lower-priority value is newer by more than 180 days and verified | Steward review |
| SRV-002 *(Example)* | Email | Validated wins | Verified email (confirmed link) wins; otherwise most recent | Most recent |
| SRV-003 *(Example)* | Postal address | Validated and recent | Address validated by reference service and most recently used for delivery | Source priority |
| SRV-004 *(Example)* | Consent | Most recent event | Latest consent event from any channel, with timestamp and channel retained | Never merged by priority |
| SRV-005 *(Example)* | Any attribute | Steward override | Steward value locked until a newer verified source value arrives | Steward |
| [SRV-NNN] | [Attribute] | [Type] | [Rule] | [Tie-break] |

## 7. Stewardship workflow

<!-- Guidance: Describe the tasks stewards perform, their states, service levels and escalation. Questions: who reviews matches, who approves hierarchy changes, how are data subject requests handled? Pitfall: a queue with no service level and no owner. -->

```mermaid
stateDiagram-v2
  [*] --> Open: task created by match or quality rule
  Open --> InReview: steward claims task
  InReview --> Merged: confirm match
  InReview --> Rejected: not a match
  InReview --> Escalated: needs data owner
  Escalated --> Merged
  Escalated --> Rejected
  Merged --> Unmerged: error found later
  Merged --> [*]
  Rejected --> [*]
  Unmerged --> [*]
```

| Task type | Created by | Service level *(Example)* | Escalation |
|---|---|---|---|
| Potential match review | MR-003 band 0.75 to 0.92 | 5 working days | Data owner after 10 days |
| Quality exception | Quality rules in section 9 | 3 working days | Domain lead |
| Hierarchy change request | Business user request | 10 working days | Data owner |
| Unmerge request | Steward or customer complaint | 1 working day | DPO when personal data was mixed |
| Data subject request | Privacy team | Within the legal deadline, internal target 10 days | DPO |
| [Task] | [Source] | [SLA] | [Escalation] |

Log every steward decision with the user, time, before and after values
and reason. Use the log to retrain or adjust match rules each quarter.

## 8. Hierarchies and reference data

<!-- Guidance: Describe hierarchies (corporate families, product categories, sales territories) and reference code lists, their owners and version control. Pitfall: hierarchies edited in spreadsheets outside the hub. -->

### 8.1 Hierarchies

| ID | Hierarchy | Levels | Source of truth | Change approval | Effective dating |
|---|---|---|---|---|---|
| HIE-001 *(Example)* | Corporate customer family | Ultimate parent, parent, legal entity | Hub, enriched from a business register | Data owner | Valid from and valid to |
| HIE-002 *(Example)* | Customer segment | Segment, sub-segment | Hub | Marketing data owner | Monthly versions |
| [HIE-NNN] | [Name] | [Levels] | [Source] | [Approver] | [Dating] |

### 8.2 Reference data

| Code list | Standard or owner | Version control | Distribution |
|---|---|---|---|
| Country *(Example)* | ISO 3166-1 alpha-2 | Updated when the maintenance agency publishes changes | Published to all sources |
| Currency *(Example)* | ISO 4217 | As above | Published to all sources |
| Customer segment *(Example)* | Marketing | Versioned in the hub | Event on change |
| [Code list] | [Standard or owner] | [Control] | [Distribution] |

## 9. Data quality KPIs

<!-- Guidance: Measure the hub with a small set of KPIs reported monthly to the data owner. Define each KPI fully in Metric Definitions (`ai-data/metric-definition`). Pitfall: reporting only completeness while duplicates grow. -->

| ID | KPI | Definition | Target *(Example)* | Frequency |
|---|---|---|---|---|
| KPI-001 *(Example)* | Duplicate rate | Estimated true duplicates among golden records, from a monthly sample | Below 1 % | Monthly |
| KPI-002 *(Example)* | False merge rate (detected) | Unmerges divided by merges in the period; validate quarterly against a labelled sample, because unmerges show only the false merges someone noticed | Below 0.1 % | Monthly |
| KPI-003 *(Example)* | Completeness of mandatory attributes | Golden records with all mandatory attributes populated | 98 % | Weekly |
| KPI-004 *(Example)* | Address validity | Addresses that pass reference validation | 95 % | Weekly |
| KPI-005 *(Example)* | Steward backlog age | Open tasks older than the service level | Below 5 % | Weekly |
| KPI-006 *(Example)* | Distribution latency | Time from golden record change to receipt by subscribers (p95) | Under 15 minutes | Daily |
| [KPI-NNN] | [KPI] | [Definition] | [Target] | [Frequency] |

## 10. Distribution and integration

<!-- Guidance: Describe how consumers get golden records: events, APIs, batch files, and the data platform. Specify event schemas in Event API Specification (`architecture/event-api-specification`). Pitfall: consumers that cache golden records and never process merge events. -->

| ID | Channel | Consumers | Content | Contract |
|---|---|---|---|---|
| DST-001 *(Example)* | Change events (created, updated, merged, unmerged) | CRM, e-commerce, marketing | Golden record plus retired identifiers on merge | AsyncAPI 3.1.0 document |
| DST-002 *(Example)* | Lookup API by master or source key | Service desk, web | Golden record and cross-reference | OpenAPI document |
| DST-003 *(Example)* | Daily snapshot to the data platform | Analytics | Golden records, cross-reference, hierarchy | Data contract (`ai-data/data-contract`) |
| [DST-NNN] | [Channel] | [Consumers] | [Content] | [Contract] |

Require every subscriber to handle merge and unmerge events: on merge,
replace the retired identifier with the survivor; on unmerge, split the
local data or flag it for review. Interface details belong in the
Integration Design (`architecture/integration-design`).

## 11. Security and privacy

<!-- Guidance: The hub concentrates personal data, so it is a high-value target and a privacy hotspot. Questions: who may search all customers, how is access logged, how is erasure propagated? Pitfall: giving every steward full access to every country. -->

| Topic | Design *(Example)* |
|---|---|
| Access | Stewards see only their countries; search results limited and logged |
| Privileged actions | Merge, unmerge and bulk updates need a steward role and are logged with reason |
| Encryption | At rest with customer-managed keys; TLS in transit |
| Data minimisation | Only attributes needed by two or more processes are mastered (section 1.2) |
| Erasure | An erasure request deletes or anonymises the golden record and publishes an erasure event that every subscriber must honour within [30] days |
| Lawful basis and records | Processing recorded in the record of processing activities (`compliance/gdpr-ropa`); DPIA in `compliance/dpia` |
| Residency | Golden records stored in the region of the customer's country; see `compliance/data-residency-sovereignty-assessment` |
| Threats | Mass export, insider browsing, false merges that disclose data to the wrong person; analysed in `security/privacy-threat-model` |

## 12. Governance and RACI

<!-- Guidance: Name the roles and decision rights. R = responsible, A = accountable, C = consulted, I = informed. Pitfall: an IT team accountable for business definitions. -->

| Activity | Data owner | Data steward | MDM architect | Source system owner | DPO |
|---|---|---|---|---|---|
| Define mastered attributes | A | R | C | C | C |
| Approve match and survivorship rules | A | R | R | C | C |
| Review match tasks | I | R, A | I | I | I |
| Approve hierarchy changes | A | R | I | I | I |
| Change integration contracts | C | I | A | R | I |
| Handle data subject requests | A | R | I | R | C |
| Report quality KPIs | A | R | C | I | I |

Run a monthly data governance meeting for the domain with the KPI report,
open escalations and rule change requests. Record rule changes with a
version number and an effective date.

## 13. Non-functional requirements and sizing

<!-- Guidance: State volume, latency, availability and recovery targets, and derive capacity from them. Pitfall: sizing the hub for steady state and not for the initial load and rematch runs. -->

| ID | Requirement | Target *(Example)* | Derivation |
|---|---|---|---|
| MNF-001 | Golden record count after initial load | About 9.6 million | 12.0 million source records with an estimated 20 % overlap: 12.0 x 0.8 = 9.6 million |
| MNF-002 | Initial match run duration | Under 8 hours | 114 million comparisons in 8 hours is 114,000,000 / 28,800 = about 3,958 comparisons per second |
| MNF-003 | Steady-state updates | 50,000 per day, peak 20 per second | Source change rates from section 4 |
| MNF-004 | Lookup API latency | p95 under 200 ms | Service desk screen budget |
| MNF-005 | Availability | 99.9 % for lookup API | Operational dependency in coexistence |
| MNF-006 | Recovery | RPO 15 minutes, RTO 4 hours | Resilience tier 2 |
| [MNF-NNN] | [Requirement] | [Target] | [Derivation] |

Record cross-cutting targets in the NFR Catalogue
(`requirements/nfr-catalogue`).

## 14. Rollout, migration and risks

<!-- Guidance: Plan the initial load, the order in which sources connect and when write-back starts. Pitfall: switching sources to hub-created identifiers before downstream systems can handle merge events. -->

### 14.1 Phases

| Phase | Scope | Exit criteria |
|---|---|---|
| 1. Consolidation *(Example)* | Load CRM, e-commerce and POS loyalty; golden record read-only to analytics | Precision at least 99.5 % on labelled sample; backlog plan approved |
| 2. Coexistence *(Example)* | Publish golden attributes and consent back to CRM and e-commerce | All subscribers pass merge and unmerge tests |
| 3. Organisation customers *(Example)* | Add ERP and the corporate hierarchy | Finance confirms revenue by customer family |
| [Phase] | [Scope] | [Criteria] |

The initial load follows the Data Migration Strategy
(`architecture/data-migration-strategy`); reconcile counts per source with
the Data Migration Reconciliation Report
(`project/data-migration-reconciliation`).

### 14.2 Risks

| ID | Risk | Likelihood | Impact | Response | Owner |
|---|---|---|---|---|---|
| RSK-001 *(Example)* | False merges expose one customer's data to another | Medium | High | Precision-first thresholds, unmerge in 1 day | @data-steward-lead |
| RSK-002 *(Example)* | Source owners keep creating duplicates | High | Medium | Search-before-create API in phase 2 | @mdm-architect |
| RSK-003 *(Example)* | Steward backlog never clears | Medium | Medium | Section 5.4 actions, KPI-005 | @data-owner |
| [RSK-NNN] | [Risk] | [L / M / H] | [L / M / H] | [Response] | [@owner] |

## 15. Glossary and references

<!-- Guidance: Define terms for business readers and list the sources consulted with versions. -->

| Term | Meaning |
|---|---|
| Golden record | Best available single version of a master entity, assembled from sources |
| Cross-reference | Link from a golden record to each source record that contributed |
| Blocking | Grouping records by a key so that only records in the same group are compared |
| Survivorship | Rules that choose which source value becomes the golden value |
| Steward | Person who resolves data issues and match decisions for a domain |
| Unmerge | Reversal of a merge that combined records of different real-world entities |
| Reference data | Controlled code lists used to classify other data |

References: DAMA-DMBOK 2nd Edition Revised (DAMA International, 2024),
Reference and Master Data and Data Quality knowledge areas (names only);
ISO 3166-1 and ISO 4217 code lists; AsyncAPI Specification 3.1.0
(asyncapi.com, January 2026); [MDM product documentation, version];
[Internal data governance policy].

## Standard and licence note

Structure aligned with the Reference and Master Data knowledge area of
DAMA-DMBOK 2nd Edition Revised (DAMA International, 2024); only the
knowledge area names are used and no text, figures or definitions from
the book are reproduced. The four implementation styles are described in
original wording from common industry practice. This template is
original text written for this collection. Check the current official
editions and your MDM product documentation before use. DAMA-DMBOK is a
trademark of DAMA International; this template is not affiliated with or
endorsed by it. Template licence: MIT.