Every change to a golden record, a hierarchy, a rule or a code list is an entry in an append-only ledger: the person or rule, the field, the value before and after, the reason, the source record, the rule version.
| when | who | field | before | after | why | entry |
|---|---|---|---|---|---|---|
| 17 Sep 09:41:12 | P. Sharma (steward) | supplier.payment_terms | Net 30 | Net 45 | contract AG-4409 · proposal 4,203 approved | #a91f… |
| 17 Sep 09:41:12 | rule R-118 v4 | supplier.credit_check | pass | pass | re-evaluated after terms change | #a920… |
| 17 Sep 10:02:55 | agent enrich-registry (L1) | supplier.registration_no | — | HRB 24118 | registry receipt 2026-09-17 · auto within range | #a933… |
| 17 Sep 10:15:40 | M. Reyes (treasury) | supplier.iban | read (masked) | read (full) | payment review PR-2026-091 · purpose window 30 min | #a94c… |
| 17 Sep 11:20:08 | feed SAP LFA1 (CDC) | supplier.address.street | Werkstr. 12 | Werkstraße 12 | source change · survivorship unchanged (verified wins) | #a951… |
Entries are chained: each carries the hash of the one before, so a gap or an edit in the ledger is detectable. The ledger is readable by SQL with the same security as the data it describes.
| Event | Logged | Where it shows |
|---|---|---|
| golden record change | person or rule, field, before, after, reason, source record, rule version | record history · ledger |
| merge and unmerge | the source records, the scores, the rule, the decision, the reversal | record history · proposal |
| hierarchy change | node, parent before and after, version, validity, approver | hierarchy history |
| rule run | rule version, rows judged, results, job or person | rule results |
| rule and threshold change | the text before and after, the tester's rows, the approver | configuration history |
| security change | the grant before and after, the approver, the certification | policy history |
| sensitive read | person, column, purpose, policy, expiry | ledger |
| write-back | the call, the acknowledgement or error, the replay | reconciliation |
| agent action | the proposal, its reasoning, the level it ran at, the approval where required | ledger · proposal |
Every hub records who changed what and when. The differences are in depth and reach: some cap the number of history events per record, some leave out changes made by rules, some start history only after a redeploy, and few log reads. Point-in-time views usually cover the master record alone, because the transactions live elsewhere.
Here the ledger is append-only with no cap, covers rule-driven and agent-driven changes, logs sensitive reads, and answers a point-in-time question for master data and transactions together, in SQL.
As long as your retention policy says, per domain; personal data follows the privacy tags. Nothing is trimmed silently.
Yes, as a stream or as signed extracts, with the same security as the data.
Reads of ordinary columns are summarised per session; only sensitive columns are logged per read, and that cost is small.
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.
