An Audit Trail Is Not an Evidence Trail

Digital systems are very good at remembering what happened inside digital systems.

• A user logged in.
• A field changed.
• A record was approved.
• A transaction was submitted.
• A timestamp was created.

These histories can be very useful. They help organizations understand who interacted with a system, what changed and when.

But there is an important distinction:

That distinction leads to another concept: the evidence trail.

The difference begins outside the computer

Imagine a food-safety employee enters:

An audit trail might establish:

• which account entered 38°F;
• when the entry was created;
• whether it was subsequently changed;
• who reviewed it.

Those are valuable facts.

But consider the physical-world questions:

1. Was the employee standing at the cooler?
2. Was a thermometer actually read?
3. Which cooler was observed?
4. Was the measurement made at the recorded time?
5. Was the reading associated with the correct operation?
6. What independent evidence, if any, supports the observation?

Those questions cannot necessarily be answered by examining the history of the database field.

Traceability already recognizes relationships

This distinction becomes especially clear in supply chains.

GS1’s traceability framework identifies objects and the events that happen to them throughout their lifecycle. Its framework addresses who, what, where, when and why, and explicitly includes transformation events in which inputs become outputs.^[1]

FDA’s Food Traceability Rule similarly requires records associated with defined Critical Tracking Events and requires relevant Key Data Elements to be linked to traceability lots.^[2]

These structures matter because isolated records are far less useful than connected records.

An invoice alone tells one story.

A production record tells another.

A shipping record tells another.

Connect them through a traceable object and sequence of events, and they begin to describe what happened to something in the physical world.

From event history to evidentiary relationship

An evidence trail takes that idea further.

It asks not only:

What events are recorded?

but:

What supports the assertion that each event occurred?

Consider the difference:

The first describes interactions with a system.

The second attempts to preserve the evidentiary relationship between the system and the physical world.

Evidence gains meaning through context

• A photograph is not automatically evidence of a particular event.
• A timestamp isn’t necessarily evidence that a physical activity occurred at that time.
• A signature doesn’t necessarily establish what the signer observed.
• A sensor reading without an identified device, location or object may have limited meaning.

Evidence becomes powerful through context and relationship.

1. What does this evidence concern?
2. Which event does it support?
3. Which object was involved?
4. When was it generated?
5. Where?
6. By whom, or by what system?
7. What happened to the object next?

Preserving those relationships as operations occur can make the resulting evidence far more useful later.

Why this matters

The distinction matters whenever the stakes are higher than simply knowing what someone typed into software.

Food safety. Manufacturing quality. Healthcare operations. Maintenance. Construction. Logistics. Chain of custody. Environmental compliance.

Anywhere a digital system makes an assertion about a physical-world event, there is potentially a gap between recording and establishing.

That gap often remains invisible until somebody challenges the record.

Then the organization begins reconstructing what happened.

The next generation of operational systems

For decades, digitization has focused on replacing paper.

That was necessary.

But replacing a paper form with an electronic form doesn’t fundamentally solve the evidence problem.

The next generation of operational systems should increasingly ask:

1. What is the physical-world assertion being made?
2. What evidence supports it?
3. Can that evidence be associated with the relevant object and event when it is created?
4. Can another authorized person later examine that relationship?

Those questions move operational software beyond electronic recordkeeping.

They move it toward verification.

An audit trail remains important.

But when the question is not merely “What did the software record?” and instead becomes “What actually happened?”, we need something more.

We need an evidence trail.