Local metric improved 50%+ but throughput gained less than 25%? That's a constraint cascade — immediately map downstream capacity limits

Why This Is a Rule

The local-system throughput gap is the signature diagnostic of a constraint cascade. When a local improvement (50%+ at one step) produces disproportionately small system improvement (under 25% total throughput), the math reveals that another constraint was closely behind the one you fixed. The improvement you created is being absorbed by the next constraint downstream rather than flowing through to increased output.

The specific thresholds — 50% local improvement producing less than 25% system improvement — indicate a cascade where the next constraint has capacity within 2x of the fixed one. If the local improvement were 50% and system improvement were 45%, the cascade gap is small (fixed constraint was the dominant bottleneck). If local improvement is 50% and system improvement is 10%, the cascade gap is large (the next constraint was almost as binding as the fixed one).

The prescribed response — immediately map downstream capacity limits — is urgent because the cascade represents wasted optimization effort if not addressed. You invested in fixing constraint A, and constraint B is now limiting throughput almost as much as A used to. Without mapping the cascade, you might continue optimizing the already-fixed constraint A (producing zero additional benefit) instead of shifting attention to constraint B.

When This Fires

• After Re-measure 2 weeks after any constraint fix: if local metric improved but total throughput didn't, the constraint has shifted elsewhere's two-week re-measurement reveals disproportionate improvement
• When workflow optimization produces "disappointing" results despite verified local improvements
• When the same total throughput persists despite fixing an obvious bottleneck
• Complements Map the constraint cascade before intervening: rank all steps by max capacity to predict where the next bottleneck will appear (cascade mapping before intervention) with the diagnostic that triggers cascade mapping after intervention

Common Failure Mode

Doubling down on the fixed constraint: "The improvement wasn't enough, so we need to optimize step 3 even further." But step 3 is no longer the constraint — further optimization produces zero system benefit. The constraint has shifted, and the optimization effort must shift with it.

The Protocol

(1) After any intervention, compare local improvement vs. system improvement. (2) If local improved 50%+ but system improved less than 25% → cascade detected. (3) Immediately map downstream capacity (Map the constraint cascade before intervening: rank all steps by max capacity to predict where the next bottleneck will appear): which step is now the binding constraint? (4) Redirect all optimization effort to the new constraint. Do not continue optimizing the old one — it's no longer the bottleneck. (5) Expect cascades as normal, not exceptional. In most multi-step systems, fixing one constraint reveals the next. The optimization process is iterative: fix → re-measure → identify new constraint → fix → re-measure.