The agent acted.Your books may never have heard about it.
The action and its record are two separate events. This grades what happens when they come apart — and a flawless record is no help at all if the action can stand without one.
The write-back is treated as bookkeeping that happens afterwards.
The agent issues the refund. The money leaves. Then a separate call writes the record, and that call times out. The failure lands in a log nobody reads, and the refund is now a fact about the world with nothing behind it — no actor, no authorisation, no reversal, and no count that will ever come out wrong enough for anyone to notice. Nothing malfunctioned. The action succeeded and the bookkeeping did not, and the system was built to treat those as separable.
The action and the record. If they are written in the same commit they cannot come apart, and the whole failure question stops being asked.
Two paths in the worked example are identical except for what happens when the write-back fails. One reads IN THE RECORD. The other reads UNRECONCILED.
A path carrying the agent identity, the authorising verdict and a reversal handle still reads UNRECONCILED if the action stands when the write fails.
Move the write into the same commit and watch a question disappear.
The action and its record cannot come apart, and the record is usable once it is there.
1,524 write-backs a day. The busiest path in the example is not the worst one, and the path that runs four times a day reads at the top.
This grades a path, never a person, and says nothing about whether the action should have been taken.
The full output on the worked example, verbatim.
Eight write-back paths across six systems of record, one command, no dependencies. This is the complete run, pasted as printed.
WRITE-BACK RECONCILIATION WARDEN - did the record follow the action spec_version 1.0.0 | 8 write-back paths read PATH ACTION RECORD QUALITY ON FAILURE VERDICT DECIDED BY ---------------------------------------------------------------------------------------------------------------- W-01 Refund issued IN THE RECORD action_reversed IN THE RECORD - W-02 Discount applied IN THE RECORD action_stands UNRECONCILED on_writeback_failure W-03 Subscription cancelled IN THE RECORD not asked IN THE RECORD - W-04 Ticket auto-closed PARTLY IN retried_then_flagged PARTLY IN on_writeback_failure W-05 CRM stage advanced IN THE RECORD action_reversed PARTLY IN batched_window W-06 Outbound email sent UNRECONCILED action_stands UNRECONCILED on_writeback_failure W-07 Inventory reorder placed PARTLY IN action_reversed PARTLY IN actor_recorded W-08 Access grant provisioned PARTLY IN not asked PARTLY IN authorization_link WRITTEN IN THE SAME COMMIT W-03 cannot come apart from its action, so the failure question is not asked of it. W-08 cannot come apart from its action, so the failure question is not asked of it. OPEN DIVERGENCE WINDOW W-02: the action stands when the write-back fails - and its record is otherwise flawless, which changes nothing W-06: the action stands when the write-back fails ACROSS EVERY PATH 2 of 8 paths are IN THE RECORD VERDICT: SOMETHING HERE IS UNRECONCILED FIX FIRST: W-02 (UNRECONCILED) - start at on_writeback_failure REPORTED, NOT GRADED 2 path(s) can leave an action in the world with no record of it. 1 path(s) spend a complete record on an open window. 1524 write-backs a day across every path. This figure is compared against nothing. This grades a path, never a person, and says nothing about whether the action should have been taken.
W-03 has action_stands written against it and reads IN THE RECORD, because the record shares a commit with the action and the question does not apply. W-02 has a flawless record and reads UNRECONCILED.
Three rules, and the reason each one is not negotiable.
If the record is written in the same transaction as the action, they succeed or fail together and there is no window to have a policy about. That is the only answer that removes the problem rather than managing it, and it is usually the cheapest change available.
A perfect record of the actions that got written says nothing about the ones that did not. So the failure answer sets a ceiling the record cannot lift, and a thin record that reverses reads better than a complete one that does not.
Three things make it usable afterwards: it says a machine acted, it points at what authorised the action, and it tells you what to undo. The record takes its weakest one, because a record complete except for one thing is missing that thing.
A structural check, not a data-quality tool.
- A read-off of whether each automated action can happen without leaving a record.
- A runnable engine, a workbook that reproduces it, and a demo that agrees with both.
- A named list of the paths that can leave an action in the world with nothing behind it.
- An emitter: one flag and the finding comes out as a verdict envelope.
- A data reconciliation tool. It never compares datasets or matches values.
- A judge of whether the action should have been taken.
- A retention or audit-readiness check. What you keep and for how long is a different question.
- A scanner. Every input is an answer you supply about your own wiring.
Scope: this is an engineering instrument. It grades a write-back path, never a person, and asserts no regulatory position. It does not tell you whether your records are correct or whether an action should have been taken, and it is not legal advice.
For the stack where software writes into the books.
- Something automated takes actions that end up in a ledger, a CRM, a billing system or an identity provider.
- You could not say which of those writes happen in the same transaction as the action itself.
- Somebody has asked how many refunds an agent issued last month and the honest answer was a range.
- You are building the record leg of an automated decision and want the contract settled first.
- Every automated action already writes its record in the same commit. There is nothing here to find.
- You need to compare two systems and find mismatched values. Different instrument.
- You want to know whether the record is correct. This asks whether it exists and is usable.
The three it sits between.
What a decision payload must carry to bind a machine. It is what the authorization link in a good record points at.
OpenWhether you keep records at all, and for how long. This asks the narrower structural question of whether the action could have happened without one.
OpenCompares datasets and finds mismatched values. This never compares data — it asks whether a record exists and is usable.
OpenDirect answers, before you buy.
An action with no record
is an action nobody can answer for.
One purchase, lifetime access, 12 months of updates. $99, once.
Scope: an engineering instrument. It grades a write-back path, never a person, asserts no regulatory position, and is not legal advice.
Sold by RedHub AI LLC · Secured by Stripe · redhub.ai