Hereditas: when the AI knows the user has died, and the digital estate handover is cryptographically clean.

A reasonable estimate: by 2030 the average British adult will have between three and seven autonomous AI agents running on their behalf, with persistent memory, signed credentials, scheduled tool invocations, and ongoing relationships with downstream services. None of those agents has any procedure for the case where the user dies. None of them has a clean handover. None of them gives the executor of the estate any way to take possession without first proving they are the user, which they cannot, because they are not. The default behaviour is that the agents keep running until the cloud subscription lapses, the credit card on file fails, or the operator's operations team manually terminates a service. That is not a sovereign answer. It is a billing answer.

Hereditas is the Mickai sub-component that handles post-mortem activation cleanly. It is filed under the Mickai portfolio at the UK Intellectual Property Office (UK IPO public register, GB2607309.8 to GB2610422.4, named inventor Micky Irons). This article is the design.

The four problems

• Detection. The system needs to know the user has died, with confidence sufficient to start an irreversible procedure. False positives are catastrophic; false negatives leave the estate in limbo.
• Authentication of the executor. The estate handover has to reach a person who can prove (a) they are alive, (b) they are the legal executor, and (c) they hold the multi-witness attestation Hereditas requires. The system must not accept any single party's claim of executorship.
• Clearance descent. The user's data has clearance levels (the personal stuff at clinical clearance, the family stuff at private clearance, the working stuff at professional clearance, the regulated stuff at higher clearances). Different parties inherit different ceilings. Clearance descent has to be enforceable post-mortem without leaking what was hidden.
• Audit. The transition has to be a signed, hash-chained record the executor can hand to a probate court (or to HMRC for inheritance-tax purposes) that proves what was transferred, to whom, when, and under whose authority. Without exposing the contents.

Detection: the deadman switch

Hereditas runs a deadman switch keyed to user-presence signals. The signals are configurable, but the defaults are designed to fail safely: a voice biometric check the user passes naturally during ordinary daily Mickai use, a hardware-token presence check whenever the user authenticates a new tenant, and an out-of-band check-in cadence the user sets at first onboarding (weekly, monthly, quarterly). If the cadence lapses, Hereditas does not immediately escalate. It escalates through a series of staged checks: a notification to the user's primary device, a notification to a list of trusted contacts the user nominated at onboarding, a configurable wait window, and finally an attested-witness contact step.

The escalation is staged because the cost of a false positive is not symmetric. A user who is on a long sabbatical, in hospital and unable to authenticate, or temporarily without their hardware token, must not have their digital estate distributed under them. The stages are designed so that the user has multiple opportunities to refute the deadman trigger before any irreversible action occurs.

Authentication: multi-witness attestation

When the deadman trigger fires, Hereditas does not act on the executor's word. It requires a multi-witness attestation: at least two of the user's nominated witnesses (configured at onboarding, replaceable any time during the user's lifetime, never replaceable post-trigger) must independently attest, each through their own hardware-bound Mickai identity, that the user has died. Each witness's attestation is signed under their own Ed25519 key, recorded in the Hereditas ledger, and time-stamped. The witnesses cannot be the executor; the cryptographic separation is enforced at onboarding.

The executor's authentication is a separate step. The executor presents probate documentation (a death certificate scan, a grant of probate when issued, a letter of administration in intestacy) to a configurable verifier. The verifier can be a human (a solicitor the user nominated) or a process (the configured probate-attestation service for the user's jurisdiction; in the UK this defaults to a HM Courts & Tribunals Service grant-of-probate verification). The executor's authentication ties to a hardware-bound identity that was created at the moment of authentication; the executor does not inherit the user's identity, they inherit a structurally distinct successor identity that can be audited separately for everything they do post-handover.

Clearance descent

Different parties inherit different clearance ceilings. The user defines the descent at onboarding and can amend it at any time during life. A reasonable default for an individual user with a small estate: the spouse inherits a personal-clearance ceiling, the children inherit a family-clearance ceiling, the executor inherits a procedural-clearance ceiling sufficient to dispose of the estate but not the user's private correspondence. Anything above the inherited ceiling is encrypted, sealed, and cryptographically inaccessible to the descending party. The same Patent 05 mechanism that powers clearance-ceiling RAG (a query that lacks the right clearance returns the same response as a query for content that does not exist) governs clearance descent. The inheritor never sees that something was hidden, only that nothing was found at their ceiling.

