Define triggers for mode transitions in both directions — especially the return path from degraded back to full

Why This Is a Rule

Mode transition triggers are the operating logic of a graceful degradation system (Design three operating modes for every important process: full, reduced, and minimal — degrade fidelity but never lose continuity). Without them, mode switching depends on real-time judgment — and real-time judgment is exactly what's impaired during the conditions that trigger degradation. You need pre-defined criteria that make the switch automatic: "When [condition], shift to [mode]."

The downgrade triggers get natural attention: "When I'm sick, switch to minimal mode." But the upgrade triggers — the return path from degraded back to full — are almost always forgotten. Without explicit upgrade criteria, systems get stuck in degraded mode long after the disruption has passed. You were sick for three days and ran your writing practice in minimal mode (one sentence). You've recovered, but without an explicit trigger to return to full mode, the one-sentence version becomes the new normal. The degradation that was designed as temporary becomes permanent because no return signal fired.

The return path requires its own explicit trigger: "When [recovery condition], begin transitioning back to [higher mode] within [timeframe]." This trigger must be as specific as the degradation trigger — not "when things get back to normal" but "when I've had three consecutive full-energy days."

When This Fires

• When designing any multi-mode process (Design three operating modes for every important process: full, reduced, and minimal — degrade fidelity but never lose continuity) — define all transition triggers before deployment
• When a process has been in degraded mode for longer than the disruption justified
• When designing recovery protocols (Document five recovery components for every important process: failure mode, detection trigger, recovery steps, time target, verification) — include mode upgrade triggers
• When a process seems permanently stuck at lower capacity despite conditions improving

Common Failure Mode

Defining only downgrade triggers: "When stressed, switch to minimal. When traveling, switch to reduced." But when does minimal switch back to reduced? When does reduced return to full? Without these triggers, every degradation is a one-way ratchet toward lower and lower performance levels. The system degrades naturally but doesn't upgrade without explicit direction.

The Protocol

(1) For each operating mode (Design three operating modes for every important process: full, reduced, and minimal — degrade fidelity but never lose continuity), define transition triggers in both directions: Downgrade triggers: "When [specific condition] → switch from [current mode] to [lower mode]." Upgrade triggers: "When [specific recovery condition] → begin transitioning from [current mode] to [higher mode]." (2) Make triggers observable (Apply the camera test to triggers — if a camera can't detect the exact firing moment, the trigger is too vague): "three consecutive full-energy days" not "when I feel better." (3) Include a transition timeline for upgrades: don't jump from minimal to full. Transition minimal → reduced (1 week) → full (1 week). (4) Default rule: if you've been in degraded mode for 2x the duration of the disruption and no upgrade trigger has fired, force a reassessment. The absence of an upgrade trigger might mean the system needs redesign rather than continued degradation.