Building a Verifier That Trusts Nothing

The verifier should be the most paranoid thing in the room

Picture a regulator, two years from now, holding a memory stick. On it is a record of every decision an artificial intelligence (AI) system made on behalf of a bank: who was denied credit, which transactions were flagged, what the model was told and what it did next. The regulator wants to know one thing. Is this record real, or did the vendor write it after the fact to look clean? Today, the honest answer in almost every deployment is that you cannot tell. The log lives in the vendor's cloud. The vendor controls the database. The vendor signs nothing, or signs with a key the vendor also holds. You are not auditing the system. You are trusting a press release.

I have spent the last few years building the opposite of that. Mickai is a Sovereign Intelligence Operating System (SIOS), built and running in production, and at its centre sits the Open Audit Record (OAR), a signed, hash-chained, append-only ledger of everything the AI does. The design goal that organised the whole thing was deceptively simple. A verifier should be able to confirm the record is genuine while trusting nothing. Not the vendor, not the server, not the network, not even the machine the verifier runs on beyond the browser in front of it. This essay is about what that constraint actually demands, because the constraint is brutal, and most of the industry quietly relaxes it. The architecture is not a slide. It is filed work: the audit and signing mechanisms sit inside a portfolio of 101 filed United Kingdom patent applications, around 2,234 claims, owned by Mickai LTD with me as the named inventor.

What 'trust nothing' actually rules out

The phrase sounds like marketing until you start subtracting. Trust nothing means the verifier cannot call home. If verification requires a network request to a Mickai server to check whether a record is valid, then Mickai is in the trust path, and we have failed. A vendor that can answer 'yes, that is valid' can also answer 'yes' to a forgery. So the first casualty is the online check. Verification has to run with the network cable pulled out.

Trust nothing also rules out the heavy client. If you need to install a special application, a runtime, a signed binary from us, then you are trusting our build pipeline and our update channel. A compromised update could ship a verifier that always says 'valid'. So the verifier has to be something the auditor already has and did not get from us. In practice that means an ordinary web browser, opening a plain HyperText Markup Language (HTML) file, running standard JavaScript against the Web Cryptography Application Programming Interface (Web Crypto API) that ships inside the browser itself. No plugin, no download from Mickai, no account.

And trust nothing rules out the convenient shortcut of vendor-held keys. If we sign the record with a private key we keep, then 'verified' only means 'Mickai vouches for this', which is precisely the assurance the auditor came to escape. The signatures have to chain to a root the auditor can pin independently, and the keys that produced them have to be the kind you can rotate and revoke in the open. Once you take all three subtractions seriously, no online check, no vendor client, no vendor-vouched key, you have boxed yourself into a corner. The interesting work is what you build inside that corner.

The chain has to carry its own proof

If the verifier cannot ask anyone whether a record is valid, the record must answer the question itself. That is the core architectural move. Every entry in the Open Audit Record is hashed, and every entry includes the hash of the entry before it. This is the well-understood hash chain that underpins version control and distributed ledgers alike, and its property is the one we need. Change any entry, even a single byte in a timestamp, and its hash changes. Because the next entry committed to the old hash, the next entry no longer matches. The break propagates forward to the end of the chain. There is no quiet edit. You either present the whole consistent chain or you present a chain that visibly snaps.

So the verifier's first job needs nothing but arithmetic it can do offline. Walk the chain from the first entry. Recompute each hash. Confirm that each entry's recorded 'previous hash' equals the hash you just computed for the previous entry. If every link holds, the sequence is internally consistent and nothing was inserted, deleted, or reordered after the fact. This is the part that genuinely trusts nothing, because hashing is deterministic. The same bytes give the same hash on the auditor's laptop, on my workstation, on a machine that has never heard of Mickai. The browser is not asking us anything. It is checking mathematics.

Consistency is necessary but not sufficient. A consistent chain could still be a chain I fabricated wholesale this morning. Anyone can hash a sequence of lies into a tidy chain. That is what signatures are for, and that is where the design gets harder. The chain proves nothing was changed after it was written. It says nothing yet about who wrote it, or whether they were allowed to. For that, the bytes have to be signed, and signed in a way the auditor can check without phoning anyone.

Signing before the action, not after

