Every serious system logs. Records are timestamped, changes are captured, and if anyone asks whether an action took place, there is an answer.
Then a genuine question arrives — why was this application refused in March, who decided, and what were they looking at — and the logs turn out to answer a neighbouring question instead.
Recording the change is not recording the decision
A typical audit record says a field changed from one value to another, at a time, by a user ID.
The questions that actually get asked are:
- What information was in front of the person when they decided?
- Which rule or version of policy applied at that moment?
- Was this automatic or did somebody choose it?
- If it was automatic, what did the system take into account?
- Who could have seen this record, and did they?
None of those are reconstructable from a field-level change log. Some are not reconstructable at all after the fact, which is the part people discover too late.
Capture the inputs, not just the output
The design difference is small and consequential: record the state that produced the decision, at the moment it produced it.
That means the values as they stood, the version of the logic that ran, the contributing factors and their weights where a model was involved, and what a person subsequently did with the result — accepted, overrode, escalated. Overrides are particularly worth capturing, because a pattern of them is usually the most useful signal a service produces about itself.
We built RailGard AI this way for safety-critical rail work, where a fatigue score has to be defensible factor by factor rather than taken on trust, and ECS Group Command carries the same pattern across nine service areas.
Access is part of the trail
For services holding personal data, who read a record often matters more than who changed it. Unauthorised access leaves no trace in a change log, because nothing changed.
Read logging is unfashionable — it is high volume and adds no visible feature — and it is the only thing that answers a question that gets asked reasonably often.
Retention, and the point of it
An audit trail is only useful for as long as it is kept, and keeping everything forever is neither lawful nor sensible for personal data. Retention has to be decided deliberately, per category, and enforced automatically. A rule that depends on someone running a script each quarter is not a rule.
The test worth running
Take a decision your service made six months ago. Without asking the team who built it, reconstruct why it came out that way.
If that takes more than a few minutes, the trail is recording activity rather than accountability — and the gap is far cheaper to close now than during an investigation.
Building a service that has to show its working? Get in touch, or read about our public sector work.