Sovereign control, layer by layer.
This page is the technical map of the Sovereign Intelligence Operating System: what runs where, which controls apply and what evidence to request. The portfolio includes 104 filed UK patent applications and 2,340 claims. Applications describe claimed inventions; they are not granted rights or proof of security.
The diagram below illustrates an isolated configuration with the required services local. Its offline and zero-egress labels describe that intended boundary, which needs testing. External email, calendars and other connected workflows require separately approved connections or controlled transfers.
The stack
Read top down: the surface your teams meet first, down to the silicon it all stands on. Review dependencies and control coverage across the layers for each agreed workflow.
Studios
The work surfaceThe applications your teams live in: departments and messaging, meetings with sovereign minutes, documents and spreadsheets, CRM, projects and tasks, and the specialist studios for finance, legal, engineering and operations. The studios share the substrate; each workflow still needs defined permissions, audit coverage and processing boundaries. External messaging and other connectors require separate approval and evaluation.
The assistant
OrchestrationOne assistant surface coordinates work across studios, brains and automation. The architecture separates planning, authority to execute and verification of the outcome. Agree which steps are recorded and signed, then test permitted actions, denied actions and failures in the proposed version.
The brains
ReasoningFifty specialised brains, twenty five domain and twenty five operational, coordinated by a deterministic arbiter. Each brain has a domain; the arbiter routes requests or composes a quorum across several. Evaluate routing quality, human review and the routing events captured in the audit record for the agreed workflows.
The trust plane
Proof and containmentThe trust plane combines the Open Audit Record, hardware identity, Sentinel and the sandbox gateway. OAR uses hash linkage and ML-DSA-65 signatures designed for offline verification with a trusted public key. Hardware attestation, destructive-action checks and prompt-injection inspection are controls to evaluate, not proof that attacks cannot succeed. Test audit coverage, key custody and the configured egress paths.
The runtime
InferenceOn-device inference across CPU, GPU and NPU, with the execution balance selected for the workload. Offline operation requires the models, authentication, extraction, retrieval and other supporting services to be local. Inspect telemetry, licensing, updates and support tooling as well as inference; connected workflows need an explicitly scoped network path.
The hardware
Customer-owned groundThe deployment options use customer-owned hardware: a sovereign workstation, an office estate, or rack-scale inference with Pantheon. Size and test the estate against model memory, concurrent requests, storage and recovery needs. Adding machines also requires review of identity, permissions and operational support.
Four properties to verify
Scope offline operation
Keep the required workflow and its dependencies local, then test a disconnected start and recovery. Live external information requires a connection or controlled import.
Define the egress boundary
Map and test data flows, including telemetry, backups and support. Separately scope any operator-approved gateway; a connected workflow is not fully air-gapped.
Verify recorded actions
Agree which actions and outcomes enter the signed audit record. Check integrity, missing events and key trust separately; a valid signature does not prove correctness.
The operator holds the keys
The design places key custody with the operator. Confirm storage, administration, backup, recovery and support access for the actual deployment.
Three deployment shapes, one codebase
Choose the shape against the workflow, isolation and capacity requirements. Confirm supported features and test the controls in the proposed deployment.
Sovereign workstation
A single-operator deployment on one machine, with local models, company knowledge and audit services. Assess casework, deal-room or incident-response workflows against their requirements. Air-gapped operation depends on the configured services and controlled imports.
On-premise estate
An installation in your server room serving departments across your internal network. Test department permissions, concurrent workloads and audit coverage. On-premise location alone does not establish zero egress; inventory source connections and external services.
Air-gapped enclave
An environment isolated from external networks, for workflows whose requirements call for that separation. Keep required services and verification materials inside the boundary, with controlled updates and transfers. Demonstrate disconnected operation, key recovery and restoration for the agreed period and workload.
Architecture questions
What is the architecture of the Mickai SIOS?
The Sovereign Intelligence Operating System is described as six layers: customer-owned hardware, local inference across CPU, GPU and NPU, a trust plane with the Open Audit Record and execution controls, fifty specialised brains, an assistant and the studios used by employees. Offline operation requires all dependencies of the agreed workflow to be local. External email, web information and connected services need an approved connection or controlled import.
How should zero data egress be assessed in a Mickai deployment?
Define the workflow and boundary, inventory its dependencies, and test with external access blocked while observing network and application logs. Include authentication, extraction, retrieval, telemetry, licensing, backups and support. The architecture provides for a sandboxed gateway for approved connected work; assess that path separately from isolated workflows. Record test versions and limitations rather than treating a location label as proof.
How does the Mickai architecture scale from one machine to an enterprise?
The architecture describes a sovereign workstation, an on-premise estate and an air-gapped enclave. Confirm supported capabilities for the proposed version and hardware. Expansion needs representative load tests, department permissions, account revocation, audit coverage and recovery checks; adding machines alone does not demonstrate that the larger deployment meets those requirements.
Architecture is one of three trust surfaces. The control catalogue lives on the security page; the regulatory mappings live on the compliance page.
Walk the stack with the team that built it.
A briefing covers the architecture against your estate: hardware, isolation, audit and deployment options. Agree information-handling boundaries before sharing confidential material.