Your logs say what happened. They can't prove it.

When an automated system or AI agent does something expensive, 'we have the logs' is the standard answer — and it doesn't survive contact with an auditor, a bank, or a buyer. What proof at the moment of decision looks like, in plain language.

The conversation every operator eventually has

A discount stacked three times and an order shipped at a loss. A payment job released funds twice. An AI assistant bought something nobody asked for. And someone — your auditor, your bank's dispute team, your biggest customer — asks the reasonable question: who decided that was allowed?

The standard answer is “we have the logs.” And the logs do say something: a request came in at 14:32:07, a service returned 200, an order was created. But watch what happens when the person across the table pushes back. Logs can be edited by whoever runs the logging system. Logs get truncated by retention policies. Logs record what the code did, not what the rules said it should do. And crucially, logs are yours — accepting them as proof means trusting you.

Describing is not proving

A log line is a description written by the system being questioned. Proof is something a skeptical outsider can check without taking your word for it. The gap between those two is where disputes, chargebacks, failed audits, and unrecoverable arguments live — and automation has made it wider, because systems now commit thousands of consequential actions per hour with nobody watching in real time.

Our research note on this, The Execution Verifiability Gap, works through the problem formally. The plain-language version is this: after-the-fact records reconstruct a decision that was never actually made anywhere. There was no moment where the rules were consulted and an answer was produced — there was just code running, and later, an explanation assembled from its exhaust.

What proof at the moment of decision looks like

Flip the order of events. Before the consequential action runs — before the order commits, before the funds move, before the agent's purchase goes through — the action is submitted to a decision step. The rules are evaluated. The answer comes back: allow, hold for a person, or block. And the whole thing — what was proposed, which rule version applied, what was decided, and why — is written into a record and cryptographically signed at that moment.

Now replay the conversation. Who decided that was allowed? Here is the record. It names the rule. It is signed, so it cannot have been quietly edited afterwards. And the person across the table can verify it themselves — the check runs against a published key, not against your dashboard. The proof no longer depends on anyone trusting you.

“But we'd never fake our logs”

Of course not. That is not the point. The point is that the other side has no way to know that — so every dispute starts from zero, every audit re-derives everything, and every serious buyer discounts your records because they have to. Signed decisions do not protect you from your own dishonesty; they release everyone else from having to price it in. That is worth real money in shortened disputes, faster audits, and deals that close without a diligence crawl through your logging architecture.

Where to start

You do not have to sign everything. Start with the actions you would have to explain to someone else if they went wrong — the checkout, the refund, the payout, the agent's spending. Those are the decisions worth making explicitly and keeping proof of. The decision authority page describes the category; the sandbox lets you trigger a refusal and hold the signed record in your hands in about a minute, no account required.