Proof Precedes Permission: A Replayable Path Is Not a Permission Boundary

1. The Sentence That Survives Inspection

Most claims an enterprise will make to a regulator in 2027 collapse into one of three sentences:

• “The action was authorised.” — against what?
• “It was refused at the boundary.” — shown by what?
• “It was stopped before harm.” — proven how?

Every one of those is a permission claim. And every one of them is unanswerable unless a different thing already exists: a record of how the decision was actually reached, replayable by someone who was not in the room. Remove that record, and each sentence becomes an assertion only the vendor can vouch for — which is the exact trust model the EU AI Act was written to end.

That ordering is the whole argument, and it has a name:

One clarification before the argument runs, because the word “precedes” can be misread. It means the proof comes first in order — the thing a permission claim is measured against. It does not mean the proof dominates the permission layer or stands above it. This is an analytic and architectural principle for engineers, not a legal rule and not a claim about who controls the action.

2. The Boundary, Drawn Publicly

The distinction did not start as a marketing line. It was drawn by practitioners reading an architecture and finding its edge. The sharpest formulation came from Ricky Jones, an execution-boundary and claim-limit specialist, in a written exchange in late May and early June 2026:

The same edge, put operationally, came from Sue Eze, an AI governance and technology-risk lead. Her version moves the question from architecture to the moment of consequence:

Two people, two vocabularies, one edge. And both are right: the substrate layer — the replayable record — does not cross it. Naming that honestly is not a weakness in the architecture. It is the precondition for the architecture being trusted at all.

3. Stated as a Test

A principle that cannot be falsified is just a slogan. So the boundary is better stated as a test an engineer can apply to any system, including ours:

The clause that does the work is under the rules in force at the time. A record that can only be read under today's policy version quietly fails the test: the adversarial reader arrives eighteen months later, and the decision has to be reconstructable against the framework that governed it then, not the one current when the question is asked. This is the property we call framework-fidelity, and it is what separates a replay from a re-run.

4. Why This Is Not Logging

The fair objection is: isn't a replayable path just a log with extra steps? Three differences decide it.

• Logging records; the substrate makes the record checkable. A log answers “what happened” to a reader who already trusts the system that kept it. The substrate is built so a stranger who does not trust you can confirm the record independently.
• The path is the record, not a layer on top. When an AI decision walks a structured graph instead of rebuilding a flat context pile each time, the route it walked — which nodes, which edges, which constraints were in force — is the audit trail itself. There is no separate “add an audit layer” step; the architecture already produced it.
• Replay is bound to the framework version. A log captures values. A replayable path captures values and the policy and ontology that governed them at decision time, so the reconstruction is faithful to the conditions, not just the outputs.

5. The Honest Limit

The strongest objection deserves the clearest answer: a replayable record of a bad decision is still a bad decision. Replay does not sanitise the call. It does not fix the outcome. That is correct — and it is the point. Replay exposes the decision, constrains it, and makes the permission claim above it checkable. It is, in the discipline Russell Parrott has named publicly, necessary but not sufficient:

So the substrate makes no claim to be the whole stack. It is one precondition that permission claims can be checked against — not the precondition everything else is measured by. The permission layer, the operational-control layer, the director-attestation layer each remain their own work, owned by their own practitioners.

6. Where the Path Ends, the Lanes Begin

The reason “proof precedes permission” holds is that it refuses to claim the layers above it. Each is named, and each is someone else's lane:

• Claim-limit chain — Ricky Jones: claim → evidence object → independent inspection → claim limit.
• Operational control — Sue Eze: authorised, governed, defensible at the point of execution.
• Director attestation — Guy Miller: the named director who must still be able to prove what they did, after they leave.
• Standards / portable proof — Peter Borner: the surface that lets a proof travel across organisations.

The substrate — the replayable path and the record — is the only layer Quantamix Solutions is responsible for. Proof precedes permission; permission belongs to the lanes above. Nobody should be claiming the whole stack, and the architecture is stronger for it.

For the engineering reader, the practical version is one question: the last decision your AI made that mattered — could you reconstruct the path it walked, today, against the rules that were live then? If you cannot, everything you stack on top of it is built on sand.

Continue Reading

• The EU AI Act Audit-Trail Stack (pillar)
• Recall vs Verifiability in EU AI Act Audit Trails
• Director Attestation under EU AI Act Articles 26 & 27
• Forensic Ground Truth in the AI Audit Trail

Frequently Asked Questions