How does a sealed AI audit ledger survive a reboot without phoning home?

A sealed audit ledger survives a reboot because its trust anchor lives in a hardware root of trust, re-derived through measured boot, not network calls. The proof of identity is bound to silicon, so it does not need to phone home.

In 2026 auditability is a procurement gate, not a nicety. Regulated buyers in defence, finance and critical infrastructure increasingly run on isolated, operator-owned hardware, where machines reboot, lose power and sit air-gapped for weeks. An audit trail that only holds while a licensing or attestation server is reachable is not an audit trail they can rely on. The reboot question is a real test of whether a sealed ledger is genuinely sovereign or quietly dependent on someone else's cloud. Mickai is a Sovereign Intelligence Operating System, a SIOS, built and live, running offline on operator-owned hardware with every action of its 50 brains, 25 domain and 25 operational, cryptographically sealed into one ledger.

What actually anchors the ledger's identity across a reboot?

Identity binds to a hardware root of trust, a TPM or secure element, and re-derives at each boot through a measured chain, never fetched online.

At every power cycle the boot process measures each stage into the root of trust and derives the node's identity key from those measurements. Because the same firmware and configuration produce the same measurements, the same identity re-emerges after a reboot with no external lookup. If a stage is tampered with, the measurement diverges, the derived key changes, and continuity with the sealed history breaks in a way that is visible rather than silent. This is hardware-attested identity bound directly to the audit chain.

How is the genesis entry, the first signed record, sealed so the chain has a valid root?

At provisioning we seal the genesis entry, the first signed record, under a hardware-attested key, so the chain's root exists before any network is reachable.

The cold-start problem is really a genesis problem: before there is a chain, what signs the first block. We solve it once, at provisioning, when the node's root of trust attests a fresh signing key and that key seals the genesis entry. From then on the chain has an immutable starting point. Every later record hash-links back to genesis, so a machine that boots cold and fully offline can still validate its whole history against a root that was fixed the day it was commissioned.

What happens when the hardware anchor itself fails?

Recovery uses threshold custody: the anchor is split across independent custodians, so no single failure breaks continuity and the ledger re-seals under a fresh key.

Hardware can fail, and a design that stakes everything on one chip is brittle. Custody of the recovery secret is therefore split so that a quorum, not any single holder, can restore trust. When a root of trust is damaged or replaced, the quorum re-seals the ledger under a new attested key while preserving the verified prior history, and the handover is itself written as a signed record. Continuity is a property of the threshold scheme, not of any one piece of silicon.

How does the ledger stay valid offline with no phone-home?

Verification is local: any holder recomputes the hash chain and checks signatures against the sealed anchor, so validity needs no server and no outbound call.

A sealed ledger is self-verifying by construction. The full record set plus the sealed anchor is everything a verifier needs, so an auditor can confirm integrity on a disconnected machine. This pairs with a zero-egress inbound perimeter: the node accepts what it needs to do its work but originates no outbound trust dependency, which is what offline verifiability actually requires.

“A ledger that must phone home to prove itself is not sealed; a ledger anchored in hardware proves itself alone, in the dark, across every reboot.”

How does the chain stay tamper-evident between boots?

Every record is signed under FIPS 204 ML-DSA and FIPS 205 SLH-DSA and hash-linked to its predecessor, so any edit, gap or reorder shows immediately.

Tamper evidence comes from two properties working together: each entry carries the hash of the one before it, and each entry is signed with post-quantum signatures. FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) sign the ledger. FIPS 203 (ML-KEM) is key encapsulation for establishing shared secrets and never signs anything, so it plays no part in the chain's integrity proof. Removing, altering or reordering a record either breaks a hash link or invalidates a signature, and cross-model consensus records leave a second corroborating trail.

How does Mickai handle each reboot challenge at a glance?

Each reboot challenge maps to one mechanism: hardware-sealed identity, a provisioned genesis, threshold recovery, local offline verification and post-quantum signing, summarised in the table below.

How does this compare with cloud-anchored audit designs?

Cloud-attested ledgers are excellent when connectivity is constant and custody sits with a provider; our design assumes isolation, so continuity never depends on reaching anyone.

For a well-connected SaaS estate, a cloud key management service and remote attestation are a strong, low-friction choice, and enterprise vendors do that job well. The contrast is one of assumptions, not quality. Where the US CLOUD Act can compel a US-based provider regardless of where servers sit, and where DORA, in force since January 2025, and NIS2 push essential and important entities toward provable operational resilience, a design that assumes isolation is often the safer default. On the EU AI Act, high-risk Annex III obligations once due 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moved to 2 August 2028 and Article 50 transparency largely unchanged, so buyers have room to choose architecture deliberately. These mechanisms sit within an IP estate of 104 filed UK patent applications and 2,340 claims, owned by Mickai LTD (Companies House 17166618), filed and patent pending.

Frequently asked questions

Does the ledger need internet to verify itself after a reboot?

No. Verification is entirely local. Any holder recomputes the hash chain and checks each signature against the sealed hardware anchor. Because the anchor lives in a TPM or secure element on the same machine, a rebooted, fully offline node can prove its own history without reaching any server.

What is a genesis entry and why does it matter?

The genesis entry is the first signed record in the chain, its cryptographic root. We seal it at provisioning under a hardware-attested key, so the chain has a valid starting point before any network exists. Every later entry links back to it, which is why cold-start verification works offline.

What happens if my TPM or secure element is damaged or replaced?

Continuity is protected by threshold custody. The trust anchor is split across independent custodians, so no single hardware failure ends the chain. On recovery the ledger re-seals under a fresh attested key while preserving the verified history, and the transition is itself recorded as a signed entry.

Why sign with ML-DSA and SLH-DSA rather than ML-KEM?

Signing and key encapsulation are different jobs. FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) are signature schemes, so they sign the audit ledger. FIPS 203 (ML-KEM) is key encapsulation for establishing shared secrets and never signs anything. Using each for its intended purpose keeps the chain verifiable against future quantum threats.

Does local verification slow the system down as the ledger grows?

No. Each record adds a fixed signing and hashing overhead that scales with the number of events, not with fleet size, because every node verifies locally rather than calling a central service. Verifying a given record set is deterministic, so an offline audit runs the same on a single laptop or a full rack.