For estates with non-standard descents (a family business, a professional practice with regulated client material, a research archive with specific institutional bequests), the user can define arbitrary clearance descent rules at onboarding. The rules are encrypted under the user's master key, attested at definition time, and only become operative when the deadman trigger has fired and multi-witness attestation has succeeded.

The transition ledger

Every step of the post-mortem transition is appended to a hash-chained ledger signed under the FIPS 204 ML-DSA-65 post-quantum signature primitive Mickai uses for every audit-relevant record (Patent 08). Every witness attestation, every executor authentication step, every clearance-descent decision, every encrypted bundle handed to each party, every revocation of the user's hardware-bound identities. The ledger is renderable as a court-ready PDF that contains the full audit trail without exposing the contents of the estate. A probate court (or HMRC) can verify the chain end to end and has cryptographic certainty about what happened, when, and under whose attestation, without any of the parties having to reveal the inherited material.

The court-ready render is structured: it leads with the deadman trigger evidence, then the witness attestation chain, then the executor authentication chain, then a clearance-descent diagram with each inheritor and their ceiling, then a per-inheritor handover record (timestamps, signed acknowledgements, revocation receipts). It does not contain a single byte of the inherited material. It contains the proofs that the material was handled correctly.

Why the user authorises this in life, and how the configuration evolves

Hereditas runs only if the user has explicitly turned it on, configured the deadman parameters, nominated witnesses, set the clearance descent, and accepted the operating posture. The configuration is amendable any time during life, with every amendment signed under the user's hardware-bound identity and recorded in a separate amendment ledger. The user can disable Hereditas entirely at any moment; disabling immediately voids any outstanding deadman state and requires re-onboarding to re-enable. Witnesses can be added or removed; clearance descent can be revised; executors can be replaced. The system is designed to be lived with for decades and configured incrementally as the user's life and estate change.

Why this matters for sovereign AI

Sovereign AI is not just about the operator's lifetime. It is about the operator's estate. A sovereign system whose post-mortem behaviour is 'keep running until the credit card lapses' is not sovereign in a way that survives the operator. Hereditas is the structural answer that makes Mickai's sovereignty inheritable. The same audit-ledger primitives, the same hardware-bound identity, the same clearance system, the same post-quantum signing, all of it composes into a digital-estate handover that is cryptographically clean, court-presentable, and survivable.

If sovereign AI is going to be the substrate of long-form personal computing for the next thirty years, this is the property the substrate has to have. Without it, the substrate fails the moment the operator does. Hereditas is the patent-protected answer.

Where this sits in Mickai

Mickai is the sovereign AI operating system. Thirty-one filed UK patent applications. Nine hundred and fourteen cryptographically signed claims. UK IPO public register, GB2607309.8 to GB2610422.4. Hereditas is one of the cooperating sub-components, alongside the privacy router, the multi-brain arbiter, the clearance-ceiling RAG layer, the post-quantum signing primitives, the hardware-bound identity layer, and the runtime perimeter (Sentinel) that gates AI-agent action. Mickai is held privately by its founder; the engagement model is direct.

“Sovereign means the architecture survives the operator. The deadman is staged. The witnesses are independent. The clearance descends. The court has the proofs without reading the contents.”

Sources

• Mickai patent portfolio: mickai.co.uk/patents (31 filed UK patent applications, 914 signed claims, UK IPO public register, GB2607309.8 to GB2610422.4). Hereditas is filed under the post-mortem activation patent block.
• FIPS 204 (ML-DSA): NIST post-quantum digital signature standard.
• HM Courts & Tribunals Service: grant of probate verification (default executor-authentication route for UK users).
• Previous Mickai articles: mickai.co.uk/articles/the-2026-sovereign-ai-manifesto, mickai.co.uk/articles/twenty-one-uk-sovereign-ai-patents-collaboration-open.