A master-data domain can be run as a registry, a consolidation, a coexistence or a centralised authoring domain.
The names are the market's; the descriptions are what happens in Lima.
The golden record is a view over the sources. Lima holds the cross-reference and the survivorship decisions; the values stay in the systems that own them. Reads are answered live, and each source applies its own permissions first.
The golden records are materialised for analysis: the surviving values are stored with their history, and the transactions sit beside them in the bed. Sources stay authoritative for changes.
The golden record is maintained in Lima and written back to the systems that own each field, through their released interfaces, with the acknowledgement stored beside the change. Both places stay usable.
New records are authored in Lima first, validated by the rules, approved in the workflow, then published to the consuming systems with the keys they expect.
Most estates land on a mixture. This table is the short version of that conversation.
| Situation | Style | Why it fits |
|---|---|---|
| The ERP stays the system of record and a governed view is what consumers need | Registry | Nothing is copied, so the view is current and the programme starts with reads |
| Planning and BI need stable keys, history and speed | Consolidation | Materialised golden records with their history answer analytical questions at query speed |
| Several systems hold the same domain and each keeps its own processes | Coexistence | Stewards agree the value once; the write-back carries it to each owner with an acknowledgement |
| Creation is where the risk sits: compliance, completeness, approvals | Centralised | The record reaches the consuming systems in a valid state, with the approval recorded |
| A domain in flux during an ERP migration | Registry, then coexistence | Serve reads across both estates first, then take over maintenance when the target is ready |
| Reference data shared by many systems | Registry or centralised | Small domains, published on a calendar, with crosswalks held beside them |
A style change is a setting plus the interfaces the new style needs.
A typical sequence: a supplier domain starts as a registry so the business can see one supplier list within a week; the same domain becomes a consolidation when procurement analytics needs history; then coexistence when the stewards take over maintenance and the write-back to SAP and Oracle is enabled per field.
Each step is a configuration change with its own test: the write-back is proved on one record in a test environment, checked against the acknowledgement, and then released. The integration and sync page covers the interfaces per system, the environments and the promotion gate.
Because the style is set per domain, a company runs several at once. This is the normal end state: reference data as a registry, materials centralised at creation, customers and suppliers in coexistence.
This is the reason a style change stays cheap.
| Part | Held once, applies to every style |
|---|---|
| Identity | The keys, the match rules and the cross-reference of source keys, with merge and unmerge |
| Survivorship | The decisions about which source wins each field, with their history |
| Structures | Hierarchies and levels, several per entity, versioned with dates |
| Rules | Column, row and business rules in one language, over values, combinations and totals |
| Security | Twelve layers for read, write and delete, at column and row level |
| Audit | The append-only ledger of changes and sensitive reads, with point-in-time reads |
| Services | The headless lookup, REST, SOAP, SQL, grids, pivots and drill-downs |
Coexistence, because most enterprise domains are maintained in several systems that each keep their own processes. A domain can be set to any of the four at configuration time, and changed later.
Yes, and it is common. The write-back is enabled per field and per system, so a supplier domain can own payment terms while the ERP keeps the address.
Yes. The 2026 Gartner Critical Capabilities for MDM Solutions scores products against four implementation-style use cases, so a product that covers all four is evaluated in every one. The analyst guide explains how the scoring works.
The setting is immediate. Turning on a write-back takes as long as the interface test for the fields concerned, usually hours per system, and it is released through the promotion gate like any other change.
Bring two systems that hold the same customers, suppliers or materials. In one working day we connect them, run the match on live rows, review the queue with your steward and publish the first golden view with its API.
