How do you know it didn't just do something wrong, quietly?
That's the real question, and it deserves a direct answer rather than a page about security posture. Actions routed through ACE are checked before execution. What happened is recorded in a form you can examine afterwards without taking our word for any of it.
Three separate facts, not one log line.
Keeping these facts separate makes the decision easier to reconstruct. A record of a check is not proof that every underlying input was correct.
Who was supposed to be involved, decided before the action ran, not inferred afterwards from who happened to touch it.
Whether an accountable human actually attached, and held the authority the action required. A person can be present without being authorised. Those are two different facts and they are stored as two.
Whether it was allowed to proceed, which is not the same as whether it was attempted, and not the same as whether it succeeded.
This is the distinction that matters when something goes wrong. “A human was in the loop” and “an authorised human approved it” look identical in a conventional audit log. They are not the same event.
- Routing
- Escalated Above the limit AR runs alone to, so a person has to be involved.
- Authority
- Bound A controller is attached and holds £5,000 on this account.
- Execution
- Permitted Routed to a person, and that person holds the authority it needed.
The write-off runs, under a named controller.
This scripted write-off illustration uses declared example authority, not a verified corporate identity. Routing can say a person was required while authority says nobody qualified, and execution still has to answer on its own. Collapsing them into one status is how a company loses the ability to say which of the three actually happened.
A refusal is the thing that makes a permission worth something.
If a system never says no, “yes” carries no information. These are recorded outcomes, not error states.
You should be able to explain why work moved.
The action the Worker put forward, recorded before anything acted on it.
The rule that was actually governing at that moment, for that customer, not the most recently indexed document.
The sources that supported it, with provenance. Not “the model determined.”
The recorded authority binding and its scope for this action and value. Corporate authority must be established by the customer.
Recorded separately from routing and from authority, for the reason above.
Whether anything the decision relied on has since moved, and if so, what that invalidated.
Consequential work should create its evidence while it happens.
The evidence record preserves what governed, what was checked, who approved and what happened. Integrity checks help detect changes to the record; they do not certify the truth of its inputs, legal authority or regulatory compliance.
OMP
Underneath the record is a protocol. OMP defines what the Boundary computes before a consequential action, and what the Ledger preserves after it.
It exists as a separate, documented thing for one reason: checking a decision should not require trusting the company whose decision is being checked, or the vendor who built the system. The format of the record and the checks that produce it can be inspected on their own terms.
Documented as a protocol in its own right, so an examiner can check a decision without taking VERIDOM's word for the format it is recorded in.
Request the specification →If you can't answer those six today, that isn't an audit problem.
It's the reason your AI is still in pilot.