Checkable by a Stranger: The Offline Proof Verifier for AI Decisions

1. The Test Most Audit Trails Quietly Fail

Almost every audit trail in production today was built to be read by someone who already trusts the system that produced it. That assumption is exactly the one that breaks under independent examination. The 2027 version of an audit is not cooperative; it is adversarial. The examiner does not trust the operator and has no obligation to take the vendor's word for anything.

The cleanest statement of why that matters came from Peter Borner, Chairman of the Open Proof Standards Foundation, on LinkedIn in May 2026:

The phrase that does the work is independently of either party. A proof you can only check by trusting the operator, or by running the vendor's software, is not really a proof to an outsider. It is a reassurance. The difference between the two is the whole subject of this piece.

2. What “Verifiable Offline” Actually Means

A verifier earns the word offline only if it needs none of the following: a network connection, an account with the vendor, or any of the vendor's proprietary code. What it is allowed to need is small and public: the proof bundle itself, and the public keys.

The mechanism is standard cryptographic tamper-evidence, built from well-known primitives rather than anything secret:

• Records are canonicalised to a deterministic byte form (RFC 8785, JSON Canonicalization Scheme), so the same record always hashes the same way.
• Records are committed in batches under a Merkle tree (RFC 6962), so the root transitively authenticates every leaf in the batch.
• The root is signed with an ed25519 key whose public half travels with the proof, and optionally anchored to a public append-only transparency log (Sigstore Rekor).

To verify, the program recomputes the leaf hash, checks Merkle inclusion, checks the signature against the trusted public key, and optionally checks the Rekor binding. If any step fails, it returns a typed failure — malformed bundle, tampered leaf, wrong root, unknown or untrusted key, Rekor mismatch — rather than crashing or guessing.

3. Shipped, Not Promised

The reason this piece is written in the present tense is that the verifier is published. As of 31 May 2026 the GraQle SDK includes a standalone offline proof-bundle verifier, available two ways:

Both surfaces return the same result — exit code 0 for verified, 1 for not verified, 2 for usage error — and the same machine-readable JSON, so they drop into a pipeline or an examiner's laptop equally. The verifier is open source under Apache 2.0, and a build-time isolation gate enforces that it imports nothing from the vendor's server or studio code: the “no proprietary code” property is checked mechanically, not just asserted.

This is the engineering form of a position stated earlier in the campaign — that the goal is to be tamper-evident to a third party who has never heard of us, with no install and no account. That sentence used to describe the roadmap. It now describes a command.

4. Where It Sits Relative to Article 12

Article 12 of Regulation (EU) 2024/1689 obliges providers of high-risk AI systems to enable automatic record-keeping sufficient for traceability and to support post-market monitoring under Article 72. On the text, it does not require that those records be cryptographically tamper-evident, or that they be verifiable by an independent party.

So the offline verifier is not a box the Act tells you to tick. It sits above the legal floor: it addresses the gap between what the page requires and what an adversarial 2027 inspection will actually reward. An architecture that can hand a regulator a proof they can check without trusting the operator is aligned with where the Act is going. It does not make the system compliant, and it is not a certification — those words belong to processes the Act defines, not to a verifier.

5. The Honest Limit

A verifier that returns “verified” is making a narrow claim, and it is important to state exactly how narrow. It proves that the recorded decision and its reasoning path are intact and were committed when claimed — that nobody altered the record after the fact. It does not prove that the decision was correct, and it does not prove that the resulting action was authorised, refused, or stopped before consequence.

Verifying the record is the precondition that makes any permission claim above it checkable — but the verifier is an evidence surface, not an execution-control layer. The permission decision belongs to a separate lane with its own owners. The verifier's job is to make sure that, whatever was decided, a stranger can reconstruct and confirm the record of it. That is covered in detail in the companion piece on proof precedes permission.

Continue Reading

• The EU AI Act Audit-Trail Stack (pillar)
• Recall vs Verifiability in EU AI Act Audit Trails
• Proof Precedes Permission: The Substrate Seam
• TAMR+: Graph-Based AI Reasoning

Frequently Asked Questions