The audit record as the product

When an automated system acts on your behalf, why is the log of what it did worth more than the result?

You asked an assistant to tidy up an old project, and it did. The folder looks right. The result is in front of you and it is fine.

Now suppose that a month later someone asks why a particular file is gone. The folder cannot answer. It shows a state, not a history — and the state is consistent with a dozen different sequences of events, some of which you would have approved and some of which you would not. So here is the awkward question: if the outcome cannot tell you whether the right thing happened, what exactly did you receive when you received the outcome?

Begin by separating two things that ordinarily travel together: what happened, and whether it should have. When you do a job yourself, the second question is answered by your own memory, and you rarely notice you are relying on it. Delegate the job, and that memory is gone — unless something wrote it down.

Now ask what the outcome, on its own, can establish. It can show the end state. It cannot show which of several paths reached it. It cannot show what was nearly done and abandoned. It cannot show what the agent read along the way, which matters enormously if any of it was confidential. And it cannot show whose authority was used — your credentials, a service account, something inherited from an earlier step. All of those are questions about the process, and a result is not a process.

Is this any different from ordinary software? Somewhat, and the difference is worth being precise about. A deterministic program's behaviour can be reconstructed by rerunning it: same inputs, same path. An agent's cannot, and not merely because sampling makes it stochastic — its inputs include a world that has since changed. Rerun the same request tomorrow and it may take a different route for entirely good reasons. So the usual fallback, reproduce it and see, is unavailable. The contemporaneous record is not a convenience; it is the only evidence there will ever be.

Then there is the question of authority, which delegation splits in two. The identity that acted is the agent. The identity that is answerable is you. Those are different, and a log that records only one of them cannot answer the question anyone actually asks after an incident, which is not "what ran?" but "on whose behalf, and who agreed to that?" This is why delegated-authority systems record a chain rather than an actor — principal, delegate, scope, and the moment of consent — and why an entry naming only the service account is nearly worthless.

Notice what follows for design. If the record is the thing that carries accountability, then the record cannot be a by-product of the action written by the actor at its own discretion. An agent that logs its own conduct is a witness testifying about itself; it can omit, and it can be manipulated by the very input it was processing. The stronger arrangement is that the log is written at the boundary — by whatever gateway grants the credential and forwards the call — so that nothing can act without leaving the record, because the record is produced by the same component that permits the action.

And once that is true, something inverts. The action becomes the side effect of the audited event, rather than the audit being a side effect of the action. That is what the phrase "the record is the product" means: not that the outcome is worthless, but that the outcome is the part you can see and the record is the part that makes it accountable, and only one of those two can be reconstructed later.

Three refinements, one of them a caution.

First, a record that only names actions is thin. What makes a trail reconstructable is that each entry carries the things that cannot be inferred: which principal, under what delegated scope, with what arguments, against what resource version, and what came back. "Deleted file" tells you nothing you could not have guessed. "Deleted this path, at this version, under this task's scope, granted at this time by this user" can be argued about.

Second, integrity is what separates a log from a diary. Append-only storage, a separate trust domain from the actor, and a tamper-evident structure — entries chained by hash, so a later edit invalidates everything after it — are what let the record survive contact with someone who wishes it said otherwise. Without those properties you have operational telemetry, which is useful for debugging and nearly useless in a dispute.

Third, the caution, and it is the honest limit of the whole idea. Recording an assistant's stated reasoning is evidence of what it said, not proof of why it acted. A model's explanation of its own behaviour is generated text, and there is active research showing such explanations do not always reflect the factors that actually drove the output. So a chain of thought in the log is genuinely useful context and genuinely weak causation. Log the observable facts — inputs seen, calls made, results returned — and treat the narration as commentary.

• What a delegated-authority chain must actually contain to survive a dispute, and how existing token standards express it.
• Why hash-chained or externally witnessed logs are worth their cost, and what attack each property closes.
• How to log what an agent read without the log itself becoming the largest disclosure in the system.

Every term the collection defines is gathered in the glossary.