Lima builds the golden records for your customers, products, suppliers, sites, accounts and every other domain from the systems you run, keeps them in their hierarchies, guards them with rules, security and an audit trail, and serves them to people, applications, planning systems and agents through grids, pivots and APIs. The source rows stay where they are; the golden record is a governed view over them, materialised only where latency needs it.
The foundation pages explain what master data management is, why it pays for itself, how this one is built and what a domain is. The capability pages sit one level down, grouped into six sets.
Master data, golden records and hierarchies defined in plain words.
The definition →One duplicated supplier, the eight places it surfaces and what it costs.
The business case →Three layers: read in place, hold in one data bed, serve under one policy.
The architecture →Registry, consolidation, coexistence and centralised, chosen per domain.
How it is run →The six parts of any domain and how to add one of your own.
The scope →The six stages, with the owner, output and test of each.
The lifecycle →Connect, model, match, review and publish, on your own data.
Book the day →Every domain goes through these six. The capability pages are grouped the same way, so a reader can follow one stage from the definition to the mechanism.
Each stage links to the capability that carries most of its weight. How a domain runs gives each stage its owner, output and test.
Every enterprise keeps the same customer, product or supplier in several systems, each with its own number, spelling and address. Lima reads those records where they are, standardises them, matches them in pairs, and assembles one golden record field by field, keeping the source keys underneath so the merge is explainable and reversible.
The golden records are then placed in their structures: levels and hierarchies, several per entity, kept as versions with dates. Reference data, hierarchies, dimensions, master records and transactions sit in one data bed with keys the platform enforces, which is why a pivot on golden customers by month is one query and why a merged customer's orders move with it.
Rules at three levels, twelve security layers and an append-only audit trail apply to every door: the steward's grid, the pivot, the REST and SOAP services, SQL, the agent endpoint. Learning the platform once is enough to govern thirty domains.
Each set carries one stage of the work. Every page explains the mechanism, then shows it on one domain.
Golden records · stewardship · AI-assisted · integration and sync
Open the set →Hierarchies and levels · reference data · the data bed
Open the set →Rules at three levels · twelve security layers · audit trail
Open the set →Headless API · data services · federated display
Open the set →High-performance grids · cell display · drill-downs
Open the set →Time series and pivots · data entry · compare measures · workbench · visualization · querying
Open the set →A separate section, thirteen pages: every rule runs as a small agent with a scope, a schedule and a level of autonomy it has earned; corrections are proposed with evidence, written back and acknowledged; a record is golden only while every applicable rule passes.
The loop on every record: profile, check, propose, decide, write back, learn. The concepts, the configuration and the mechanics, page by page.
Open the section →From finding to learned outcome: evidence, proposal, decision, the change on the golden record, the write-back and its acknowledgement.
How corrections run →In flow, golden, quarantined; the publish gate; what every door does in each state; quality contracts with consumers.
How enforcement works →This is the design decision the rest follows from; the architecture page has the three layers in full.
A supplier exists as a vendor in SAP, a supplier in Oracle, a party in the portal and a row in the lake. Lima reads the four where they live, matches them and publishes one golden supplier. The purchase orders in SAP and Oracle keep their vendor numbers; the cross-reference maps both to the golden id, so 'open orders for this supplier' is a join, and the answer is live.
Because the rows stay in place, a domain is ready to build on the first day: register the objects, and the match runs on live rows. Each source applies its own permissions when Lima reads, and the twelve platform layers apply on top. Where a source is too slow or too limited to query live, the Backbone lands a governed replica in your lake under the same keys, security and audit.
Read how Lima master data is built for the read, hold and serve layers, the deployment options and the performance mechanisms.
Parties, products, locations, finance, reference data and supply chain. Every catalogue entry names the golden record's attribute groups, the match keys, the hierarchies, sample rules at three levels, the transactions that refer to it, the measures, the drill-downs, the security pattern and the lookup API, with one page per system.
The six parts of any domain, the six groups, and how a domain of your own is added.
The scope →Thirty domains with filters by group, system and industry, and 127 pages naming the objects read and written per system.
Browse →What the customer domain reads and writes in SAP S/4HANA, field by field, with the interfaces and prerequisites.
An example →Every part is tested where it is configured, which is why the elapsed time is days.
A source shows its rows the moment it is registered. A match rule shows which live pairs it selects as it is typed. A rule shows the rows it would flag before it is saved. The work that remains is the agreements: what counts as the same thing, which source wins each field, who stewards the domain.
How a domain runs gives each of the six stages its owner, its output and its test, with the first day hour by hour and the activities that keep running after go-live.
Rules, security and the audit trail are part of the platform, so every domain inherits them.
Every change to a golden record is an entry in an append-only ledger: the person or rule, the field, the value before and after, the reason, the source record it came from and the version of the rule that judged it. Reads of sensitive columns are logged too, with the policy that allowed them. A question 'as of 31 March' reads the record and its transactions as they stood together on that date.
In the showcase estate, a treasury audit of supplier bank changes ran as a query over the ledger: 412 changes in the quarter, every one with its two-person verification, zero payments to an account changed within the previous seven days. The audit trail page has the pattern.
Every figure on these pages is labelled production, showcase estate, anonymised engagement, estimate or dated source.
A $20B telecom leader maintains global customer and product codes across three divisions on Lima, feeding activation, forecasting and demand planning.
A $75B semiconductor equipment maker mastered materials across plants ahead of a 1,000-table planning integration.
A $10B high-tech manufacturer consolidated three ERPs' vendors into one supplier list.
The supplier walkthrough on the showcase estate: two sources, 41,800 records, one working day.
The 2026 Gartner Magic Quadrant for Master Data Management Solutions names eight mandatory features and scores four implementation styles.
The eight duties and where each one sits in Lima are tabulated on what master data management is. The four styles have their own page: registry, consolidation, coexistence and centralised, chosen per domain.
How analysts categorise MDM covers the evaluation criteria, the inclusion thresholds and the vocabulary, with dated sources. The comparison pages answer nine questions for fourteen products.
Read in this order for a briefing: what it is, how it is built, the styles, the capabilities, the stories.
The golden records are built from rows read in place, so a domain starts the day the systems are connected. Where a source is too slow to query live, or where analytics needs history at scale, the Backbone lands a governed replica in your lake and Lima reads it there, under the same keys, security and audit.
Any of the four, per domain. A domain can run as a registry (a golden view, nothing copied), a consolidation (golden records materialised for analytics), a coexistence (maintained here and written back) or centralised (authored here first). Switching is a setting; the model, rules and history stay.
Through the same connectors the rest of the platform uses: released read interfaces and change capture for reads, BAPIs and IDocs or REST resources for writes. Every catalogue entry names the objects and interfaces per system.
They sit in the same data bed as the master data, with keys the platform enforces. That is what makes pivots on golden dimensions, drill-downs to orders and business rules over totals possible on one page.
The people who own each domain, in a queue sorted by confidence and value at stake. Models and rules propose; people approve where judgement matters; automation earns autonomy per action type and can be taken back.
By platform capacity. Domains, records, attributes and users are included in the tier; there is one price for the platform, written before the work starts.
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.
