Proving What Your AI Did: Offline Provenance Without Trusting the Vendor

If you cannot check an AI system's record for yourself, you are not auditing it, you are trusting the people who built it. The way you prove what an AI actually did, without trusting the vendor, is to make the record independent of the vendor. In Mickai the mechanism for this is the Open Audit Record: an append-only, hash-chained log of every consequential action the system takes, with each entry signed using a post-quantum signature and verifiable offline against a checkpoint you hold on separate hardware. If anyone alters an earlier entry after the fact, the chain no longer computes and verification fails. The record does not stop tampering. It makes tampering impossible to hide.

• Vendor dashboards and exported CSVs prove nothing on their own: whoever can generate them can also edit them.
• The Open Audit Record is append-only and hash-chained, so every entry commits to the exact contents of the one before it.
• Each entry is signed with ML-DSA-65 under FIPS 204, a post-quantum digital signature standard.
• You verify the live chain offline, on your own terms, against a signed checkpoint kept off the machine.
• The property you get is tamper-evidence: silent alteration is detectable, which is what an auditor, a regulator, or a court actually needs.

The trust problem: why exported logs prove nothing

Most AI audit stories end at a dashboard. The vendor shows you a timeline of prompts and actions, you export it to a spreadsheet, and everyone agrees that is the record. The difficulty is simple to state and hard to escape: the party presenting the log is the same party that could have changed it. A screenshot, a CSV, even a signed PDF generated on the vendor's servers tells you what the vendor wants to show you at the moment they generated it. It says nothing verifiable about what happened, in what order, or whether an entry was quietly removed after the fact.

This matters most in exactly the settings where AI is now being deployed: financial operations, healthcare, legal review, critical infrastructure, government. In those environments the question is rarely 'what does the log say today'. It is 'can you prove this log has not been edited, and can you prove it to someone who does not trust you'. That is a different and much harder requirement, and it is the one I set out to meet.

What the Open Audit Record is

The Open Audit Record, or OAR, is the audit substrate underneath Mickai. Every consequential action the system takes (a model inference that changes state, a file written, an external action proposed or executed, a policy decision) is written as an entry in an append-only log. Append-only means entries are added and never edited or reordered in place. Each entry carries the action, its inputs and outputs in hashed form, a timestamp, and the identity of the actor.

Two design choices make the log more than a diary. First, the entries are hash-chained, so the log's integrity is a mathematical property rather than a promise. Second, entries are signed with a post-quantum signature scheme, so a valid signature cannot be forged even by an adversary with a future quantum computer. Everything that follows is a consequence of those two decisions.

Hash-chaining: making order load-bearing

In a hash-chained log, each entry includes a cryptographic hash of the entry before it. That hash is a fingerprint: change a single byte of the earlier entry and its fingerprint changes completely, which means the later entry no longer points at anything that exists. To rewrite history you would have to recompute every entry from the point of change all the way to the present, because each one is wound into the next.

This is why the order of events becomes load-bearing evidence rather than metadata. If someone wants to delete the third action of a thousand, they cannot simply pull it out. They would need to reconstruct entries four through one thousand so the chain still computes, and then they would still have to defeat the signatures. Hash-chaining turns a quiet edit into a wholesale forgery, and forgery is far easier to catch.

Post-quantum signatures, and why I chose ML-DSA-65

A hash chain proves internal consistency, but on its own it does not prove who wrote the log. For that each entry is signed. I chose ML-DSA-65, the parameter set of the module-lattice signature scheme standardised as FIPS 204. It is a post-quantum algorithm, which means its security does not rest on problems (like integer factoring) that a large quantum computer would break. Audit records are long-lived by nature: a decision made today may be examined in a decade, and 'harvest now, verify later' is a real concern for anything meant to stand up over time.

