Design for Interruption
Interruptions are inevitable. Execution environments are chaotic. Systems that demand perfect isolation fail when the real world intrudes.
This directive integrates interruption recovery into the system architecture.
The Core Principle
Recovery must be immediate and structured.
An interruption is only a pause. The failure occurs in the delayed recovery. Systems designed for interruption have clear boundaries, state-saving mechanics, and immediate resumption triggers.
A disciplined system expects to be broken and knows how to resume.
Why This Fails for Most People
Most people expect uninterrupted time. When interrupted, they lose momentum, abandon the task, and blame the environment.
They rely on flow states. They leave tasks in ambiguous states. They fail to capture context before switching. They delay resumption until they “feel ready” again.
Unstructured recovery kills execution.
The Gyōji Directive
Design systems to recover from interruption immediately.
If an interruption destroys the session, the system is defective.
Implementation Protocol
- Assume interruptions will occur.
- Save state frequently during execution.
- When interrupted, document the exact next step before stopping.
- Use that documented step as the trigger to resume.
- Resume execution the moment the interruption ends.
Recovery is a mechanical process, not a feeling.
Common Errors
- Expecting perfect focus blocks.
- Leaving context undocumented.
- Using interruptions as an excuse to quit.
- Delaying resumption.
Enforcement Rule
If resumption is delayed, the interruption becomes a failure.
Final Order
Expect interruption. Resume immediately.