Occasionally run processes in degraded mode when not required — rehearse partial failure so mode-switching is familiar, not frightening

Why This Is a Rule

Netflix's Chaos Monkey deliberately kills production servers during normal operation to ensure their systems handle failures gracefully. The same principle applies to personal systems: if you only run full mode, the transition to degraded mode feels like failure. If you periodically practice running in degraded mode, the transition feels like a familiar alternative — reducing the psychological barrier to mode-switching when real constraints arrive.

The psychological dimension is as important as the operational one. People resist switching to degraded mode because it feels like giving up: "I should be doing the full version." This resistance keeps them attempting full mode under conditions where it will fail, producing binary outcomes (full execution or nothing) instead of graceful degradation. Periodic practice normalizes reduced operation: it's not failure, it's a practiced alternative that preserves continuity.

The occasional frequency is important — not constant (that would normalize degradation as the default) but frequent enough that the mode is familiar when needed. Once a month or during every 4th cycle is typical: enough to maintain procedural memory without undermining full-mode operation.

When This Fires

• Monthly or every 4th cycle of any process with designed degraded modes
• Before anticipated disruption periods as a rehearsal
• When you notice resistance to mode-switching during actual constraints
• Extends Test degraded modes during calm periods — if they don't work when you're resourced, they'll certainly fail under stress (test during abundance) from initial testing to ongoing rehearsal

Common Failure Mode

Only running full mode and treating degradation as shameful: "A real professional never does the minimal version." This perfectionism makes degraded mode feel like failure, which makes switching to it psychologically difficult, which means you skip the process entirely when full mode isn't possible. The result: binary execution (full or nothing) instead of continuous operation across modes.

The Protocol

(1) For each process with designed degraded modes (Design three operating modes for every important process: full, reduced, and minimal — degrade fidelity but never lose continuity), schedule occasional practice runs. (2) Once per month (or every 4th cycle), deliberately run the reduced or minimal mode even though you could run full mode. (3) During practice: notice how the degraded mode feels. Is it smooth? Awkward? Does it preserve the core function you designed it to preserve? (4) After practice: note any adjustments needed. The reduced mode might need a small modification, or the transition might need a different cue. (5) The goal is familiarization: when real constraints force mode-switching, the degraded version should feel practiced and comfortable — a legitimate operating mode, not a desperate fallback.