principle · chain-level thinking
Chain-level thinking
A defect surfaces in a person's hands. Its root is rarely there.
A bug is filed. Engineers triage. The instinct is to find who touched the code last and trace the fix backwards. The corpus's discipline is the opposite: trace the defect forwards, through the chain, asking at each level did this level of the chain have an opportunity to catch this, and didn't?
Same defect, five different fixes. A Hebrew name renders broken bug at Execution level is a regex change. The same observation at Discovery level is a brief that didn't witness Hebrew speakers — and a feature that needs reshaping. The team that fixes at the wrong level pays for the same bug twice.
The five levels
Every defect lives at one of these levels — sometimes more than one, in which case the root is the highest.
| Level | What it produced | Cost to repair |
|---|---|---|
| Strategy | The wrong bet, the wrong portfolio | 5–10× of execution cost |
| Discovery | The problem was not witnessed | 3–5× |
| Scope | The story missed a state, the ADR was missing | 2–3× |
| Execution | The code, test, or pipeline misbehaved | 1× (baseline) |
| Operation | The runbook, the SLA, the support pipeline failed | 1.5–2× |
The multipliers are heuristic; the order is not. A Strategy gap costs an order of magnitude more than an Execution gap. This is what makes the chain's earliest gates expensive insurance: a weekend of Discovery prevents a quarter of execution rework, and the math is not subtle.
What chain-level thinking is not
It is not blame deflection. We can't be expected to fix this; it's a Discovery issue is a misuse of the principle. Tracing to a level opens the conversation; it does not close it. The structural fix is at the level the defect originated, regardless of which team owns that level.
It is also not a reason to skip Execution discipline. Many defects are exactly what they look like — code defects, fixed in code. The principle does not say all bugs trace to Discovery. It says some do, and the team that doesn't ask which level pays the same cost twice.
What it does mean
In practice, three things.
Triage classifies by chain level. Every bug, alongside severity and class, gets a chain-level tag. Recurring concentration in one level is a structural signal — most of our defects keep tracing to Discovery is a finding about the team's discovery practice, not about engineers.
Postmortems read at the chain level. Why did the chain not catch this before this person? — not why did this person not catch this? The structural fix lives in the runbook template, the brief template, the ADR record, or the release-gate checklist. Not in we will be more careful.
Fixes are owned at the level they originated. A code fix for a Discovery-rooted defect treats the symptom. The structural fix is a brief-template change, an observation-cadence adjustment, or a Discovery-budget protection at portfolio level.
What this enables
Teams that practise chain-level thinking become harder to scare. Bugs are uncomfortable but not catastrophic; they are the chain's way of telling the team where it is leaking. Postmortems produce structural changes, not feelings. The team's quarter-over-quarter trend is fewer bugs at the same chain level — which compounds in a way that fewer bugs overall never quite does.
See also
- Canon — After We Build · Bugs and Their Roots
- Canon — After We Build · Incidents and Postmortems
- Principle — Compounding small changes