Most systems log what they did. Far fewer log enough to answer the question that actually gets asked months later, usually by someone who wasn't there: why did it do that?
For software that acts on a business's behalf — updating records, requesting documents, deciding something is complete — that gap is the difference between an audit trail and a list of events.
Three questions a trail has to answer
When an action is questioned, it's almost always one of these:
What happened? The mechanical record. This action was taken against this record at this time. Nearly every system gets this right.
What was it working from? The state at the moment of the decision — what had been received, what was still outstanding, what the process required. This is where most logs thin out, and it's the one that makes the record interpretable rather than just verifiable.
Why was this the outcome and not another one? Whether the action followed from a rule, and which rule. Whether a person approved it. Whether it was escalated, and what happened then.
A trail that answers only the first question tells you an action occurred. It doesn't tell you whether it should have.
Reconstruction is the real requirement
The practical test isn't whether the log is complete in the abstract. It's whether someone can sit down with it — months later, without having been involved, possibly without access to the original conversation — and rebuild what happened well enough to judge it.
That framing rules a few things out quickly.
A log that references data by pointer rather than value fails it, if the underlying record has since changed. "Updated client record" is useless once the record has been updated eleven more times.
A log that records the outcome but not the inputs fails it. Knowing a submission was marked complete doesn't tell you what was in it at the time.
A log that records an escalation without recording what was escalated, and what the person decided, fails it — often at the worst moment, because escalated cases are exactly the ones likely to be questioned.
Escalation is part of the trail
It's tempting to treat handoffs to a person as the end of the system's responsibility. It's the opposite: the handoff is one of the most important things to record.
A complete trail covers why the case was escalated rather than handled, what context the person received, what they decided, and what the system did as a result. Without those, a reviewer can see that something left the automated path and nothing else — which is precisely the case where "the software did it" stops being an adequate answer.
What it's actually for
There's a tendency to treat audit logging as a compliance obligation: something you produce because an auditor will ask.
That undersells it. The same record that satisfies an auditor is what lets a team debug a process that's producing bad outcomes, answer a customer who says they already sent something, and decide whether to widen the boundary of what the system handles without supervision.
An organisation that can't reconstruct why its software did something can't safely give it more to do. The trail isn't paperwork about the system's autonomy — it's the precondition for it.