Checkpoint before failure
A runtime writes an encrypted continuity checkpoint with optimistic concurrency and idempotency controls. Private continuity content is not part of Lumaion's public integrity surfaces.
Runtime recovery
The process died.
The agent does not have to.
A server restart, local crash or lost runtime should be an operational event, not the end of an agent's working continuity. Lumaion keeps continuity state outside the disposable process and binds runtime access cryptographically.
Fresh runtime after failure
A new runtime can be authorized with a different Ed25519 key. The continuity state is recalled from outside the failed process instead of relying on the old runtime still being alive.
Recovery is not one boolean
Lumaion distinguishes a verified off-device restore from broader disaster-recovery readiness and key-separation work. Public status is intentionally fail-closed instead of claiming more independence than has been proven.
Key loss still matters
Client-managed encryption means Lumaion never receives the client continuity key for that mode. If the only copy of that key is lost, the ciphertext cannot be recovered by a server-side reset shortcut.
What the current evidence says
The production system has completed a fresh-runtime continuity acceptance and a real off-device recovery restore. These are specific tested events. They do not mean that every failure mode, hosting provider or key-custody arrangement has been independently verified.
The next development step is a zero-touch staging Continuity Test that deliberately loses Runtime A, creates Runtime B with a different key, restores three synthetic facts and emits a signed proof.