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. Every consequential action is checked before it happens. 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.
Most systems collapse these. Keeping them apart is what makes an action provable rather than merely recorded.
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.
Three results, moving separately. 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 verified binding, and whether it covered this action at this value.
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.
Reconstructing an audit trail after the fact is a different activity from producing one at the moment of decision, and only the second one survives contact with a regulator. You don't have to take our word for it. the record can be checked independently.
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.