A domain goes through the same six stages every time: connect the sources, resolve the records, structure them, govern them, serve them and analyse them.
Each stage is testable on its own, which is why the elapsed time is days.
Each capability page lights the stage it belongs to.
| Stage | What happens | Who owns it | Output | How it is tested |
|---|---|---|---|---|
| 01 · Connect | Register the sources and their objects with released read interfaces and credentials | ERP application owner with the data engineer | Objects showing live rows, with each source's own permissions applied | Open the object and read rows; compare a count with the source |
| 02 · Resolve | Standardise, match in pairs, survive field by field, keep the cross-reference | Data steward | Golden records with their source keys and provenance | Review the queue by confidence band; sample merges against known cases |
| 03 · Structure | Build the hierarchies and levels, several per entity, with effective dates | Domain owner | Versioned structures that validate | Validation reports zero orphan leaves in the live version |
| 04 · Govern | Write the rules, set the twelve security layers, confirm the audit trail | Governance lead | A policy every door obeys | Each rule previews the rows it flags; a masked column is checked in grid, API and SQL |
| 05 · Serve | Publish the golden view, the lookup, the services and the write-back | IT architect | Consumers reading one record through one policy | A test write per field and system, checked against the acknowledgement |
| 06 · Analyse | Build the pivots, measures, drill-downs and saved questions | Planning centre of excellence and analysts | Answers on the golden rows, with drill-down to the source | Reconcile a measure against the source system for one period |
Times are from the showcase supplier walkthrough and from engagements; they are labelled, and your estate will differ.
The reason a day is enough for the first view is that each part is tested where it is configured. 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, and those are the parts worth the business's time.
Weeks two to four are the production steps: loading history so point-in-time reads cover the period before go-live, enabling the write-back field by field with a test write each time, and moving consumers behind a router so they can be switched one at a time. The first-domain page covers the day in detail, and the migration pages cover the same path when an old hub is being replaced.
A second domain is faster, because the platform, the rules language, the security model and the team's habits carry over. The catalogue estimates one to six days of configuration per domain.
Each role has its own page with the day it has and the screens it uses.
Owns quality in one or more domains: works the queue, approves merges, fixes values, tunes the match rules.
Stages 02 and 06 →Owns the policy: rules, ownership, security layers, audit evidence, the measures reported upward.
Stage 04 →Owns the source systems: which interfaces are released, what may be written back, and when.
Stages 01 and 05 →Owns the parameters and the measures planning depends on, and the pivots that maintain them.
Stages 03 and 06 →Owns accounts, entities, cost structures and the exposure rules over totals.
Stages 03 and 04 →Owns the integration, the services, the environments and the promotion gate.
Stage 05 →A domain is a service once it is live, and the platform supplies the instruments.
| Running activity | What it involves | Where it happens |
|---|---|---|
| The steward queue | New and changed source records matched, with pairs above the review threshold queued by confidence and value at stake | Stewardship |
| Rule results | Rows flagged by column, row and business rules, worked like any other queue, with the rule version recorded | Rules at three levels |
| Hierarchy versions | Reorganisations prepared as a version with an effective date, validated, then made live with history re-rolled | Hierarchies and levels |
| Reference data releases | Code lists published on a calendar, with crosswalks and the systems that consume them | Reference data |
| Write-back health | Acknowledgements per system and per field, with retries and the freshness per source | Integration and sync |
| Audit evidence | Changes and sensitive reads queried from the ledger for internal and external audit | Audit trail |
| Autonomy review | Which action types the models may complete alone, reviewed on the record of their accuracy | AI-assisted |
Stages 03 to 06 overlap in practice: hierarchies are built while the steward works the queue, and the first pivots appear before the write-back is enabled. Stages 01 and 02 are sequential, since matching needs the sources connected.
One steward per domain for the queue, an owner who settles the agreements, and access to whoever owns the source interfaces. The platform work is configuration by one or two people.
By stage output: objects reading, golden records published, structures validated, rules live, consumers moved, measures reconciled. Each has a screen, so a weekly report is a page that is already written.
The interface is re-registered and the objects re-read; the keys and rules stay. Where a field moves, the survivorship for that group is repointed, and the change is recorded in the audit trail.
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.
