Evidence on demand, or evidence eventually

I am not a lawyer and none of this is legal advice. Get proper counsel for anything that turns on your specific obligations.

Ask an engineering leader whether they could show what happened to a particular change eight months ago and you will almost never hear no. You will hear “yes, it would take some digging”. That answer is nearly universal, and it is also the entire problem.

Everyone can produce evidence eventually. Given a quarter, two engineers and access to enough systems, almost any organisation can reconstruct almost any change. Reconstruction is a solvable problem.

My position: the only distinction that matters in an evidence programme is latency, and “eventually” is a euphemism for a failure mode with costs nobody counts. Design evidence as a query with a known response time, not as a project you can staff when someone asks.

Every request that matters has a clock

The reason latency is the whole game is that evidence is never requested in the abstract. It is requested by someone with a deadline, and the deadline is usually not yours.

A prospective customer’s security review is blocking a contract that finance has already forecast. An incident is live and someone needs to know what else changed in that window before deciding whether to roll back further. A regulator or an auditor has asked, and the response window is defined by them. An acquirer’s diligence process has a data room closing date.

In every one of those, “it would take some digging” resolves to one of two outcomes. Either you miss the window, which has a direct commercial cost. Or you make the window by pulling three of your most senior people off delivery for two weeks, at the worst possible moment, to reconstruct something that should have been a query.

Evidence eventually

• Response measured in weeks, staffed as a project
• Consumes senior people at the moment they are least available
• Reconstruction relies on memory of people who may have left
• Answer arrives with caveats, which invite follow-up questions
• Cost is invisible because it never appears as a line item

Evidence on demand

• Response measured in minutes, run by whoever is asked
• Consumes nobody's delivery time
• Independent of who is still employed
• Answer is complete or explicitly says what is missing
• Cost is paid up front, once, as design

”We log everything” is not evidence on demand

The most common misconception in this area is that evidence is a data volume problem. It is not. Nearly every organisation already retains more raw material than it needs.

The problem is joinability. You have commits in source control, tickets in a tracker, deploys in a pipeline, approvals in a review tool, alerts in an observability platform and decisions in chat. Six systems, six identifier schemes, six retention policies, and no key that reliably connects them.

Reconstruction is the manual labour of performing that join with a human brain, which is why it takes weeks. The data was all there. Nobody had made it answerable.

So the first design decision is choosing the join key, and the only candidate that works is the change itself. Not the ticket, which may cover six changes or none. Not the deploy, which bundles unrelated work. The unit of change, with everything else attached to it.

What changedThe diff, and the surface it touched. Available everywhere; the easy one.

Against what stated intentThe criteria that were in force when the work started. Almost never captured at the time, and the piece that decays fastest.

On whose authorityThe human principal, not the service account that executed. Distinguishable only if you designed for it.

Verified howWhat checks ran, what they asserted, and what a human actually judged as opposed to clicked.

Approved by whom, knowing whatThe approval plus what was visible to the approver at the time. The last clause is the one everybody omits.

Traceability requirements assume the query works

There is a regulatory backdrop here, and it needs stating carefully rather than dramatically.

EU AI Act enforcement began on 2 August 2026. Article 12 requires automatic logging of events relevant to identifying risk and ensuring traceability, tamper-evident, retained for at least six months and twenty-four for biometric and law-enforcement uses. Whether any of that applies to your systems is a classification question, and classification is legal work.

The point relevant to this argument is structural rather than legal. Traceability is not a storage requirement, it is a retrieval requirement. A record that exists but cannot be assembled into an answer within the time available satisfies the letter of retention while failing at the thing retention is for. No tool makes anyone compliant with anything, ours included, and any vendor telling you otherwise is describing a product that does not exist.

Run the drill, and time it

The intervention I would push hardest is not a purchase. It is a drill, and it costs an afternoon.

Pick a change from eight months ago, at random, that touched something consequential. Give it to two engineers with no special preparation. Ask them for the five rows in that figure. Start a timer.

Do not help them. Do not pick a change you already know the answer to. The number you get is your actual evidence latency, and it is the most honest governance metric available to you, because it is measured rather than asserted.

Three things usually come out of it. The elapsed time is much longer than the leadership team guessed, typically by an order of magnitude. The specific rows that took longest are consistent and diagnosable, and they are almost always stated intent and what a human actually verified. And someone will discover a system whose retention window silently expired, which is worth finding on a Tuesday rather than during a live incident.

Then repeat it quarterly and watch the number. A latency figure that trends down is a governance programme working. A binder of policy documents is not evidence of anything except that someone wrote a binder.

Where this breaks down

Most organisations get asked very rarely, and building for on-demand may be overinvestment. If you have no regulatory exposure, no enterprise customers running security reviews and no acquisition on the horizon, the expected cost of eventually-evidence is genuinely low. Building a retrieval capability for a question nobody will ask is a real waste, and I would rather say that than pretend everyone needs this.

Latency is easy to game once it becomes a metric. Run the drill on convenient changes, in convenient parts of the system, with people who happen to remember, and the number will look excellent while telling you nothing. The defence is random selection by someone who is not accountable for the result, which requires an organisational separation many teams do not have.

A fast, complete answer can still describe a bad process. This is the objection I take most seriously. Being able to produce, in ninety seconds, a perfect record showing that a consequential change was merged with no criteria and no human judgement is not a governance success. It is excellent instrumentation pointed at a hole. Retrieval speed and control quality are independent, and improving the first is sometimes a way of avoiding the second.

Capturing intent at the moment of the change is the expensive part and I have made it sound routine. Rows two and four in that figure require capturing something at a time when nobody feels any need for it, which means either process discipline that decays or tooling in the path of every change. Both cost more than the diagram suggests, and both have failure modes where what gets captured is a formality rather than the real intent.

Quarterly drills decay like every other periodic exercise. The first one is illuminating. The fourth is a calendar item somebody delegates. Keeping it honest needs an owner with enough standing to insist on random selection, and in most organisations that person has other priorities.

The takeaway

Everybody can produce evidence eventually. The distinction that matters is how long it takes, because every request that carries consequences arrives with someone else’s deadline attached, and “eventually” is paid for in senior attention during an emergency.

Evidence is a retrieval problem, not a storage problem. Pick the change as your join key, attach intent and verification to it at the moment it happens, and then measure the only number that tells you whether any of it works.

If you take one thing into next week: pick a consequential change from eight months ago at random, hand it to two engineers with no warning, and time how long it takes them to tell you what changed, against what stated intent, on whose authority, verified how and approved by whom. That number is your evidence programme. Everything else is a description of one.