The Resolution Fallacy

The assumption that systems return to a fixed state after intervention. When the root cause is a probability distribution - not a bug - there is no "resolved," only "currently within acceptable drift."

Why It Happens

Every incident response process, ticket system, and budget line assumes failure is an event that can be closed. Find bug. Patch bug. Mark resolved. Move on. This model worked for deterministic systems where the same input produces the same output. Probabilistic systems don't fail in events - they drift continuously.

Three Properties

1. Event blindness. Tools built for events can't detect states. Smoke detectors find fires but not oxygen displacement. Every monitoring system in production is a smoke detector deployed in a room slowly losing oxygen.

2. Resolution theater. The ticket says "resolved." The system is still drifting. Marking something closed doesn't stop the distribution from shifting - it stops you from watching it shift. Resolution is the bureaucratic version of the Ignorance Dividend.

3. Budget mismatch. "Remediation" is a project with an end date. "Continuous observation" is an operation without one. Nobody's spreadsheet has a line for vigil.

The Fix / Implication

Stop building tools that assume resolution. Build tools that assume drift. Monitor rates of change, not states. Track the delta between consecutive measurements, not whether the last measurement was "good." The question isn't "is this system working?" but "is this system working differently than it was yesterday?"