The specification

Eight fields, or it is just a log.

Each one exists because an investigation ends on it. Miss one, and that is the question you cannot answer under oath.

The actor: Which agent acted — and whether a human was in the loop, which is a separate fact from which human.
The action: What was done, in a vocabulary a tool you did not write can still read.
On whose behalf: The customer or person it acted for. Without this there is no per-customer answer, complaint, or erasure.
The approver: The named person who signed off, taken from an authenticated session — never from the request. The field every investigation ends on.
The reason: Why — mandatory on adverse decisions, because a verdict without a reason already fails disclosure rules in force.
The fingerprints: A cryptographic digest of what went in and came out, so integrity is provable without the trail holding your data.
The rule: Which policy evaluated the action, its version, and whether it was enforcing or only watching.
The order: Each entry carries the fingerprint of the one before it — so “nothing was inserted, removed or reordered” is checkable, not asserted.

As a row on the chain

One entry, all eight.

The wire from the demo, as the record holds it — every field above is a field on this block.

006 · Action11f0545e

Wire transfer, $50,000

Actor: payments-bot · on behalf of customer 8841 · approved by priya@lender.io — “verified against the signed payout schedule” · rule: above $10,000 a named person signs, enforcing

004 · Rule10e5957e

Wire transfer held

Fingerprint of what the agent acted on · rule: above $10,000 a named person signs · decision: held · reason: $50,000 is above the $10,000 threshold

The test

Hand it to a stranger.

A trail only the vendor can check is a claim. The whole exercise is what happens when someone who does not trust you runs the check.

anyone, anywhere — with nothing but Node

node -e "const b=require('./evidence.json');require('fs').writeFileSync('verify.mjs',b.verifier)"
node verify.mjs ./evidence.json
✓ VERIFIED — chain intact, checkpoints countersigned

That is our export being verified offline: no account, no API call, nothing from us. The verifier recomputes every fingerprint and names the exact sequence where any edit began.

What this does not prove

Verification proves the records were not altered after they were sealed. It cannot prove the trail is complete — an action that never reached it is not in it, and no signature can say otherwise. Coverage is a property of your deployment, and an honest vendor never conflates the two.

Asked precisely

Four questions that define the artefact.

Including who can actually demand yours — where the first answer, in practice, is a customer rather than a regulator.

Is an application log an audit trail?

No, for three reasons that survive any amount of log volume: it can be edited without trace, it expires before the obligation does, and it names a service account where an investigation needs a person. A log records that something ran; a trail proves what happened.

Do agent frameworks provide one?

They provide traces — excellent for debugging, built for engineers, mutable, and short-lived. Some emit OpenTelemetry spans, which is genuinely useful: a trail can be built from the same spans. The framework gives you the signal; it does not give you the evidence.

Who can demand ours?

A regulator under the EU AI Act's logging duty, an examiner under SEC 17a-4 or FINRA supervision, a court in discovery, and — most often in practice — an enterprise customer's security review before they sign. The last one arrives years before the others.

What makes a trail verifiable rather than trusted?

The check runs without the vendor. Ours exports one self-contained file — events, checkpoints, public keys, and the verifier itself — and the auditor runs it offline. If verification requires our servers, our account, or our goodwill, the trail is a claim with extra steps.