Design three operating modes for every important process: full, reduced, and minimal — degrade fidelity but never lose continuity
For every important recurring process, design three explicit operating modes—full, reduced, and minimal—where each preserves progressively less fidelity but never loses continuity.
Why This Is a Rule
This extends Design a degraded-mode version of every recurring system before it breaks — preserve core function at reduced scope (degraded-mode design) with a more precise three-tier structure. While Design a degraded-mode version of every recurring system before it breaks — preserve core function at reduced scope introduced the concept of graceful degradation for behavioral systems, this rule specifies the exact architecture: three discrete operating modes, each explicitly designed and documented, with a clear relationship between them.
Full mode: the process as designed, with all components at full scope. This is the default when conditions are optimal. Reduced mode: core function preserved at reduced fidelity. Non-essential components are shed, but the process still produces its primary output, just less refined. Minimal mode: continuity-only operation. The process fires at its absolute minimum, preserving the behavioral chain and the habit structure but producing little output. The sole purpose of minimal mode is to prevent the process from dying entirely.
The three-tier structure matters because binary systems (full or nothing) are fragile: any disruption that prevents full-mode operation kills the process entirely. With three tiers, you have two fallback levels before total failure. The progression — full → reduced → minimal → dead — gives you three chances to maintain continuity before the process is lost.
The "never lose continuity" constraint is the non-negotiable: even minimal mode must preserve the trigger-response chain. A writing practice in minimal mode (one sentence) maintains the habit; a writing practice that stops entirely loses the chain and requires full reinstallation effort to restart.
When This Fires
- When designing any important recurring process that needs to survive disruptions
- When Design a degraded-mode version of every recurring system before it breaks — preserve core function at reduced scope's two-mode structure (full/degraded) needs more granularity
- When travel, illness, or crisis approaches and you want to protect existing processes
- During process architecture reviews when evaluating resilience
Common Failure Mode
Designing only full mode and treating disruption as binary failure: "My review process takes 2 hours every Friday." When Friday is disrupted, the review doesn't happen at all — there's no reduced mode (30-minute focused review) or minimal mode (5-minute priority check). The process dies for that week, and the behavioral chain weakens.
The Protocol
(1) For each important recurring process, explicitly design three modes: Full mode: the ideal execution with all components. Document what "full" includes. Reduced mode: shed the 40-60% lowest-value components. What's the core output this process must produce? Design a version that delivers that core in 30-50% of full mode's time/effort. Minimal mode: the absolute minimum that preserves continuity. Under 5 minutes, zero preparation, executable under any conditions. This mode's only job is to keep the habit chain alive. (2) Write all three modes down with explicit switching criteria: "When [conditions], switch to [mode]." (3) Pre-test reduced and minimal modes during normal conditions to verify they're actually executable. (4) When conditions degrade → switch modes rather than dropping the process entirely. Continuity at minimal fidelity beats perfect execution 60% of the time and silence 40% of the time.