Enforcement is what makes quality a property of the golden record itself. A record is in flow while checks run and corrections are pending, golden once every applicable rule passes, and quarantined the moment a rule fails later.
A quarantined record returns to in flow when a correction is applied, and passes gate one again when its rules pass. The state is data on the record, so a question 'as of 31 March' shows the state the record had on that date, and the promotion and quarantine events are entries in the audit trail.
The gate is strict on purpose: a golden record is a promise to every consumer, and the promise is only worth making if it holds. Weighted fields keep the all-pass rule; a domain owner can relax the gate for low-weight groups with a threshold, and the relaxation is a facet with a history.
Because the state is enforced at the platform, every door behaves the same way. A satellite application calling the headless API receives a failed record only with its state and its reason; a pivot excludes quarantined rows from totals unless asked to include them; a write-back waits. The consumer's own code needs no quality logic.
A contract states thresholds per dimension for one view, signed by the consumer and the owner.
A breach does three things: it notifies the consumer with the records and the dimension, it holds the feed or the write-back if the contract says so, and it opens a ticket for the owner with the root cause. The treasury contract above held the bank-details feed on 312 aged verifications; the verifier re-ran them the same morning.
| Door | In flow | Golden | Quarantined |
|---|---|---|---|
| Grid | Badge 'pending'; editable; the open ticket one click away | Served | Badge 'quarantined' with the failing rule; editable |
| Headless API | Returns the record with a status field and the pending checks | Returns the record | Returns the last golden version with status 'quarantined' and the reason |
| SQL and pivots | In a separate view; excluded from totals by default | Visible | Excluded from totals by default; a flag column names the rule |
| Write-back | Held | Runs, acknowledged | Held until the correction passes the gate |
| Assistant and agents | Answers name the state before the value | Answers as fact | Answers with the last golden value and the reason it is held |
At first. On the showcase supplier domain 312 of 9,340 records were held on day one, most by the bank-details timeliness rule; after the verifier's first run 41 remained. The number of held records is the work list, which is what the gate is for.
Yes, with the status field, through a view that says so. A planning feed that wants only golden reads the golden view; an analyst who wants everything reads the full view with the state as a column.
The owner of the domain and the owner of the consuming system, on the contract's page; the platform monitors it and reports breaches to both.
A rule that a class of records will always fail becomes an excusal, owned and reasoned, and the excusal is visible on the scorecard. A record with no basis for a fix goes to the steward as it is.
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.
