What "provable" actually requires
Provable has four hard requirements, and most things sold as audit trails satisfy one of them. Reconstructed evidence is not evidence, and a log that can be edited without trace is a document rather than a record.
“Provable” has become the word everyone reaches for. Provable provenance, provable review, provable controls. It is used to mean something between “we have logs” and “we would probably be fine”, and it has stopped carrying any information at all.
My position: the word has four hard requirements, they are not negotiable, and almost everything currently described as an audit trail satisfies one or two of them. This matters because the requirements you fail are not discovered when you build the system. They are discovered in a room, months later, by someone with a printout and a question.
Declare the interest first: my employer sells into this problem. So do not take my word for the four requirements. Take the four requirements and test whatever you already have, including anything of ours.
The four
1. Contemporaneous
The artifact was produced by the act itself, at the moment it happened, without a human choosing to record it. Anything assembled afterwards proves that somebody assembled something.
2. Linked
It connects the change to the intent and the authority. A commit hash on its own is a fact about bytes. What was being attempted, and who was entitled to attempt it, is what anyone actually asks.
3. Tamper-evident
Alteration is detectable. Not prevented, which is unachievable, but detectable, so an unaltered record can be distinguished from an altered one.
4. Durable and legible
Still there after the retention period, and still interpretable by someone with no access to the people involved. The second half is the one that fails.
Each of these looks obvious written down, and each has a specific way of failing that is easy to miss while you are building.
Contemporaneous, and why reconstruction is not evidence
The most common failure, and the least understood.
A team is asked to show that a control operated on a change from four months ago. They can. They pull the commit, they find the ticket, they check the approval, they write it up. The write-up is truthful and it is not evidence, because it was produced by people with an interest in the outcome, after they knew what the question was.
That distinction sounds pedantic until you have watched it land badly in an audit. The question is never really “what happened”. It is “how do you know”. A reconstruction answers the first and not the second, and once one reconstruction has been offered, everything else you produce is read the same way.
The practical test is one question: if nobody had ever asked, would this artifact exist? If the answer is no, it is a reconstruction.
Linked, and the identifier problem
Take any change from six months ago and try to get from a line of code to the decision behind it. Almost everyone can do the first hop, to the commit, and stalls somewhere after.
The reason is boring and structural: the systems each hold part of the chain and none of them share an identifier. Version control has commits. The tracker has tickets. CI has runs. The deploy system has releases. Each has its own retention policy, its own identity model, and its own idea of what a unit of work is. Nothing in the middle guarantees the chain is complete, so gaps are invisible until you walk it.
The third box has a trap in it worth naming: acceptance criteria are usually stored mutably. If the criteria a change was approved against can be edited afterwards without a trace, then the intent half of your chain is not a record either.
Tamper-evident, plainly
This is the requirement people either over-engineer or ignore.
The bar is not a distributed ledger. The bar is that if a record is altered, that is detectable by someone who did not write it. Ordinary cryptographic chaining over an append-only store meets it. Write access held by the same team that operates the systems being recorded does not, regardless of how honest that team is, because the point of the requirement is to make honesty checkable rather than assumed.
The EU AI Act’s Article 12 is unusually direct on this, requiring automatic logging of events relevant to risk and traceability, tamper-evident, retained for six months, and twenty-four for biometric and law-enforcement uses. Enforcement began on 2 August 2026. Read as a definition, that is requirements one, three, and half of four in a single sentence, written by a regulator rather than a vendor.
I will say the necessary thing clearly: no tool makes an organisation compliant with the AI Act or with anything else. Tools produce evidence, or fail to. Compliance is a judgement people make about your whole operation, using that evidence.
Durable and legible
Retention is the easy half and the half everyone plans for.
Legibility is where records die. An artifact whose meaning depended on conventions everyone shared at the time, a ticket prefix, an internal name for a service, an approver identity that was a shared account, is gone even though the bytes survive. The person reading it in eighteen months has none of that.
The test is unsentimental: hand a record from a year ago to somebody who joined last month and ask them what it says. What they cannot recover, you no longer hold.
There is one gap worth flagging because it is structural rather than local. Native provenance attribution exists for generated images: there are mechanisms for marking generated content as generated. There is no documented equivalent for generated code. Whatever chain you build, you are building it yourself, and no format is going to arrive and make your records portable in the near term.
Where this breaks down
Four requirements is a demanding bar, and most organisations do not need it everywhere. Applied to an internal tool with no regulatory exposure this is expensive ceremony. The honest version is that a small number of change classes need all four, and deciding which is a risk judgement I cannot make for you.
Contemporaneous records can be contemporaneously wrong. An automatic artifact captured at the moment of the act records what the system observed, which is not always what happened. A rubber-stamp approval produces an impeccable, timely, tamper-evident record of a review that did not occur. Every one of my four requirements is about the integrity of the record, and none of them is about the truth of what it records.
Tamper-evidence protects against a threat model most teams do not have. The realistic risk is not that someone edits a log. It is that nothing was recorded. Spending on the third requirement before the first is a common and expensive ordering mistake.
Article 12 is young. Enforcement began weeks ago, and how supervisory authorities will actually read “tamper-evident” and “relevant to risk” is unsettled. I am treating a new definition as a stable one because it is the most concrete available, not because anyone has tested it.
And volume may defeat all of this. A complete chain for every change produces an enormous quantity of records that nobody will ever query. There is a real argument that a smaller, curated set of well-understood records is worth more than a complete set nobody can navigate, and I have not made the case that completeness beats usability.
The takeaway
“Provable” is a claim with four parts: produced by the act, linked to intent and authority, alterable only detectably, and still readable by a stranger after the people have gone. A system that fails any one of them does not partly prove things.
Test what you have rather than what a vendor says. The exercise takes an afternoon and it is the same exercise an auditor will run, only friendlier.
If you take one thing into next week: pick one change from six months ago and try to walk from a changed line to the person who authorised the intent, using only artifacts that already existed before you asked. Wherever you have to ask a human is where your chain ends.