Candidate Host Continuity Design

Candidate Host Continuity Design

The following is a design candidate, not an implemented or approved storage mechanism. A protected, versioned per-VM journal would retain the verified VM UUID, a generation, the last accepted boot baseline and any associated source observation, unresolved obligations and the baseline each depends on, and the identity and hash of any committed terminal receipt. A new verified baseline must not erase the historical baseline needed by another unresolved obligation. An attempt can resolve only obligations whose specific proof requirements it meets.

A separate, trusted anti-rollback anchor would bind the journal head's VM UUID, generation, and digest. A checksum, MAC, atomic rename, or protected directory alone cannot detect restoring an older, otherwise valid journal. Restoration of older host-local storage is within the required fault model. The anchor must itself resist the rollback being considered and must not be restored with the journal; a second file in the same rollback domain is not sufficient. Candidate authorities, host support, privilege, custody, durability, recovery, and the boundary against host or guest compromise remain unproven. If the journal and anchor can both be rolled back, or their agreement and provenance cannot be verified, continuity is UNKNOWN. A single independently rollback-resistant authority that durably stores the whole state could meet the same invariant instead. Neither mechanism is selected; this is not a hardware or remote-attestation claim.