Execute and prove a planned rollback

Editorial review pendingon 2026-07-29version support under review

Decide the trigger before the change

A rollback trigger is observable and owned: a required acceptance check fails, a critical integration cannot complete its bounded test, a state migration cannot be validated, or the recovery objective is threatened. “Someone feels uncomfortable” may be a good reason to pause, but it is not a useful trigger unless the decision owner records the concern and chooses the action.

The rollback record

Use this order:

1. freeze further change and announce the status;
2. preserve the relevant evidence window and release identifiers;
3. apply the approved release-specific rollback or restore procedure;
4. validate the known-good state with the same critical-path checks; and
5. record what remains unknown.

The exact OpenClaw package, service, configuration, SQLite/state recovery, and gateway procedure must come from the target release’s approved runbook. Do not infer it from a successful rollback on another version.

Lab: prove the recovery point

In a sandbox, trigger the pre-agreed condition. Work from your recovery checklist. Record the time to restore, recovery point age, every acceptance check, and the evidence location. If the recovery cannot be completed, record that as the result and open an evidence gap; do not edit the record to make the game day pass.

Check: a version number alone cannot satisfy the lab. The proof must show that the protected state and critical behavior were accepted after recovery.

Checkpoint

Put these actions in order: preserve evidence, freeze change, restore, validate, communicate. The precise technical implementation varies by release; the order protects both the investigation and the users.

Learner artifact

Capture a synthetic, redacted before-and-after diagnostic view. Annotate version identifier, recovery-point marker, acceptance checks, and remaining uncertainty. Never use a real support transcript or a real customer payload.