A finding becomes a ticket with the evidence snapshot; the corrector proposes a fix with its basis and a confidence; a person or, within limits, the agent decides; the golden record changes and is versioned; the agreed value is written back to the owning system and the acknowledgement is stored; and the decision teaches the model.
| Step | What happens | Recorded |
|---|---|---|
| 01 Finding | A rule agent fails a record and takes an evidence snapshot: the values seen, the rule version, the run | Finding id, rule, evidence |
| 02 Proposal | The corrector drafts a fix with its basis (a list, a winning source, a verification result, a learned mapping) and a confidence | Before, after, basis, confidence |
| 03 Decision | At L1 or L2 a person decides on the escalation screen; at L3 the agent decides when every guard holds | Who or what, the guard verdicts, the time |
| 04 Golden record | The value changes; the record gets a new version; consumers see the change at the next read | Version n → n+1, ledger entry |
| 05 Write-back | The agreed value goes to each owning system through its released interface, per field | Interface, request, attempts |
| 06 Acknowledged | The source confirms; the change is complete only now, and the golden tag is set | Acknowledgement per system, document numbers |
| 07 Learned | Accepted and rejected proposals train the model for that action type | Training example, model version |
Sorted by confidence and by value at stake, with the explainer's reason on each ticket.
Six tickets from the showcase queue. The first was applied by the agent inside its budget; the second waits for two people in treasury; the last has no proposal and goes to the steward as it is.
Identical fixes are grouped: 1,204 records with “United Kingdom” in the country field become one proposal, “United Kingdom → GB”, with the count, the confidence and a sample. The steward approves the set once, or the agent applies it at L3 within its budget. Each row still gets its own ledger entry, its own version and its own write-back acknowledgement, so the audit trail reads per record.
A set is capped by the daily budget of the action type; a set larger than the budget runs across days and reports progress. A set whose acceptance falls during review is paused and returned to the steward.
Rollback restores a record to a previous version, with the write-back reversed through the same interface and acknowledged in the same way. Unmerge restores the source records of a merged golden record and moves the transactions back. Both are ordinary actions with their own ledger entries, so a mistaken bulk correction is undone as a set.
Corrections that touch a field with the four-eyes mark go to two people whatever the level; the corrector prepares the evidence and the two people decide. The verification page covers the treasury pattern for bank details.
Every decision is a training example for the action type: an accepted country mapping raises the confidence of that mapping; a rejected one lowers it and adds the steward's reason. On the showcase estate the country-standardisation model went from 88% confidence on day one to 99.9% on day ninety, from 141 decisions a day.
Learning is per estate, on the estate's own data, inside Lima's environment. Definitions can be co-drafted with an outside model; row data stays inside. A model version is recorded on every proposal, so a change in behaviour can be traced to the version that caused it.
Country-code standardisation on the showcase estate, from the stewards' own decisions.
The rejected ones carry the reason and train the model; a rising rejection rate demotes the agent by policy.
Reported for the illustrative consumer-goods estate after ninety days.
So a change in behaviour is traceable to the version that caused it.
The change stays pending on the golden record with the rejection reason, retries on the connector's schedule, and escalates to the application owner after the retry budget. Consumers reading the golden record see the pending state.
Yes, and the next read picks it up: the finding closes when the rule passes on the new value, whichever system it was corrected in. The at-the-source page covers corrections at creation.
Two agents proposing different values for one field produce one ticket with both proposals; the decision goes to a person, or to a weighted arbitration inside a spread the owner has set, with the outcome recorded.
The escalation route is the workflow: a screen network with hops and SLAs, where the ticket carries its evidence and accumulated fix from screen to screen. The SmartApps pages describe the screen networks in full.
Bring one domain and two systems. In a week the sources are profiled, the ten costliest fields are under rules, the first corrections are written back with their acknowledgements and the publish gate is on.
