Checkpoint lifecycle: idempotency + precondition + verify + rollback
approved action
idempotency key k
precondition check
state still consistent?
mark-as-done-first
persist "committed" BEFORE exec
execute side effect
tool call / DB write / send
post-action verify
re-read target resource
verify passes
done
verify fails
known-bad state detected
rollback fires
in-band / compensating / alert
the sharp failure: double-execute on retry after crash
1. commit starts · 2. execute succeeds · 3. crash before persisting "committed"
4. resume, sees "approved not committed" · 5. re-executes · 6. side effect fires twice
mitigation: persist "committed" BEFORE execute ("mark-as-done-first" pattern)
EU AI Act Article 14 — operational reading
checkpoints queryable (auditor access, not just logs)
rollbacks rehearsed (end-to-end test, not documented intent)
audit trail survives deploys (PostgreSQL or Durable Objects, not in-memory)