Detect errors at the earliest catchable point — correction…

Why This Is a Rule

Barry Boehm's cost curve (1981) demonstrated that software defects caught in requirements cost 1x to fix, in design 5x, in coding 10x, in testing 50x, and in production 200x. The exponential increase is not software-specific — it applies to any process where downstream steps build on upstream outputs. An error in a foundation affects everything built on top of it; the deeper the propagation, the more rework is required.

"Shift left" — moving detection earlier in the process — exploits this cost curve. A checkpoint at step 2 of a 10-step process catches errors before 8 steps of work build on the flawed output. The same checkpoint at step 8 catches the error but requires rework of steps 3-7. At step 10, the entire pipeline needs rework.

The "earliest catchable point" qualifier is important: some errors can't be detected until a later step produces enough output to reveal the problem. The checkpoint goes at the first point where detection is possible, not at step 1 regardless of what's detectable there. This requires understanding what each step produces and what errors become visible at each stage.

When This Fires

• When designing error detection architecture for any multi-step process
• When deciding where to place quality gates, reviews, or validation checks
• When errors are consistently caught late and correction costs are high
• Complements When the cost of late error discovery exceeds 5x early… (phase-gate cost ratios) and Place pre-flight checks at the prep/execution boundary… (pre-flight positioning) with the general placement principle

Common Failure Mode

Placing all checkpoints at the end: "We'll review everything before shipping." End-of-process review catches errors but only after maximum propagation. An error introduced at step 2, caught at step 10, requires rework of 8 steps. The same error caught at step 3 requires rework of 1 step. End-of-process review is the most expensive possible detection architecture.

The Protocol

(1) Map your process: what does each step produce, and what errors can first be detected at each step? (2) For each error type: identify the earliest step where this error becomes detectable. Place a checkpoint there. (3) The checkpoint doesn't need to be comprehensive — a quick validation that catches the most common upstream errors is sufficient (Checklists are 5-10 items that catch what competent people…). (4) Multiple small checkpoints distributed early in the process outperform a single comprehensive checkpoint at the end. Each early checkpoint reduces the propagation distance for its error category. (5) Track where errors are actually caught: if most errors are caught at late checkpoints, you're missing opportunities for earlier detection. Can those error types be detected sooner?