Decompose error handling into four independent subsystems: detection, diagnosis, correction, learning — partial failure shouldn't disable the whole system

Why This Is a Rule

Most personal error-handling is a monolithic blob: when something goes wrong, you detect the error, diagnose the cause, fix the problem, and (sometimes) learn from it — all in one interleaved process. When any part of this blob fails, the entire error-handling capability fails. If you can't diagnose the cause, you also don't correct or learn. If you fix the error but skip the learning, the same error recurs.

Decomposing into four independent subsystems creates modularity: each subsystem can fail without killing the others. If diagnosis fails (you can't figure out why), detection still catches the error, correction still applies a workaround, and the learning system flags "undiagnosed recurrence" for deeper analysis later. If correction fails (you can't fix it immediately), detection still catches it, diagnosis still explains it, and learning still extracts the lesson.

Each subsystem can also be improved independently. Better detection tools don't require changing the diagnosis process. Better learning practices don't require changing the correction procedures. This modularity reduces the complexity of each improvement effort.

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 — if it only reduces frequency, keep digging-510), error classification (Classify errors as execution, knowledge, or judgment failures before correcting — each type needs a fundamentally different fix) — processes the detection log. Correction: how is the error fixed? Immediate workarounds, structural fixes (Recurring errors with the same root cause need structural fixes, not more effort — process changes beat discipline every time-500) — can act even without complete diagnosis. Learning: how does the system improve? Pattern recognition (After 10+ post-action reviews, analyze in aggregate — patterns across unrelated tasks reveal systemic tendencies, not isolated errors, Log every mistake for 30 days with date, event, and conditions — no analysis, just raw data for pattern detection), assumption identification (Within 24 hours of an error, write one mechanistic sentence + the incorrect assumption it revealed — before memory reconstructs) — 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 changes destroy causal attribution of what worked applied to error-handling architecture).