Enterprise AI Project Wiki · Data, knowledge and models
Master data
Also calledMaster data · Core master data · Enterprise master data · Master records
Master data is controlled data that gives stable identity and description to core entities an organisation repeatedly references across business processes, transactions, or systems. It commonly connects a persistent unique entity identifier to names, classes, states, relationships, and applicable attributes so consumers can refer to the same object and use the authoritative information effective at the relevant time.
Master data lets processes keep referring to the same entity; it is not a central pile of common fields
Orders, invoices, approvals, stock, and service records repeatedly reference customers, suppliers, products, locations, or organisations. If every system creates an object from a name, one entity becomes duplicates and different entities can be merged. Master data first establishes controlled identity so transactions and events point consistently to the same business object.
GS1 describes master data as static or nearly static data associated with an entity and explains that transactions and visibility events refer to entities through identification keys. Relatively stable does not mean immutable: companies rename, products retire, locations move, and organisations merge. Master data manages those changes without making history inexplicable.
ISO 8000-100 introduces a series addressing master-data quality and organisational conditions, including machine-checkable exchange of characteristic data across systems and organisations. It does not provide a universal enterprise-entity list or complete internal MDM merely through adoption. Each project still selects domains, objects, attributes, authorities, uses, and governance.
What qualifies for master-data scope
Not every frequently used value needs master-data governance. The strongest candidates are core entities shared across processes, requiring stable identity, whose errors spread between systems. Judge shared business use and consequence before funding specialist controls.
- Does it represent an independently identifiable core entity?
The object persists in business terms rather than being a momentary transaction value or calculation.
Check: business-object model, vocabulary, and identity boundary.
- Do multiple processes or systems reuse it?
Enterprise mastering may not justify its cost when a value is confined to one task and never crosses a boundary.
Check: producer–consumer–transaction reference map.
- Does inconsistency have cross-process consequences?
Duplicate customers, wrong supplier state, or divergent product class affects transactions, access, reporting, risk, or service.
Check: defects, reconciliation cost, and risk.
- Do attributes change more slowly than referencing transactions?
Master data changes, but ordinary business activity does not create a new entity description each time; high-rate events and balances belong elsewhere.
Check: creation, update, and reference rates.
- Is shared identity, definition, or authority necessary?
Consumers need agreement on which object, which attributes are effective, and which source prevails.
Check: identifier collisions, semantic differences, and attribute authority.
- Does governance value justify its cost?
Not every lookup table needs central mastering. Prioritise high-impact, broadly reused domains with accountable owners.
Check: domain priority, value, risk, and operating capacity.
Define domain, entity grain, and relationships first
Supplier may mean a legal entity, contracting party, payment location, or contact. Without grain, teams merge objects that should be related or create duplicates for one entity. Define domain, entity, and relationship before identifiers and matching rules.
Party domain
Customers, suppliers, partners, employees, legal entities, organisational units, and contacts. Separate person, legal entity, business role, account, and relationship; one party may hold several contextual roles.
Product and service domain
Product family, sellable item, specification, pack, service catalogue, and asset model. Separate class, variant, lot, serial instance, and order line.
Location domain
Registered address, physical, functional, and digital locations, warehouses, shops, and delivery points. GS1 GLN rules show that shared or separate identity for entity, function, and location needs a business decision.
Organisation and finance structure
Legal entity, department, cost centre, ledger, budget unit, and reporting hierarchy. Reorganisation must not silently rewrite the structure governing past transactions.
Asset and resource
Equipment, vehicle, facility, contract resource, or another object shared by maintenance, finance, stock, and service. Model and individual instance have different identity grains.
Relationship and hierarchy
Parent organisation, customer–account, product–pack, supplier–location, substitute, and succession relationships need type, direction, validity, source, and authority.
Domain boundary
Partition by capability, accountability, identity, and lifecycle—not current application menus. Records in several systems are source representations, not proof of several business entities.
Stable identity matters more than a name
Names change, translate, abbreviate, and repeat, so they cannot carry identity alone. A stable identifier keeps historic transactions and new names attached to one entity. External numbers also need issuer, scope, and validity—not just a stored string.
Identifier domain and object type
State the organisation, domain, or open network in which an ID is unique and whether it identifies a class, legal entity, function, location, lot, or instance.
Uniqueness and completeness
One value identifies one entity in scope and every governed entity receives a value; temporary, candidate, and unknown external objects use controlled states.
Persistence and non-reuse
Keep identity across the entity lifecycle and do not reassign a retired ID. Rules decide whether name, address, class, or ownership change updates an entity or creates a new one.
Non-significance or limited significance
Avoid encoding mutable region, department, class, or date in the primary key. Display numbers can carry format, but internal identity must not depend on changing meaning.
External and internal mapping
Retain tax, registry, GS1, customer, supplier, and system IDs with source, type, validity, and mappings. No external ID is assumed valid for every purpose.
Merge, split, and succession
For duplicates, corporate merger, organisational split, or product replacement, retain former and canonical IDs, relationship, time, decision, and downstream migration instead of deleting references.
System of record, attribute authority, and golden record are different
One system may create supplier identity, another own tax status, and a third own payment accounts. A golden record is a view assembled by approved rules; it does not become the original authority for every attribute. Separating these layers explains where conflict and correction begin.
| Concept | Responsibility in master data |
|---|---|
| Source system | Creates or maintains a source record. It may govern some attributes or be only a consumer or legacy source. |
| System of record | The authorised record location for a specified entity or attribute. A domain may have several authorities by attribute, region, or lifecycle stage. |
| MDM system | A capability or platform for modelling, validation, matching, merging, approval, relationships, history, and publishing. It can be authoritative or coordinate other sources. |
| Golden record | A canonical entity view formed under approved matching and survivorship rules, often combining selected attributes. It is a versioned, lineage-bearing governance result—not naturally absolute truth. |
| Single source of truth | A governance principle directing consumers to a defined authority. It neither requires one physical copy nor makes every consolidated table correct. |
| Registry or mapping hub | Manages cross-system identity and mappings while attributes remain at sources. It reduces concentration but still needs resolution, availability, and consistency responsibility. |
Attribute authority matrix
For legal name, state, payment terms, risk class, address, and contact, state definition owner, precedence, effective time, and conflict decision-maker.
Source-to-golden lineage
Every golden value traces to source record, acquisition time, standardisation, match cluster, survivorship rule, override, and version. Merging does not erase sources.
Override and exception
An override needs actor, rationale, evidence, duration, and review. A permanent manual value must not silently block later legitimate source changes.
Treat matching, merging, and survivorship errors as business risk
A missed match leaves a duplicate, but merging two suppliers can mix payments, contracts, and access. Thresholds cannot optimise only overall match rate. Consequential merges need evidence, human review, reversibility, and a plan to correct downstream systems.
Standardise while retaining originals
Normalise case, whitespace, characters, address, phone, and codes for comparison while preserving source value, language, format, and processing version.
Generate candidate pairs
Use stable external IDs, exact keys, or blocking to narrow comparisons. Records missed during candidate generation cannot be recovered by later scoring.
Score fields in context
Combine name, address, contact, birth, or registry evidence by reliability and use, accounting for aliases, shared addresses, household, and corporate relationships.
Set auto, reject, and review bands
Automate high-confidence low-risk pairs, keep clear differences apart, and send the middle to authorised stewards. Approve thresholds from labelled samples and error cost.
Decide clusters and entities
Pair similarity is not automatically transitive: A≈B and B≈C does not prove A=C. Assess the whole cluster, entity type, and conflict constraints.
Apply survivorship
Choose values by attribute authority, source trust, recency, completeness, or authorised decision. Longest or non-null are technical policies, not universal business truth.
Keep undo and replay
Record rules, model, thresholds, cluster, decision, and publications so a false merge can be split, recalculated, and corrected across consumers.
Master data has creation, change, hierarchy, and retirement lifecycles
Core entities do not remain unchanged after creation. Companies rename, merge, move, and retire; product and organisational hierarchies shift. Effective time and historical relationships let current views and past transactions remain intelligible.
Request and create
Define who proposes an entity, minimum evidence, duplicate search, approval, and ID assignment. Emergency temporary creation has expiry and later review.
Enrich
When registries, address services, classification, or people add attributes, record provider, rights, time, and scope. Enrichment is not undeclared authority.
Change and effectivity
Treat name, state, relationship, class, and address as immediate, future-effective, or retrospective corrections and preserve point-in-time history.
Hierarchy and relationship change
Parent–child, ownership, substitute, merger, and split have validity. Current hierarchy must not overwrite aggregation and responsibility used by old transactions.
Deactivate and prevent new use
A former supplier, retired product, or closed site is normally inactive, not erased: block new activity while enabling history, reconciliation, return, or legal duty.
Merge, split, and redirect
Retain retired and canonical IDs, decision, mapping, and references; handle undo, caches, open transactions, and partners. Do not divide history arbitrarily after a split.
Deletion and records retention
Individual rights, expired permission, and records duties may differ. Authorised roles decide anonymisation, restriction, deletion, retention, and propagation; inactive is not deleted.
Master-data publication and synchronisation need a declared consistency model
A corrected master record does not make every downstream copy consistent at once. Specify event, batch, or query distribution, permitted lag, replay after failure, and which version may govern decisions during transition. Otherwise every system may claim its own latest value.
Central query
Consumers query current authority by ID. Define availability, latency, rate limits, access, and business behaviour when the master service is unavailable.
Event or message publication
Publish create, update, merge, split, and deactivate events with ID, version, change type, time, and correlation. Consumers handle duplicates, order, and replay.
Batch synchronisation
Full or incremental feeds define cut-off, version, watermark, deletion marker, checks, resume, and reconciliation. File delivery is not consumer application.
Advance synchronisation and lookup
GS1 describes periodic synchronisation before transactions, point-to-point delivery, and lookup by identifier. Select by business timing and network boundaries.
Write-back to sources
Prevent loops, attribute-ownership conflict, and lost overrides when returning golden values. Rejected and partly successful writes need reconciliation.
Consistency and staleness
Declare strong, eventual, or snapshot consistency, recognisable version, maximum staleness, and whether a critical transaction waits for refresh.
Contract evolution
Schema, enumeration, identity, merge semantics, event type, and deprecation changes enter interface requirements with compatibility, consumer inventory, regression, and cutover evidence.
Master-data quality needs owners, stewards, and closable workflows
Finding a duplicate or error is only the beginning. Owners decide meaning and risk, stewards investigate evidence and handle merge, correction, and exception, and technology keeps rules and propagation reliable. Each issue needs an owner, time, affected scope, and closure evidence—not a permanent red dashboard mark.
Domain owner
Owns business definition, value, risk, and material rules; resolves cross-functional conflict and approves quality thresholds and exceptions.
Data steward
Reviews creation, candidate matches, conflicts, quality issues, and relationships. Segregation of duty and operating capacity must be realistic.
Platform and source responsibility
Platform teams provide processing, interfaces, history, audit, and recovery; sources obtain and correct their attributes; consumers report defects.
Domain quality measures
By use, measure identity coverage, duplicate rate, false merge, missed match, completeness, validity, timeliness, consistency, and relationship integrity with explicit denominator and sample.
Prevention and detection
Duplicate checks, permitted values, authority interfaces, and approval prevent error; profiling, reconciliation, anomaly detection, and feedback find existing defects.
Issue closure
Track root cause, object, source, downstream effect, correction, republication, and verification. Fixing a golden value without fixing its process invites recurrence.
Change governance
Review impact, privacy, security, migration, and rollback before adding a domain, attribute, source, match model, threshold, survivorship rule, or consumer, preserving a reproducible baseline.
Constructed supplier master-data example
This customer-independent supplier domain connects identity, attribute authority, matching, hierarchy, and synchronisation. Thresholds and identifiers remain business decisions. The point is which evidence and workflow address false merge, missed match, and stale downstream copy.
Entity and roles
SUP-1001 identifies the partner legal entity; procurement supplier, payee, and delivery site are effective-dated roles or relationships rather than one name representing entity, account, and place.
Identifier mapping
Retain canonical ID, approved external registry ID, and ERP supplier numbers with source, state, and validity. Without external ID, keep candidate state instead of generating authority from a name.
Attribute authority
Approved registry governs legal name and status, procurement approves terms, bank data uses separate high-risk verification, and authorised supplier evidence confirms contact; each value has time and evidence.
Match decision
Exact registry ID is a strong candidate; similar name and address require review. Two group companies or co-located entities must not merge from similarity. Rule, threshold M1, and human decision remain traceable.
Golden record
Attribute survivorship forms a canonical view while retaining value source, rule, override, and source records. Consumers receive canonical ID, version, and applicable attributes—not an unconditional claim of absolute truth.
Deactivation and transactions
Deactivation blocks new requests while old orders, payments, returns, and audit remain visible under historical identity. Reactivation, merge, or replacement publishes an approved event and is reconciled downstream.
Enterprise AI can assist entity resolution but cannot create master-data truth
Models are useful at finding names, addresses, and possible relationships across formats, which also makes their output look more settled than it is. Governance separates candidates, inferences, and approved facts. AI may narrow an investigation but a confidence score grants no merge or overwrite authority.
Reading a name creates a candidate for review, not a master record
A name, address, or class extracted from a contract, email, or image retains its source location, model version, and unconfirmed status. Only deterministic rules or an authorised person may promote it to an approved attribute. Looking formal on screen does not skip that step.
Evaluate resolution by domain
Measure candidate recall, false merges, missed matches, cluster quality, and high-risk groups separately for customer, supplier, product, and location using temporal representative samples and hard negatives.
Deterministic constraints surround the model
Unique external IDs, prohibited-merge relationships, tenant separation, state rules, and high-risk-field validation cannot be bypassed. A model score cannot enlarge access or overwrite authority.
Human review is actionable
Show necessary source values, differences, relationships, model rationale, and downstream effect; allow confirm, reject, split, and defer while hiding unrelated sensitive fields and recording the decision.
Training and feedback are governed
Before match decisions, corrections, or master data enter training, confirm purpose, rights, minimisation, temporal representation, label quality, period, and approval; do not fossilise old errors.
Golden records still require retrieval authorisation
A unified view improves usability and increases aggregation risk. Filter AI retrieval by user, tenant, object, attribute, and purpose; golden does not mean open to every model context.
Outputs preserve identity and time
An AI answer cites canonical entity ID, master version, and applicable time and distinguishes current attribute from transaction snapshot. A rename must not silently rewrite history.
Model and rule change triggers replay
Compare match model, prompt, feature, threshold, or source changes on frozen evidence and production candidates, stage approved rollout, and keep split and downstream correction capability.
How master data differs from neighbouring concepts
Master, reference, transaction data, and golden records often share a platform but carry different duties. Master data identifies core entities, transactions record events, reference data constrains values, and a golden record is a governed result. The distinction determines who may create, correct, and publish.
| Concept | Boundary from master data |
|---|---|
| Business data | Covers objects, events, transactions, states, documents, decisions, and outcomes. Master data is the relatively stable portion identifying core entities across processes. |
| Reference data | Codes, units, states, and permitted values classify or constrain other data; master data describes identifiable entities. Both need authority and versioning but have different objects. |
| Transaction data | Records interactions such as orders and payments and references master identities. Transactions continuously accumulate; each transaction does not create another same-class master entity. |
| Business object | A person, thing, place, organisation, or concept in a domain. Master data represents its identity and controlled attributes; it is not the object itself. |
| Data requirement | States identity, source, quality, protection, synchronisation, and lifecycle obligations master data must satisfy; master data is the governed dataset. |
| Dictionary and glossary | Describe fields, concepts, definitions, and permitted values. They hold metadata for shared understanding, not customer or product entity records. |
| Golden record | A canonical entity view produced through matching, survivorship, and human rules. Master data also includes sources, mappings, history, and relationships. |
| System of record | The authorised record location for an entity or attribute. It can be an MDM platform or business application, and authority can differ by attribute. |
| MDM | The organisational, process, rule, and technical capability maintaining master data. Buying an MDM product does not create correct entities, authority, or governance. |
| Customer 360 | Combines customer master, transactions, interactions, and analytics. It is broader than customer master data and may be analytical rather than operational authority. |
| PIM | Manages product content, taxonomy, media, and channel publication and may master part of the product domain; it does not automatically govern every enterprise master domain. |
| Dimension data | Warehouse descriptions for analytics, possibly sourced from master data or reshaped for reporting and slow-change history. They are not automatically operational authority. |
Sources and scope
This entry explains master data in enterprise projects: relatively stable data used to identify and describe core business entities consistently over multiple processes, transactions, or systems, together with the boundary needed to preserve identity, authority, quality, relationships, versions, and distribution. Master data is not all important data, a base table, a parameter table, transaction history, a warehouse dimension, a golden record, a single source of truth, an MDM platform, or the whole data-governance system. It does not fully define business data, reference or transaction data, a business-object model, data requirements, data dictionaries, metadata, Customer 360, product-information management, identity authentication, a data-quality system, database design, interface synchronisation, privacy or security policy, or product selection. Authorised roles must confirm master domains, identifier rules, attribute authority, match and merge, survivorship, golden records, change, and approval rights.
- ISO 8000-100:2016 — master-data quality series overview, quality metrics, and organisational and data requirements; confirmed current in 2026
- ISO 8000-110:2021 — syntax, semantic encoding, data-specification conformance, and dictionary access for characteristic master-data messages
- ISO 8000-115:2024 — syntax, semantics, owner, use restrictions, resolution principles, and characteristics of master-data quality identifiers
- ISO 8000-116:2019 — representation of authoritative legal-entity identifiers; confirmed current in 2025
- GS1 System Architecture — entity master data, transaction and event references, unique complete persistent keys, advance synchronisation, direct delivery, and lookup
- GS1 GDSN — automated maintenance, sharing, and synchronisation of timely, complete product master information
- GS1 GLN Allocation Rules — unique identity and new, change, merge, split, and non-reuse rules for legal entities, functions, physical and digital locations
- UK Cabinet Office minimum enterprise data requirements — map critical objects to golden records and authorities, systems, units, relationships, versions, purposes, and retention
- GOV.UK trusted-source guidance — establish a system of record, combine authorities, and use a persistent unique identifier through the dataset lifecycle
- Microsoft Purview/Profisee architecture — standardisation, matching, merging, survivorship, golden records, source links, lineage, audit, and stewardship workflow
- NIST SP 800-63A implementation material — resolve a unique identity within a population and context using minimum necessary attributes, evidence, and conflict resolution
- NIST AI RMF Core — AI data, provenance, quality, representativeness, access, human oversight, measurement, monitoring, and change