# Incident Root Causes Live Upstream of the Failed Component ## Claim The component that broke is rarely the cause; the decision made hours earlier by someone outside their own domain of expertise usually is. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds for operational incidents that involve a human decision somewhere in the causal chain, made by someone without full visibility into a neighboring domain. - Breaks for pure hardware wear-out and for supply-chain compromises that originate entirely outside the team's own decision surface — there, the "upstream decision" framing doesn't apply because no team decision is in the chain. ## Evidence In *Project Hail Mary*, a fuel tank ruptures and nearly kills Grace. The failed tank isn't the cause — the cause is that Grace, who isn't a pilot, flew a sample-collection maneuver at an angle that created an aerodynamic backdraft, superheating and fracturing the hull hours before the rupture. Competence and diligence narrowed the gap but didn't close it, because the missing knowledge sat outside his domain. > [!quote] > we still can't (and won't) know everything. And the things we don't know can (and might) hurt us ## Links - [[3. Resources/Permanent Notes/Thriving Conditions Are Personal Not a Performance Signal]] — because extends; same source, same series of closing lessons - [[3. Resources/Permanent Notes/A Test That Cannot Return No Cannot Validate Yes]] — because contrasts; that note is about validation design, this one is about causal attribution in postmortems — both concern where teams stop looking too early - [[3. Resources/MOCs/Product & Startup Instincts MOC]] — because applies-in; incident review practice for engineering teams - [[3. Resources/MOCs/Evidence & Claims Literacy MOC]] — applies-in: Joins the cluster on failures hidden in layers nobody instrumented; fit is loose. ## Tests / falsifiers - Audit a sample of past incident postmortems: does the root-cause line identify a decision made outside the decider's domain expertise, or does it stop at the component that failed? A pattern of stopping at the component would suggest this framing isn't actually practiced, only endorsed. - If postmortems that explicitly ask "what didn't we know?" before "what broke?" don't surface different root causes than ones that don't, the reframing adds no analytical value. ## Maintenance - Last tended: 2026-08-16 - Next review: 2026-11-16 ## Source - [[3. Resources/Readwise/Full Document Contents/Articles/What “Project Hail Mary” Taught Me About Working in Tech]] — Adato Systems, part 4 of a four-part series.