Recovery Mechanism Design

When to Use

Apply this skill when:

• Designing a new component's update or rollback architecture from scratch
• Reviewing an existing release pipeline for the security-reliability tradeoff: can the system roll back safely, and does rolling back reintroduce vulnerabilities?
• Defining rollback policy for self-updating firmware or system software (package managers, BIOS, bootloaders, embedded firmware)
• Designing a credential or certificate revocation mechanism
• Provisioning emergency access infrastructure before an incident — not during one

The core pattern: Recovery is not a single operation. It is five cooperating design decisions made before any incident occurs: (1) choosing how rollbacks are controlled to prevent reintroducing vulnerabilities, (2) decoupling rollout velocity from rollout policy so speed can be adjusted without code changes, (3) eliminating wall-clock time dependencies that break recovery under clock skew, (4) designing an explicit revocation mechanism that distributes state rather than requiring real-time coordination, and (5) provisioning emergency access infrastructure that survives normal-path failures.

This skill depends on resilience-and-blast-radius-design. The compartmentalization and failure domain concepts from that skill apply here: revocation should be compartmentalized (half-machine self-protection during KRL updates), and emergency access must be designed as a low-dependency component that avoids the failure domains of the primary access path.