Master data is governed domain by domain: customers, suppliers, materials, sites, accounts, codes.
Each part is a decision the business makes and Lima records as configuration, with its history.
The six are deliberately in this order. Identity comes first because everything else attaches to a record whose boundaries are agreed. Attributes come next, since survivorship is the second conversation the business has. Hierarchies follow, because they group records that already exist. Rules, security and services then apply to a model that is settled.
A catalogue entry supplies a starting point for all six: the keys most estates use, the attribute groups with their usual winning source, the hierarchies the domain tends to need, sample rules at three levels, the security pattern and the lookup API. A programme adjusts them to its own agreements.
Because the six parts are the same everywhere, the learning transfers. A team that has configured suppliers can configure materials with the same skills, and the platform's rules language, security model and audit trail are learned once. The customer entry shows a full worked example.
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.
Customer · Supplier · Business contact · Employee · Organisation units and positions · Distributors and channel partners
Open the group →Material and product · Bill of materials · Product classification · Equipment and assets · Price lists and conditions
Open the group →Plant and site · Warehouse and storage location · Ship-to and delivery addresses
Open the group →General ledger account · Cost centre and profit centre · Legal entity and company code · Bank and payment details · Tax codes and jurisdictions
Open the group →Units of measure · Currencies and exchange rates · Countries, regions and code lists · Calendars and time profiles
Open the group →Planning parameters · Routings and work centres · Sourcing rules · Contracts and agreements · Carriers and lanes · Commodity and tariff codes · Product compliance attributes
Open the group →The same six parts, filled in for the domain most programmes start with.
| Part | The customer domain |
|---|---|
| Entity and keys | One legal buyer. Strong keys: tax id, registration number, national identifier. Standardised: name, address, domain of the email. Deciding evidence: a registry match or a steward's confirmation |
| Attribute groups | Identity (registry wins) · addresses (the verification service wins) · commercial terms (the ERP wins) · credit and exposure (finance wins) · contact and consent (the CRM wins) |
| Hierarchies | Legal parent tree · sales territory · reporting group · payer and ship-to relationships, each versioned with effective dates |
| Rules | Column: tax id format per country · row: a credit limit requires a rating date within twelve months · business: exposure across open orders and invoices stays inside the group limit |
| Security | Bank details masked to all but treasury · rows filtered by region · write on terms restricted to the owner · deletion reserved to the domain owner with a second approval |
| Services | Lookup by any key returning the golden customer and its open orders · REST and SOAP for any field combination · pivots of revenue by territory and month · drill-down to the order rows |
The full entry, with the objects it reads on SAP S/4HANA, Oracle Fusion, Salesforce, Snowflake and Databricks, is on the customer page.
Nothing in the platform is specific to the catalogue domains.
Effort follows the count of attribute groups, keys, hierarchies and systems. The catalogue's estimates run from one day for a small reference domain to six days for a domain like customer or material with several systems and structures; these are estimates from showcase runs and engagements, labelled as such.
A new domain inherits everything the platform already holds: the rules language, the twelve security layers, the audit trail, the services and the grid behaviour. What a programme adds is the agreements specific to that domain.
Where a domain relates to another, the link is held in the bed: a contract refers to a golden supplier, a bill of materials to golden materials, a sourcing rule to both. Cross-domain questions are then ordinary queries.
Most programmes run one domain to production, then add the next in order of pain. The catalogue exists so the shape of each is known in advance.
The catalogue entry is a starting point that is meant to be edited. Keys, attribute groups, hierarchies and rules are all configuration, and the changes carry their own history.
Through keys in the bed. A golden contract points at a golden supplier, a bill of materials at golden materials. Cross-domain rules and pivots then work the same way as single-domain ones.
The one whose errors are being paid for now, and which two or three systems already hold. Supplier and customer are the usual starting points; the why it matters page lists the first wins by function.
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.
