Test degraded modes during calm periods — if they don't work when you're resourced, they'll certainly fail under stress
Test degraded operating modes during periods of abundant resources to verify they preserve core function, because modes that fail under calm conditions will certainly fail under stress.
Why This Is a Rule
Degraded modes are designed to function during resource scarcity — illness, stress, travel, crisis. But if you design a degraded mode and first test it during an actual crisis, two failure types compound: the stress of the crisis and the unfamiliarity of the mode. The result is often that the degraded mode fails, and you conclude "degraded modes don't work for me" when the actual conclusion should be "untested modes fail under stress."
Testing during abundance — when you have full energy, stable routines, and low stress — isolates the mode design from the stress conditions. If the minimal version of your writing practice (one sentence) works smoothly during a calm week, you know the design is sound. If it fails even during a calm week (the trigger doesn't fire, the one sentence feels awkward, you can't find the right moment), the design needs revision before stress ever tests it.
This is the behavioral equivalent of fire drills: you practice evacuation when there's no fire, so the procedure is familiar when there is one. Practicing degraded modes under calm conditions builds the procedural memory that makes mode-switching automatic rather than effortful when real disruption arrives.
When This Fires
- After designing any degraded or minimal operating mode (Design three operating modes for every important process: full, reduced, and minimal — degrade fidelity but never lose continuity)
- During calm, resourced periods — schedule deliberate tests of your fallback modes
- Before anticipated disruptions (upcoming travel, known busy periods, seasonal challenges)
- When you've never actually run a degraded mode you designed — it's untested infrastructure
Common Failure Mode
Designing degraded modes on paper and never testing them: "If I get sick, I'll do the minimal version." When sickness arrives, the minimal version has never been practiced, the trigger is unfamiliar, and the reduced scope feels wrong because you've only ever done the full version. The degraded mode dies on first contact with actual stress.
The Protocol
(1) After designing a multi-mode process (Design three operating modes for every important process: full, reduced, and minimal — degrade fidelity but never lose continuity), schedule a test of each degraded mode during a normal week. (2) Run the reduced mode for one full cycle. Does it preserve core function? Does it feel executable? Does the trigger work? (3) Run the minimal mode for one full cycle. Same questions. Can you actually do it in under 5 minutes? Does it maintain the behavioral chain? (4) Note any design problems and fix them now, while you have the cognitive resources to redesign. (5) After testing, you have verified degraded modes that you know work. When disruption arrives, you switch to a mode you've already practiced — not a theoretical design you've never tried.