Being able to prove what happened is a structural property. You either build it in at the start or reconstruct it expensively later, usually under time pressure and usually incompletely. An audit history is not a log. A log serves engineers debugging today. An evidence record serves somebody outside the company months from now, who will not accept what the system says at present as an answer about what it said then.
What people mean when they say the system keeps a history
A last-modified stamp is not a history
Knowing who touched a record most recently tells you almost nothing. It cannot say what changed, what the value was before, how many times it changed, or who changed it earlier. It is a single overwritten field pretending to be a record of events.
The report regenerates and answers a different question
Somebody asks for a copy of what was sent. The system rebuilds the document from current data and produces something that looks right. It is not the document that was sent; it is today’s version of it. The difference stays invisible until the recipient puts their copy next to yours.
The trail exists but nobody outside engineering can read it
Events are being written, in a format designed for troubleshooting, referencing internal identifiers. Answering a question from it takes a developer and an afternoon. That works once, not when the requests become routine, and nobody ever checks the trail proactively.
Retention was never decided, so the answer is until the backups rotate
How long history survives turns out to be an accident of infrastructure rather than a decision. Sometimes evidence disappears before the period you are obliged to cover. Sometimes you are holding personal data long past any reason to, which is its own problem.
Everything is recorded, including things you would rather not hold
Comprehensive logging captures full record contents on every change, duplicating sensitive fields into a store with different access controls than the original. Over-collection is a real risk, and it usually results from turning logging on rather than designing it.
The question, the record it needs, and the usual gap
Work backwards from the questions rather than forwards from the data. These get asked in disputes, audits, insurance claims, and licensing reviews. Each has a structural requirement that must have been satisfied at the time, not afterwards.
| Question you may be asked later | What must have been recorded at the time | Where teams usually fall short |
|---|---|---|
| Who approved this, and what were they looking at? | The approver’s identity, the moment, and a snapshot of the record as it stood then | Storing the approval flag but not the state approved, when the record has changed six times since |
| Was that person authorized to do that? | The permissions in force for that person at that moment, not the ones they hold now | Reading permissions live, so a later role change silently rewrites what was allowed |
| When exactly did the customer receive it? | Send time, delivery or bounce result, and the exact address it went to | Recording that a message was queued and treating that as delivery |
| Is this the document they actually signed? | A stored copy of the exact file presented, with a version marker or content hash | Regenerating from live data, producing the current version of an old agreement |
| Why was the standard rule not followed here? | A reason captured at the moment of the exception, attached to whoever entered it | An override field with no reason field beside it, so the what survives and the why does not |
| What did the person in the field actually observe? | The capture with its own timestamp, and where it matters, device time and location | Trusting the upload time, which can be hours later and somewhere else |
| Has anything been changed since? | An append-only history where edits create rows and deletions are marks, not removals | Updating rows in place, so the only trace of a change is that the value differs |
| Who else has seen this record? | Access events on the records where viewing is itself significant | Logging writes but never reads, which is fine until the question is about disclosure |
| Was this work reviewed as required? | The reviewer’s event, separate from the submission, with its own actor and time | One combined completed state that cannot distinguish doing the work from checking it |
Structuring the record so a later question has an answer
Write events and derive states
The durable thing is the event: who did what to which object, when, with what before and after values. Current state becomes something you compute rather than something you overwrite. This inverts how most business systems are built, and it makes everything else here possible.
Freeze the artifact, not only the fact
When a document is sent, signed, or presented, store the rendered file exactly as it was, not the data needed to rebuild it. Rebuilding silently incorporates every change since. Keep the source data too, but the copy that was in front of the person is the evidence.
Capture the reason at the moment of the exception
Any action deviating from the normal path should require a reason before it completes. Asked at the time, the reason is accurate and takes a moment. Asked later, it is a reconstruction, and everybody knows it. A short list plus a note beats free text alone.
Keep the evidence store separate from the working store
Operational data gets corrected, merged, archived, and cleaned up, all legitimately. Evidence must not be subject to those operations. Different table, different permissions, no update or delete path from the application, and a longer backup horizon.
Decide retention and disposal deliberately
For each class of record, write down how long it is kept and what happens at the end. Two failure modes sit either side: destroying something you were obliged to produce, and holding personal data with no remaining reason to. An infrastructure default is not a decision.
Give the trail an interface a non-technical person can use
A history requiring a developer to query is a history nobody checks. Build a plain view on the record showing what happened in order, in business language, with names rather than identifiers. It also improves data quality, because people behave differently when the record is visible.
Systems where evidence questions surface first
- workflow automation for construction companies — Insurance, lien, and safety questions get asked long after a job closed, about conditions on a specific date.
- workflow automation across connected systems — A common blind spot, because the record of what moved between systems often lives only in a connector's run history.
Is this a fit for your business?
A good fit when
- Work you do can be challenged later by a customer, insurer, licensing body, or counterparty
- Money, safety, or professional certification depends on decisions the system records
- Work is performed by one person and reviewed or supervised by another
- You have already been asked about the past and struggled to answer
Probably not a fit when
- The process is internal, reversible, and nothing outside the company depends on its history
- The system holds no decisions, only reference information nobody acts on
- You need debugging visibility rather than evidence, which is smaller and cheaper
What to have ready
- Any question you have been asked about what happened on a specific date
- Your retention obligations, from contracts, insurers, or your profession’s rules
- A list of the actions in the process that are irreversible or that carry money
Questions we get asked
Does keeping a full audit history slow the system down?
Writing events adds work, and at the volumes most small and mid-sized businesses run it is not what makes a system feel slow. Reading causes the trouble. If current state is recomputed from full history every time a list loads, that gets expensive. Keep a current-state table for reading and the event store for truth.
Can we add this later?
You can add it going forward, and that is worth doing. What you cannot do is add it backwards. Everything that already happened without an event record stays unprovable, and if the system has been overwriting values in place, the prior values are gone. The cost is the gap you can never close.
Should users be able to delete their own records?
They should be able to remove things from view, which is a different operation from deletion. A soft delete marks the record inactive, records who did it and when, and leaves history intact. Where you must genuinely destroy data, that destruction should itself be an event with a reason attached.
Is a database backup an audit trail?
No, and treating it as one is a common and expensive mistake. A backup restores the whole system to a point in time. It does not tell you who changed a field and why, and reconstructing an answer means restoring each backup and comparing. Backups are for recovery; audit history is for questions.
Related
Tell us what the process looks like now and we will map what a system would need to do. No obligation, and you keep the map either way.