Most logging happens after the fact. The system does a thing, then writes a line about the thing it did. That ordering is the original sin of audit logs, because it leaves a window. If the action and the record are separate steps, a system under pressure, or under attack, can take the action and then decline to write the truthful record. The log becomes a story the system tells about itself, edited for the audience.

In the Open Audit Record the order is reversed. The intended action is signed before it executes. The model proposes to deny the loan, move the funds, send the message, and that proposal, with its inputs and its reasoning trace, is committed and signed first. Only a committed, signed intent is allowed to run. This is a small reordering with a large consequence. There is no action without a prior record, so there is no clean way to do the deed and suppress the evidence. The evidence is a precondition of the deed. When an auditor later asks 'did the system do anything it did not record', the architecture's answer is that it structurally cannot, because the record gates the act rather than trailing it. This matters more, not less, as the work is split across many specialised models. Mickai runs 50 brains, 25 domain and 25 operational, on the Poseidon silicon substrate, and every one of them writes into the same signed record under the same rule. There is no privileged brain that gets to act first and account for it later.

The signature itself uses a post-quantum scheme, the United States National Institute of Standards and Technology standard for module-lattice digital signatures (US NIST FIPS 204, ML-DSA-65). I will be plain about why. A signature is a promise that survives into the future, and the future contains larger quantum computers than today's. A classical signature scheme that is fine in 2026 may be forgeable in 2036, at which point every historical record signed with it becomes deniable in retrospect. An audit trail whose signatures expire is not an audit trail. Choosing a lattice-based scheme standardised for exactly this threat is not us chasing a buzzword. It is the only honest choice for records that are supposed to mean something for decades.

Verifying a signature with nothing but the browser

Here is where the no-vendor-client rule bites and where I want to be honest about the engineering. To check a signature offline, the verifier needs the public key, the signed bytes, the signature, and an implementation of the verification algorithm. The first three travel inside the record bundle. The fourth is the problem, because post-quantum verification is not yet a native primitive in every browser's crypto interface the way older curve signatures are.

We solve it the only way that respects the constraint. The verification logic ships as auditable code inside the same self-contained HTML file the auditor opens, not as a binary fetched from us at run time. An auditor, or their security team, can read it. They can compare it against the published reference. They can run the verifier against a record they know is good and a record they have deliberately tampered with, and watch it accept the first and reject the second. The trust does not rest on 'Mickai says this code is correct'. It rests on 'this code is short enough and open enough that a competent reviewer can confirm it is correct, and then run it on a disconnected machine'. That is a meaningfully different kind of assurance. It is the difference between a sealed box with a label and a glass box you can take apart.

The signed bytes matter as much as the algorithm. A subtle failure mode in audit systems is signing a summary rather than the substance, so that the signature is genuine but covers a sanitised version of events. In the Open Audit Record what gets signed is the canonical serialisation of the full entry: inputs, action, model identity, and the previous hash that binds it into the chain. Canonical means there is exactly one byte sequence that represents a given entry, with fields ordered and encoded the same way every time, so the verifier reconstructs the same bytes the signer signed without guessing. No canonical form, no offline verification, because the verifier would have no way to know which arrangement of the data to hash. Getting that serialisation boring and deterministic is unglamorous work, and it is where offline verifiers usually quietly break.

Where the root of trust lives

A signature is only as meaningful as your confidence in the public key that checks it. If the auditor accepts whatever public key arrives inside the bundle, then a forger simply ships a fake record signed with a fake key and includes the matching fake public key. Everything verifies, and everything is a lie. This is the deepest version of the trust problem, and being offline makes it sharper, because the verifier cannot phone a certificate authority to ask whether a key is legitimate.

The answer is to anchor the root somewhere the vendor cannot quietly rewrite, and to let the auditor pin that anchor independently. In Mickai the audit root is anchored to a sovereign Layer 1 chain we are building, called Pantheon, which in turn anchors to Bitcoin. I will be careful here, because the chain is the one part of the stack still in build rather than live. The principle is what matters for the architecture. The root commitment is published to a ledger that no single party, including us, can rewrite, so an auditor who knows the published root can check that a record bundle descends from it. Pantheon's own economics are deliberately fixed and boring for the same reason the serialisation is: its token, PAN, has a fixed supply of five billion, because a settlement layer for audit anchors should not have surprises in its monetary base. The auditor does not take our word for the root. They take the public ledger's word, and they can fetch that root from any independent source they like, then carry it to the disconnected machine where verification happens.

