Mickai is not a wrapper around a frontier LLM. It is a Sovereign Intelligence Operating System composed of twenty-five specialist brains across six subsystems, with a deterministic arbiter routing every request and a post-quantum signed audit ledger underneath. This piece walks through the architecture in technical detail. How the brains compose, how decisions are routed, how the audit chain is signed at commit, how the verifier runs in any browser tab with no network calls, and why every component is designed to operate inside an air-gapped enclosure with no tunnel to the public internet.
Why on-device matters for the four sectors that cannot ship data to the cloud
Defence, government, finance, and healthcare share a structural posture that the consumer AI market does not address. Each sector has a regulatory floor below which data cannot leave the operator's perimeter. UK MoD JSP 440 and JSP 604 set classification handling rules that make a public-cloud frontier-model API an immediate non-starter for anything above OFFICIAL-SENSITIVE. NHS Digital's Data Security and Protection Toolkit (DSPT) and the wider NHS Cloud Risk Framework are explicit about extra-territorial data flow. PRA SS1/23 and the FCA AI strategy paper of 2024 both treat third-party AI dependency as concentration risk that has to be priced into operational resilience. ICO guidance on UK GDPR Article 25 (data protection by design) treats vendor-key custody as a structural deficiency that needs compensating controls. Every one of those frameworks reaches the same engineering conclusion. If the model and the model's audit trail leave the operator's hardware, the operator no longer holds the cryptographic position to defend the decision the model produced. Mickai is the engineering response to that conclusion. The whole stack runs on the operator's own iron. Nothing leaves.
This piece is for the technical decision-maker. The CTO, the Chief Architect, the CISO, the head of AI assurance. It walks through the architecture as it is implemented today, not as a roadmap. The six subsystems, the twenty-five specialist brains, the orchestration model, the audit ledger, the verifier, and the air-gap discipline. By the end you should be able to evaluate whether the architecture stands up to the procurement scrutiny your sector applies to anything that handles regulated data.
The architecture in one diagram
The Mickai SIOS architecture. Six subsystems, twenty-five brains, one cryptographic audit chain. All on-device.
Mickai is composed of six subsystems. Each subsystem groups one or more specialist brains. There are twenty-five brains in total. A deterministic Arbiter Brain at the head of the cooperative routes every inbound request. A Governance Layer at the foot of the cooperative records every action under a hash-linked, post-quantum signed chain. The seven subsystems in the homepage card grid are Multi-Brain Orchestration, Agent Tooling, Knowledge and Memory, Artifacts, Vinis Voice, and the Governance Layer. The audit ledger is itself a brain (the Audit Ledger Brain) inside the Governance Layer. The verifier is the offline counterpart to the audit ledger and runs in any browser tab.
The cooperative architecture is the subject of patent application 02 at the UK Intellectual Property Office. The deterministic routing contract that makes audit replay possible is in patent 16. The trust-domain externalisation pattern that lets the operator hold the audit keys without trusting the AI vendor is in patent 17. Together they are the structural basis of the on-device claim. The model artefacts can change. The brains can be retrained. The frontier model substitutes can be swapped. The audit chain remains valid because the chain is signed by the operator, not by any vendor.
Subsystem one. Multi-Brain Orchestration
Four brains. Arbiter, Router, Reasoning, Planning. The Arbiter Brain is the deterministic conductor. It receives every inbound request after a Trust Agent layer has classified the user, the tenant, and the action class, then dispatches the request to the correct specialist or to a quorum of specialists. Determinism is the central property. The same request, in the same context, with the same policy, always routes the same way. That property is what makes audit replay meaningful. A regulator inspecting a decision two years later can replay the routing graph against the recorded inputs and assert that the system would arrive at the same dispatch under the same conditions.
The Router Brain decomposes complex intents into a directed acyclic graph of typed sub-tasks across other brains. Where the Arbiter is the conductor of a single bar, the Router is the composer of a multi-movement work. The DAG is signed before execution begins. Deviations from the plan are recorded against the original plan in the audit ledger. This is how the system handles work that cannot be answered by a single brain. The Reasoning Brain handles open-ended cognitive load. Hypothesis generation, multi-step deduction, scenario evaluation, structured deliberation. It is the brain that thinks. The Planning Brain produces ordered execution plans for multi-step actions and arbitrates between alternative plans when the Reasoning Brain produces more than one viable path.
Subsystem two. Agent Tooling
Four brains. Tool Use, Code, Browser, Function. Tool Use Brain selects and invokes external tools and APIs that the agent has been authorised to use. Code Brain writes, edits, and executes code in sandboxed environments. Browser Brain drives a browser session for retrieval, scraping, and form interaction, with all I/O recorded under the audit chain. Function Brain calls typed functions exposed by host applications under capability-scoped tokens. The boundary is the capability token. Any tool the agent invokes is gated by a capability that lists exactly what the agent is allowed to do with that tool, on what data, and for how long. The capability is signed by the Permissions Brain (subsystem six) and presented to the tool at every call. Tools that do not honour capabilities are not allowed in the system.
Subsystem three. Knowledge and Memory
Four brains. Retrieval, Embeddings, Long-Term Memory, Context. Retrieval Brain answers structured retrieval queries against the operator's local corpus and any explicitly-authorised remote corpora. Embeddings Brain produces and indexes vector embeddings on local hardware so that no document leaves the perimeter to be embedded by a hosted service. Long-Term Memory Brain holds the operator's persistent context across sessions, with retention windows scoped per data class and recorded against the policy engine. Context Brain maintains the working set of context inside a single multi-turn conversation, decides what to retain, what to summarise, and what to evict. Together these four brains are the operator's memory. They run on the operator's hardware. The memory is the operator's, not the vendor's.
Subsystem four. Artifacts
Four brains. Document, Image, Video, Data. Document Brain reads, writes, and reasons about long-form documents (PDF, DOCX, ODT) including legally-significant ones such as contracts and clinical reports. Image Brain handles visual reasoning, OCR, and on-device image generation under conformance constraints. Video Brain handles long-running video understanding, segmentation, and the audit trail that an inspector will need if a clip is later challenged. Data Brain reasons about structured tables and time-series data, with first-class hooks for the operator's data warehouse and SIEM. Each artefact processed by these brains is hashed at ingest, and the hash is recorded in the audit ledger before any reasoning starts. That ingest hash is the bedrock of any later forensic claim about what the system saw.
Subsystem five. Vinis Voice
Three brains. ASR (automatic speech recognition), TTS (text to speech), Voice Biometric. ASR Brain transcribes the operator's speech using on-device acoustic models with low latency and no cloud dependency. TTS Brain synthesises the response in the operator's voice or in a neutral system voice, depending on policy. Voice Biometric Brain authenticates the speaker against an enrolled voice template held in TPM-bound storage. This is the system's defence against voice-clone impersonation. A captured impersonation may sound right to a human ear and to a generic ASR model, but it does not pass the speaker-verification check that Vinis runs against the local enrolment. The Voice Biometric brain is part of the routing path. A request that does not match the enrolled speaker is downgraded or refused per policy.
Subsystem six. Governance Layer
Six brains. Policy, Audit Ledger, Identity, Quorum, Permissions, Revocation. Policy Brain holds the policy graph. The deterministic rules about who can do what to which data class under which conditions. The graph is signed by the operator at deployment and any change is itself recorded in the audit ledger. Identity Brain authenticates the human and machine actors against TPM-bound identity material. Quorum Brain implements the m-of-n approval pattern for high-stakes actions where one signed actor is not enough (clinical prescriptions, financial settlements, weapons-handling actions). Permissions Brain emits the capability tokens that gate every external tool call. Revocation Brain processes revocations in real time so that a withdrawn capability cannot be used by an in-flight request.
Audit Ledger Brain is the heart of the governance layer. Every committed action across all twenty-five brains is serialised in CBOR, hashed under SHA-3-512, signed under FIPS 204 ML-DSA-65, and appended to a hash-linked chain. The chain is local to the operator. It can be exported as a compact tar archive for off-site replication or for handing to a regulator. The verifier (described below) walks the chain and emits one of four deterministic verdicts per record. VERIFIED. INVALID. STALE. REVOKED. There is no fifth verdict. There is no probabilistic answer. The chain either holds or it does not, and the verifier explains exactly which record broke the chain and why.
How a request flows through the system
A user speaks to Mickai. The request enters via the operator console (which is not itself a brain, but a thin shell) and is captured by Voice Biometric Brain for speaker verification. ASR Brain transcribes. The transcript is normalised and handed to the Arbiter. Arbiter inspects the active tenant, the speaker's clearance, the policy graph (Policy Brain), and the request type. The Arbiter dispatches to the appropriate single brain or, for complex multi-step intents, to the Router Brain. Router decomposes into a DAG of typed sub-tasks. Each sub-task is signed and the DAG is committed to the audit ledger as an intent record. Specialist brains execute their sub-tasks under capability tokens minted by Permissions Brain. Tool calls emerge through the Agent Tooling subsystem under those capability tokens. Artifacts pass through the Artifacts subsystem and are hashed at ingest. The Reasoning Brain assembles the final answer. TTS Brain synthesises the spoken response. The Audit Ledger Brain commits a final-state record that hash-links back to the intent record. The whole flow leaves the operator with one signed chain that ties the spoken answer back to the spoken request, with every intermediate decision visible.
Replay is the second half of this story. Any record on the chain can be selected, and the recorded inputs (or their hashes if the data class forbids replay of the data itself) can be fed back into the deterministic routing function. The same routing graph emerges. The same capability tokens are minted. The same tool calls are issued (or simulated against a deterministic stub). The same audit records are emitted. A divergence between the recorded chain and the replay output is itself a forensically meaningful signal. It points either at non-determinism in a brain (which Mickai treats as a defect to be fixed) or at tampering with the original chain (which the verifier will already have flagged).
The cryptographic audit ledger in detail
The ledger is the substrate. Every record on the chain has the same structure. A CBOR-canonical body containing the action descriptor, the inputs (or their hashes), the brain identity, the capability token, the timestamp, and the prior-record hash. A signature over the body using FIPS 204 ML-DSA-65, the post-quantum signature algorithm standardised by NIST in 2024. The signing key is held in TPM 2.0 on the operator's workstation, never exported. Key rotation is itself a record on the chain. The chain is append-only by design. There is no edit operation. There is no delete operation. There is no admin who can patch the chain after the fact, including the operator. The only way to retract a published action is to append a revocation record signed under the same key, which the verifier surfaces as REVOKED on subsequent walks of the chain.
The verifier is the second component of the substrate. It is a WebAssembly module compiled to run in any modern browser tab. It loads the published chain (typically a tar archive, but the format is open) and walks it record by record. For each record it checks the prior-record hash, validates the ML-DSA-65 signature against the operator's published verifier key, and compares the action descriptor against the chain's policy snapshot. The verifier has a no-network invariant. It does not phone home to any service. It does not contact the operator. It does not log to any third party. The verdict it emits is purely a function of the chain itself plus the verifier key. A regulator inspecting a chain on a sandboxed laptop, weeks after the operator has gone offline, gets the same verdict that the operator would get on their own console.
Air-gapped operation
The on-device claim is a no-tunnel claim. Mickai's deployment posture has three concentric perimeters. Innermost is the workstation with TPM 2.0 anchoring identity, capability, and audit signing keys. The next perimeter is the local network the workstation sits on (operator's own LAN, no internet route). The outermost perimeter, in a fully air-gapped deployment, is a Faraday-equivalent enclosure with no wireless and no wired link to the outside. The architecture supports all three deployment modes from the same codebase. A defence operator can run Mickai in a SCIF with no link out. A finance operator can run it on a dedicated VLAN with audited egress. A healthcare operator can run it on the trust's existing infrastructure under DSPT alignment. The cryptographic discipline does not change between the three. The audit chain is identical. The verifier is identical. The brain code is identical.
There is one place the system can interact with the outside world, and that place is explicit. A controlled export gate, operated under the Quorum Brain, allows the operator to publish an artefact (typically a signed audit chain export, or a permissioned model fine-tune diff) outside the perimeter. Every such export is itself a record on the chain. There is no implicit telemetry. There is no implicit phone-home. There is no implicit model-call to a hosted frontier endpoint. If the operator wants to invoke a hosted model, the system will allow it under explicit policy and capability, with the call recorded as a record on the audit chain that another operator can later replay or challenge.
What this enables in defence, government, finance, and healthcare
Defence. A unit operating under JSP 440 can use Mickai for intelligence summarisation, OSINT triage, and after-action review without sending any data to a frontier model API. The audit chain is the unit's evidence pack for the decisions the system informed. A separate unit can validate that pack offline, in a different SCIF, against the same verifier binary. The post-quantum signature discipline means the chain still verifies in the post-quantum era that the unit will operate in by 2028 onwards.
Government. A regulator (NCSC, DSIT, ICO) can deploy a sovereign-AI assurance pilot on Mickai on a single workstation with no procurement bridge to a hyperscaler. The audit chain is the regulator's evidence to itself that the pilot has been operated according to the published policy. A second regulator can be invited to walk the chain offline. The regulator's keys never leave the regulator.
Finance. A bank operating under PRA SS1/23 can use Mickai for model-risk diligence on third-party AI vendors, with the on-device deployment closing the concentration-risk gap that hosted-only AI evaluation creates. The audit chain is the bank's evidence to itself, to its auditor, and to the supervisor that the diligence was performed according to the bank's own policy graph rather than the vendor's.
Healthcare. An NHS Trust or an integrated care board can run Mickai on a clinical-grade workstation under DSPT, with the policy graph encoding the trust's own data-handling rules. Patient data does not leave the trust. The audit chain is the clinical safety officer's evidence to themselves and to the CQC that an AI agent did, or did not, do something to a patient record. The Voice Biometric brain protects against impersonation in spoken clinical workflows.
Why the architecture is the differentiator
A cloud chatbot is a single model, hosted by a single vendor, audited under that vendor's logging discipline, exposed to that vendor's prompt history retention. The data leaves. The audit is the vendor's. The trust assumption is the vendor's. The price is monthly per seat, until the vendor changes the price, the model, or the retention policy. Switching vendor is a migration project. Switching audit format is impossible without losing the historical chain.
A Sovereign Intelligence Operating System is twenty-five specialist brains, six subsystems, one deterministic arbiter, one cryptographic audit ledger, and one verifier. The data does not leave. The audit is the operator's. The trust assumption is the operator's. The audit chain is portable, in OAR canonical format, to any other operator. The verifier runs offline. The architecture is the differentiator and the architecture is what makes the regulated-industry use cases viable.
How to evaluate this for procurement
Three questions for the technical decision-maker. First, what cryptographic position does the proposed AI system give your operator if the vendor disappears tomorrow. If the answer is none, you have a vendor-lock problem on the audit layer regardless of the model layer. Second, what verifier can a regulator use to walk the audit chain on their own laptop, with no network. If the answer is "use our hosted dashboard", the audit is not portable. Third, what is the operator's recourse if the audit chain has to verify in 2035 against a quantum-capable adversary who was not in the threat model when the chain was signed in 2026. If the answer is "we will rotate the algorithm later", the chain you are recording today does not survive the threat horizon you are buying for.
Mickai answers all three. The operator's keys are held in TPM. The verifier is browser-resident WebAssembly with a no-network invariant. The signature algorithm is FIPS 204 ML-DSA-65, post-quantum from inception. The architecture is the answer. The architecture is the product.
Originally published at mickai.co.uk.
Sandboxed instance for technical evaluation: press@mickai.co.uk.