The practical effect is that a verifier can confirm each entry was signed by the key that was supposed to sign it, and that neither the entry nor the chain it sits in has changed since. The signature and the hash chain work together: the chain binds the entries to each other, the signatures bind the entries to a keyholder, and both can be checked without any network connection.

Verifying offline against a checkpoint you hold

Here is the part that removes the vendor from the trust equation. At intervals the system emits a signed checkpoint: a compact commitment to the state of the chain up to that point. You take that checkpoint and store it somewhere the running machine cannot reach, ideally on separate hardware in your own custody. Later, at any time you choose, you verify the live chain against the checkpoint you are holding.

The verification is arithmetic, and it runs entirely offline. You recompute the chain forward from the checkpoint and confirm it matches, and you check the signatures with a public key. Because you hold the checkpoint independently, no one on the vendor side can roll the log back to before an event and re-sign a clean version: your held checkpoint would no longer agree with the shortened chain, and the mismatch is the alarm. You are not asking the system whether it has been honest. You are checking, yourself, with mathematics you can run on an air-gapped laptop.

Tamper-evident, not tamper-proof

I am deliberate about this distinction because the industry is loose with it. The Open Audit Record is tamper-evident, not tamper-proof. It does not physically prevent someone with enough access from trying to alter the log. What it guarantees is that any such alteration is detectable: the chain will fail to compute, or a signature will fail to verify, or a held checkpoint will disagree with the live chain. Silent, undetectable change is what it rules out.

That honesty is not a weakness in the claim, it is the strength of it. 'Tamper-proof' and 'unbreakable' are marketing words that a serious auditor is right to distrust. Tamper-evidence is a property you can actually stand behind, because it is the property cryptography can actually deliver. The goal is not to promise that nothing bad can ever happen. It is to guarantee that if it does, you will know.

Why I published the method

A verification scheme that only the vendor understands is just another form of 'trust us'. That is why I have written the approach up as a technical preprint on the Offline Attestation Record, published on Zenodo under my ORCID (0009-0000-5511-5858), alongside related preprints on sovereign inference, private knowledge bases, and turning compliance obligations into evidence. The mechanisms are also the subject of our patent estate: 104 filed UK patent applications covering 2,340 claims, patent-pending at the UK Intellectual Property Office. We patent the mechanism, not the model. A buyer in a regulated sector should be able to read how the guarantee works, not simply be told that it holds.

Frequently asked questions

What is the Open Audit Record?

It is Mickai's audit substrate: an append-only, hash-chained log of every consequential action the system takes. Each entry is signed with a post-quantum signature and can be verified offline, so the record's integrity is a mathematical property rather than a promise from us.

Does tamper-evident mean the log cannot be changed?

No, and I am careful not to claim that. Tamper-evident means any change is detectable, not that change is physically impossible. If someone alters an entry, the hash chain fails to compute or a signature fails to verify, so the alteration cannot pass silently. That is a stronger and more honest guarantee than 'tamper-proof'.

Why use a post-quantum signature for an audit log?

Audit records are long-lived. A decision recorded today might be scrutinised in ten years, and an adversary can store signed data now to attack it later once quantum computers mature. Signing with ML-DSA-65 (FIPS 204) means the signatures should remain sound well beyond the life of the records they protect.

Do I need to trust Mickai to verify the record?

No. That is the design goal. You hold your own signed checkpoint on separate hardware and verify the live chain against it yourself, using public mathematics. If our systems, an insider, or an attacker altered the log, your independent checkpoint would disagree with it and the check would fail.

Can the record be verified without an internet connection?

Yes. Verification is arithmetic: recomputing the hash chain and checking signatures against a public key. It runs entirely offline, including on an air-gapped machine, which is exactly what you want in a sovereign or classified environment.

Where can I read the technical detail?

I have published a technical preprint on the Offline Attestation Record on Zenodo, under my ORCID (0009-0000-5511-5858), alongside related preprints on sovereign inference and private knowledge bases. The underlying mechanisms are also covered by our filed UK patent applications.