Federated fleet coordination. Why sovereign AI scales horizontally across departments without surrendering tenancy.

A single sovereign AI is enough for a workstation. A government department needs a fleet. An NHS trust needs a fleet. A defence prime needs a fleet. The question is whether that fleet is a hundred sovereign AIs that cooperate, or one centralised AI that the operator pretends is sovereign because the inference instance happens to live in their region. The two architectures look superficially similar from the procurement side. Operationally they are opposites.

Mickai's federated fleet coordination primitive (Patent 17 of the Mickai portfolio at the UK Intellectual Property Office, application UK00004373277, sole inventor Micky Irons) is the protocol that makes the first architecture, the cooperating fleet, work in practice. This article is the protocol, the trust model, and the structural answer to the question 'how does a Whitehall department run sovereign AI at scale without it collapsing back into a centralised system'.

The fleet trust model

Every machine in a Mickai fleet runs its own complete sovereign AI: its own brains, its own audit ledger, its own hardware-bound identity layer, its own clearance enforcement, its own runtime perimeter on every agent. No machine ceded any of these to any other machine. There is no central fleet controller that holds keys, mediates traffic, or arbitrates decisions on behalf of the fleet.

What the fleet shares is a federation protocol. Each machine publishes a small set of signed federation records to a fleet-wide append-only log: its identity attestation, its clearance posture, the brains it offers, the rate limits it can sustain, the audit-record schema version it speaks. Other machines in the fleet read those records, decide which peers to trust with which classes of work, and route accordingly. The federation protocol is structurally analogous to BGP routing on the internet: each peer announces its own posture, each peer chooses its own routes, no central authority is in the loop.

What gets federated

1. Decision arbitration

When a high-stakes decision (a clinical recommendation, a defence-procurement classification, a financial-control authorisation) needs more than one Mickai brain to weigh in, the federation protocol can route to peers in the fleet. Each contributing peer signs its contribution under its own ML-DSA-65 key (Patent 08); the originating machine arbitrates as it normally would (Patent 06 multi-brain coordination); the audit ledger records every contributing peer by hardware-attested identity. The arbitration is auditable end to end. The contributing peers do not surrender custody of their internal brains; they expose only the typed cooperation interface.

2. Audit replication

A regulated environment often requires that audit ledgers be replicated across multiple physical sites for resilience and verifiability. Mickai's federated audit replication ships signed audit records (Patent 16) to designated peer machines on a configurable cadence. Each replica carries the original signature; tampering at any replica is detectable because the signature chain breaks. The operator can run one machine in the head office, one in a separate building, and one in a regional office, and have cryptographic certainty that they all hold byte-identical audit history. This is the structural answer to 'where does the regulator-presentable audit ledger live'. The answer is 'on every machine the operator chooses, with cryptographic equivalence between them'.

3. Brain federation across institutional boundaries

A small NHS trust may not have the budget to host a specialised oncology brain locally. A larger trust may. The federation protocol lets the small trust route specific queries (under explicit operator policy, with full clearance and consent gating) to a larger trust's specialised brain, signed end to end, with the result returning to the small trust's local audit ledger. The smaller trust's local users see the same UI and audit trail; the larger trust's brain does the work; both institutions retain their own tenancy, identity, and audit. Patent 17 covers the cross-boundary signed routing.

4. Clearance descent at the fleet level

When a user moves between Mickai-protected machines (a clinician working from a hospital workstation today and a private practice workstation tomorrow), the federation protocol propagates only what the user's per-tenant clearance allows. The hospital workstation's tenancy stays inside the hospital's federation domain; the private practice tenancy stays inside the private practice domain. The user's identity is the connective tissue but the data does not cross boundaries unless the user, at the originating tenancy, explicitly authorises it.

5. Distributed deadman and distributed Hereditas

An institution that runs Mickai at fleet scale has institutional analogues of the Hereditas deadman protocol covered in our previous article (mickai.co.uk/articles/hereditas-when-the-ai-knows-the-user-has-died). When a key role-holder ceases to be available (resignation, death, regulatory removal), the fleet has a structured handover that cascades cleanly across machines without requiring centralised intervention. The continuity is auditable; the institution's signed memory survives the role-holder.

What this gives the institution

• Horizontal scale without centralisation. Add machines to the fleet; the federation protocol auto-discovers and integrates them. No central controller becomes a bottleneck or a single point of failure.
• Cryptographic resilience. Audit history replicates to multiple physical sites with byte-identical equivalence; the institution's signed memory survives any individual machine's loss.
• Cross-boundary cooperation. A small clinical site can use a larger site's specialised brain without surrendering tenancy. A defence prime can collaborate with subcontractors without anyone losing key custody.
• Per-machine autonomy. Each machine continues to run its full sovereign AI even when offline. Federation is opportunistic; loss of network does not collapse the local machine to a degraded state.
• Auditable cooperation. Every cross-machine interaction is signed end to end. A regulator inspecting any decision can walk the chain across machine boundaries and arrive at hardware-attested actor identities every time.

Why this matters for procurement

UK procurement frameworks for AI in regulated sectors are converging on requirements that look impossible to satisfy with centralised hosted AI: physical locality, operator-side audit, cryptographic isolation, post-quantum signed memory, hardware-bound identity, runtime perimeter on agents, and now (added in the last cycle of guidance) horizontal federation across institutional boundaries without ceding control. Centralised hosted AI cannot satisfy these requirements at any number of machines because the architecture itself is centralised. Mickai's fleet coordination satisfies them by construction because the architecture is federated by construction.

Where this sits

Mickai is the sovereign AI operating system. Twenty-one filed UK patent applications. Six hundred and seventy-five cryptographically signed claims. Sole inventor Micky Irons. Application reference UK00004373277. Federated fleet coordination (Patent 17) is the protocol that lets sovereign AI scale horizontally without surrendering the properties that make it sovereign in the first place. Mickai is held privately by its founder; the engagement model is direct.

“Sovereign means the fleet cooperates without anyone losing custody. Each machine signs its own work. The audit chains across the boundary. The operator owns every key.”

Sources

• Mickai patent portfolio: mickai.co.uk/patents (Patent 17, federated fleet coordination).
• Previous Mickai articles: mickai.co.uk/articles/the-2026-sovereign-ai-manifesto, mickai.co.uk/articles/multi-brain-cooperative-intelligence-why-one-llm-is-not-enough, mickai.co.uk/articles/hereditas-when-the-ai-knows-the-user-has-died.