Decompose error handling into four independent subsystems

When This Fires

• When designing error-handling systems for any recurring process
• When error-handling feels overwhelming because everything is tangled together
• When partial failures in your error response disable the entire response
• When you want to improve one aspect of error handling without redesigning everything

Common Failure Mode

Coupling detection and diagnosis: "I'll investigate every error I notice." This means you can't detect faster than you can diagnose — every detection immediately triggers a diagnosis effort. When diagnosis takes time, detection backlogs. If you separate them: detection logs the error (fast, low effort), diagnosis processes the log when capacity is available (batched, efficient).

The Protocol

(1) For each recurring process, design four independent error-handling subsystems: Detection: how are errors identified? Automated alerts, checklist checks, output verification — should run independently of everything else. Diagnosis: how is the cause determined? Root cause analysis (A true root cause, eliminated, makes the error impossible…-510), error classification (Classify errors as execution, knowledge, or judgment…) — processes the detection log. Correction: how is the error fixed? Immediate workarounds, structural fixes (Recurring errors with the same root cause need structural…-500) — can act even without complete diagnosis. Learning: how does the system improve? Pattern recognition (After 10+ post-action reviews, analyze in aggregate…, Log every mistake for 30 days with date, event…), assumption identification (Within 24 hours of an error, write one mechanistic…) — runs on accumulated data from all other subsystems. (2) Verify independence: if any one subsystem is disabled, do the others continue functioning? If not → decouple further. (3) Improve one subsystem at a time (Change one agent component per iteration — multi-variable… applied to error-handling architecture).