Open Audit Record, tamper-evident post-quantum sealing
The Open Audit Record is the substrate of the Mickai SIOS: every agent action is hash-chained and signed under your operator-controlled ML-DSA-65 key, then made verifiable in any modern browser without trusting Mickai. It answers the question a regulator always asks, namely what the system did, on whose authority, on what inputs and in what sequence, with a cryptographic answer rather than a vendor's assurance. Because the ledger and the keys live on hardware you own, the record cannot be edited after the fact, and a third party can replay any run offline with no Mickai server in the loop.
Conventional cloud AI cannot prove what it did when a regulator asks, because the weights, the run logs and the identity all sit on infrastructure the customer neither owns nor can audit, so the evidence of every automated decision is held by the vendor. Both the EU AI Act and the UK AI Safety Institute agenda demand evidence of what an AI system did, in what conditions, on whose authority and with what effect, and for regulated financial firms SR 11-7 model risk governance adds an obligation to evidence exactly how a model reached a figure. A black-box cloud model cannot meet that bar, and a log the vendor can silently rewrite is worse than none, because it gives false assurance. The Open Audit Record removes the problem by keeping a causally linked, post-quantum signed record of every decision on hardware you own, so each entry references the inputs that produced it, the prior signed decisions that informed it, the brain that produced it and the actor whose signature commissioned it. Because the signatures are made under an operator-controlled ML-DSA-65 key that never leaves your hardware, no vendor cooperation is ever required to verify a decision, and the trail remains valid even after a cryptographically relevant quantum computer arrives.
The 5 controls in this domain, each enforced by construction on hardware you own and mapped to the subsystem that provides it.
Per-Action Post-Quantum Signing
Every action Mickai takes, from a routing decision to a tool invocation to a ledger entry, is signed with the post-quantum ML-DSA-65 algorithm under the FIPS 204 standard, using a key the operator controls. Because the scheme is designed to resist attack by a cryptographically relevant quantum computer, the audit trail remains verifiable long after current public-key cryptography is broken, which future-proofs every signed artefact in the system. The signing key lives on your own hardware and never leaves it, so no vendor can produce or forge a signature on your behalf. This control is anchored in the filed Quantum-Safe Attestation patent.
Hash-Chained Decision Lineage
The Open Audit Record is a causally linked directed graph in which every decision references its inputs and the prior signed decisions that informed it, with every node post-quantum signed. A regulator can take any output and walk the lineage all the way back to the originating prompt and the operator identity, with no ambiguity, because the deterministic arbiter guarantees the same request in the same context routes the same way. This gives the tamper-evident, causally complete trail that SR 11-7 model risk governance and the EU AI Act expect. The lineage design is anchored in the filed Decision Lineage patent.
Browser-Verifiable Offline Replay
A Mickai audit chain can be dragged into an offline verifier that checks hash linkage and FIPS 204 ML-DSA-65 signatures entirely in the browser, so anyone holding the operator public key can confirm a run without trusting Mickai and without a network connection. Once the public key has loaded, the verifier never touches the network, which means a regulator, an auditor or a counterparty can independently satisfy themselves that a decision was genuine. This is what turns an internal log into evidence, because verification does not depend on the party that produced the record. The vendor-neutral verifier and schema are covered in the filed Open Inter-Vendor Audit Record family.
Tamper-Evident Sealing
Because each entry is hash-linked to the one before it and signed under a key held on your own hardware, altering any past record breaks the chain and invalidates every downstream signature, so tampering is immediately detectable. The vendor cannot edit history, and neither can an insider, because there is no privileged path that rewrites a sealed entry without leaving a cryptographic mark. This gives finance, legal and regulated operations a record they can present with confidence that it has not been quietly amended. The seal is the same one any third party checks in the offline verifier.
Regulator And Reasoning Capture
For any automated action that affects a person or a regulated process, Mickai records the reasoning that authorised it alongside the signed entry, so the basis for the decision is reviewable rather than opaque. This meets the EU AI Act traceability and human-oversight duties and the FCA conduct expectations that attach to automated decisioning, because a firm can show not only what happened but why. Human-in-the-loop gates can be set on any action class governance requires, and each gate is itself recorded. The captured reasoning is sealed to the same post-quantum record as the action.
The advantages hold across every control domain, and they are architectural, not promotional. The third-party cloud-exposure vector is removed; your own physical, insider and compliance controls remain yours.
The data never leaves your hardware, so no third party and no cloud-provider employee ever sees it. What happens in the server room stays in the server room.
You own the compute and the capability, so the system runs independent of the internet and of any cloud vendor's pricing, terms, or availability.
The data never crosses a geographical or digital border because it never leaves the building, which removes the cross-border-transfer and third-party-processing friction of UK GDPR, Schrems II, and the sector rules. You keep your own obligations.
Fine-tune and run retrieval on your deepest archives to build a hyper-customised co-pilot, with no risk of your proprietary edge training a public model or leaking.
After the hardware and licence, queries cost essentially electricity. A capital asset you own and depreciate, instead of volatile per-token cloud bills.
There is no third-party cloud path, so no competitor and no vendor insider can scrape, intercept, or subpoena your prompts or your fine-tuned weights from the internet. The trust vault is closed by architecture.
You own the software snapshot on your own hardware, so a change to a cloud vendor's terms, a model deprecation, or an outage cannot reach you. The system stays predictable and auditable on-premise as the rules evolve.
What is the Open Audit Record?
The Open Audit Record, or OAR, is the cryptographic substrate of the Mickai SIOS. It is a causally linked, post-quantum signed graph of every decision the system has made, where each entry references the inputs that produced it, the prior signed decisions that informed it, the brain that produced it and the actor whose signature commissioned it. It lets an operator, or any regulator the operator authorises, walk the lineage from any output back to its originating prompt. Because it lives on hardware you own and is signed under your own key, it is evidence rather than a vendor assurance.
What is ML-DSA-65 and why does Mickai use it?
ML-DSA-65 is the Module-Lattice Digital Signature Algorithm, parameter set 65, the post-quantum signature scheme standardised in FIPS 204 by NIST. It is designed to remain secure against attack by a cryptographically relevant quantum computer, so an audit trail signed with it outlives current public-key cryptography. Mickai signs every decision and ledger entry with ML-DSA-65 under a key the operator holds on their own hardware, so the record stays verifiable for the long retention periods that regulated evidence requires.
Can a regulator verify a Mickai decision without trusting Mickai?
Yes. Given a Mickai output and the operator public verification key, a regulator can independently confirm that the decision was produced by the claimed device, by the claimed brain, on the claimed inputs, at the claimed time and in the claimed sequence with all upstream decisions. The offline verifier checks hash linkage and the FIPS 204 signatures entirely in a browser and does not touch the network once the key has loaded. No vendor cooperation is required, which is what makes the record trustworthy.
How does the audit record satisfy the EU AI Act and SR 11-7?
Both frameworks require a firm to evidence exactly what a model did and how it reached a result. Because every action is hash-chained and post-quantum signed on hardware you own, and because the reasoning that authorised each action is captured alongside it, Mickai gives a complete, tamper-evident trail that maps directly to EU AI Act traceability duties and SR 11-7 model risk governance. The logs and the weights are yours, not a vendor's, so the evidence is under your control.
Can the audit record be edited after the fact?
No. Each entry is hash-linked to the one before it and signed under a key held on your own hardware, so altering any past record breaks the chain and invalidates every downstream signature. Tampering is therefore immediately detectable, and there is no privileged path, for the vendor or an insider, that rewrites a sealed entry without leaving a cryptographic mark. This is what tamper-evident means in practice.
Is the audit record patent-backed?
Yes. The OAR sits on several of the 104 filed UK patent applications behind the Mickai SIOS, including the Quantum-Safe Attestation application covering ML-DSA-65 signing, the Decision Lineage application covering the causally linked signed ledger, and the Open Inter-Vendor Audit Record family covering the vendor-neutral schema and the browser verifier. The portfolio covers approximately 2,340 claims and is owned by Mickai LTD.
Review the open audit record, tamper-evident post-quantum sealing controls with us.
Briefings are for organisations weighing a sovereign, on-premise deployment. Tell us about your estate and threat model and we will walk the controls, the attestation surface and the deployment that fits.