This is also the honest boundary I insist on drawing. Anchoring proves a record existed in a certain state at a certain time and has not been altered since. It does not prove the AI was wise, or fair, or correct. A signed record of a bad decision is still a record of a bad decision. What the architecture buys you is that the decision cannot be denied, backdated, or quietly rewritten. That is a narrower claim than 'trustworthy AI', and I would rather make the narrow claim and have it be true.

Threats the model actually has to survive

It is worth walking the attacks, because a verifier that trusts nothing is only worth building if it defeats the realistic ones. Consider the insider who controls the server. They can delete the database, but they cannot produce a consistent chain that omits an entry, because the hashes no longer link. They can refuse to hand over records, but absence is conspicuous in a chain that numbers and links its entries. What they cannot do is the dangerous thing, silently change what happened while preserving an innocent-looking log.

Consider the forger who ships an entirely fake bundle with a self-consistent chain and a matching public key. The internal checks pass. The anchoring check is what stops them, because their fabricated root does not match the root published to the independent ledger. Consider a future adversary with a stronger quantum computer attacking old signatures. That is the threat the post-quantum scheme is chosen to blunt, which is why we did not pick a comfortable classical curve that ages badly. And consider the most mundane attack of all, a compromised verifier that lies. That is why the verifier is small, readable, vendor-independent code an auditor can inspect and run on an air-gapped machine, rather than a service we operate. Each subtraction we made at the start, no online check, no vendor client, no vendor-held key, maps directly to one of these threats. The constraints were not aesthetic. They were the threat model wearing different clothes.

Why the regulation makes this concrete, not theoretical

None of this is academic for much longer. The European Union (EU) Artificial Intelligence Act brings its high-risk obligations into force from August 2026, and the recurring demand across those obligations is record-keeping, traceability, and the ability to demonstrate after the fact what a system did and why. Liability for AI decisions is rising in parallel, and the migration to post-quantum cryptography has moved from a research footnote to a planning line item for serious institutions. The trend is unambiguous even where I will not invent a precise number to dress it up. Organisations will increasingly be asked not just to claim their AI behaved, but to prove it to someone who does not trust them.

When that day comes, a log in a vendor's cloud is not proof. It is an assertion with good production values. The thing that holds up in front of an adversarial reviewer is a record they can verify themselves, on their own hardware, with the network disconnected, against a root they pinned from a source we do not control. There is a deeper sovereignty point underneath this. We are actively training our own models now, fine-tuning and specialising open foundations such as Llama 3.2 and Qwen 2.5 and building a sealed corpus, with funding scaling us toward fully native weights. The reason that matters for audit is simple: a record you can verify offline is only as trustworthy as your independence from the people who made the model. If the model, the substrate, and the audit root all answer to one party that you must also trust, you have not escaped anything. The point of owning the stack is so the proof can stand without us. That is a high bar, and we set it for ourselves on purpose, because a bar you can clear by being trusted is no bar at all.

The record that does not need you to believe it

Building a verifier that trusts nothing forces a particular kind of discipline. You cannot paper over a weak link with a friendly server. You cannot launder a vendor's reputation into a security guarantee. Every shortcut that would have made the engineering easier is also the shortcut that would let us, or an attacker who became us, write a comfortable fiction. So we closed those doors deliberately. Sign before you act. Chain every entry to the last. Use signatures built to outlive the machines that might break them. Anchor the root where no one can rewrite it. Ship the verifier as glass, not as a sealed box, so the auditor reads it rather than believes it.

The result is a small, almost anticlimactic artefact. An ordinary browser, an HTML file, a disconnected laptop, and a few seconds of arithmetic, and the answer comes back genuine or it comes back broken, with no opinion of ours in between. The whole point of the signed, offline-verifiable record is that it does not ask for your faith. It hands you the means to check, and then it gets out of the way. In a field crowded with assurances, that is the rarest thing we know how to make, a claim that survives a sceptic who refuses to trust the one making it.