When correction exceeds 20% of weekly capacity, shift…
When error correction consumes more than 20% of weekly capacity in a domain, shift resources from faster correction to upstream prevention mechanisms that reduce error generation rate.
Why This Is a Rule
Below 20% correction overhead, errors are manageable noise — they consume some resources but don't significantly constrain productive output. Above 20%, correction has become a structural tax on the system. One-fifth of capacity diverted to fixing errors means the system is spending more time maintaining itself than it should, and the correction load is likely growing as the error-generating conditions remain unaddressed.
The strategic shift from correction to prevention is counterintuitive because correction feels productive — you're fixing problems, producing visible results, maintaining output. Prevention feels like overhead — you're investing time in changes that won't produce immediate visible output. But prevention reduces the error generation rate, which compounds: a 50% reduction in error rate produces 50% fewer corrections every week, indefinitely. Faster correction only reduces the time per correction instance while leaving the generation rate unchanged.
The 20% threshold is the inflection point where the correction tax is large enough to justify prevention investment. Below 20%, individual corrections are the efficient response. Above 20%, the volume of corrections signals a systemic problem that individual fixes can't resolve — you need upstream intervention that reduces how many errors are generated in the first place.
When This Fires
- When tracking correction time (Multiply direct correction time by 3x for true cost…) reveals that correction exceeds 20% of domain capacity
- When "firefighting" has become a significant part of your work routine
- When process improvement feels less urgent than the corrections demanding attention right now
- When the same error types keep recurring despite effective correction procedures
Common Failure Mode
Investing in faster correction instead of prevention: "Let's build a tool to fix this error faster." If the error occurs 10 times a week, reducing fix time from 30 to 15 minutes saves 2.5 hours weekly. Preventing 7 of the 10 occurrences saves 3.5 hours weekly (at the original fix time) and the savings grow if the prevention improves further. At >20% correction load, prevention ROI exceeds correction-speed ROI in almost all cases.
The Protocol
(1) Track correction time for one month using Multiply direct correction time by 3x for true cost…'s 3x multiplier. Calculate: what percentage of weekly capacity does correction consume? (2) If <20% → continue with correction-based approaches. Optimize individual correction procedures. (3) If ≥20% → shift investment to prevention. For the top 3 error types by correction time: identify the upstream cause (Classify errors as execution, knowledge, or judgment…, A true root cause, eliminated, makes the error impossible…) and design structural prevention (Recurring errors with the same root cause need structural…). (4) The prevention investment will temporarily increase total time spent (correction continues while prevention is being built). Accept this short-term cost — the long-term reduction in error generation rate will more than compensate. (5) After prevention deployment, re-measure correction percentage. If still ≥20% → the prevention didn't address the right causes. Re-diagnose.