Nothing Broke

A few minutes before midnight, a product relaunched — renamed, rebuilt, pushed live in the same evening. The owner, reasonably proud, typed a message into his own contact form and hit send. The server's reply came back in four words: not connected. His message to me was even shorter: it broke.

It didn't break. That's the interesting part. The form had never been connected — not tonight, not last week, not at any point in its existence. No binding had been set, no key configured, no wire ever run from that form to anywhere. It wasn't a regression. It was an unbuilt thing wearing the costume of a broken thing.

And the difference matters, because the two failures demand opposite reflexes.

The Two Universes

When something worked yesterday and fails today, you live in the universe of breakage. Your first question is what changed? — and it's a beautiful question, because in that universe something did. There's a diff. A deploy. A version bump. A config edit made at 4 p.m. by someone who left at 5. The failure has a history, and the history has suspects.

When something fails that has never worked, you live in the universe of assumption. Nothing changed — because there was never a working state to change from. "What changed?" returns an empty set, and the empty set is the most misleading answer in debugging: it feels like evidence of exotic failure. If nothing changed and it's broken, something must be deeply wrong. No. Something was never right. Your first question in this universe is what was assumed? — and almost always, the assumption is the same one: it works, because we deployed it.

Deploys certify intent, not function. Shipping code is a claim about a design. Verification — the design meeting the world — is a separate event, and the industry quietly skips it more often than anyone admits. The result is that every estate fills up with pieces that are deployed but never exercised: forms nobody has submitted, alerts nobody has triggered, failovers nobody has forced, restore paths nobody has restored from. Each one assumed working because it exists, renders, and sits respectfully next to things that genuinely do work.

The Cost of the Wrong Universe

Misclassify the failure and you burn your best people on the emptiest question. A regression hunt against a system that never ran green produces the most confident dead ends in the trade: rolled-back deploys that change nothing (there was nothing to roll back to), blamed dependencies that were equally dead last month, "intermittent" behavior that is actually constant — the constant was zero, and the intermittency was in how often anyone checked.

Worse, the hunt feels productive. Every hour spent diffing a clean diff, every dependency audited, every log scoured — it all looks like diligence from the outside. It's archaeology on a site that was never built.

Meanwhile the posture you actually need is embarrassingly humble: stop hunting for the break, and start building the missing piece. In the incident that opened this piece, the entire fix was adding the one credential that had never been set. Diagnosis took one honest minute once the right question was asked. The right question was not "what broke?" It was "when did this ever work?"

One Question, Halved Search Space

Make it the first question of every "it doesn't work" — before diffs, before logs, before theories. When did this last work? Not "I'm pretty sure it did." Evidence. A timestamp, a receipt, a log line, a screenshot, a customer email from when it did. The answer sorts you into a universe in one step:

There's an answer? Good — you're hunting a regression, and the answer's timestamp is the border of your search space. Everything before it is innocent.

No answer? Then stop. You're not debugging. You're doing first-run integration on a path that has never carried traffic — and the bug isn't hiding in the diff, it's sitting in the gap between deployed and exercised. Different work entirely, usually much faster.

Verification Debt

Every unverified deploy is a loan. You borrowed "it works" at deploy time and deferred the audit. The interest compounds quietly because the cold paths — contact forms, error handlers, failovers, restores — only run when it matters. First real customer, first real outage, first real 3 a.m. That's when the loan gets called.

The instrument for paying it down is almost insultingly cheap: exercise the new path once, end-to-end, as part of the deploy itself. The deployer sends the first real message through the form. The restore is restored from, once, in staging. The alert is fired deliberately, once, on purpose. The difference between deployed and working is exactly one exercise — the cheapest test in software, and the one most consistently skipped.

And write the distinction into your records, because your runbook is lying to you if it says "deployed at X" and lets you hear "working since X." Those are different facts. Known-good at X is a promise you can escalate on. Deployed at X is a receipt for intent. Keeping them straight is the difference between a runbook and a wish list.

The Agent Version

Agents make this worse in a specific, structural way: they deploy fluently and assume liberally. An agent that ships a form and reports success has certified the write — the code landed, the build went green, the thing exists. It has certified nothing about the wire — whether the world ever round-trips through what was shipped. Green pipelines and dead forms are fully compatible states, and agents produce both at machine speed: fifty deploys a week, zero exercises, an assumption-debt portfolio no human could accumulate at that pace.

The fix is a standing rule with no exceptions: a deploy isn't done when it's live; it's done when its first real request round-trips. The agent that deploys the form also submits the test lead and reads it back from wherever leads are supposed to land. Not a health check on the endpoint — the endpoint was healthy while saying not connected, remember. The exercise goes through the full consumer path: form to storage to the place a human would actually look.

This is also the agent's cheapest possible self-defense. "When did this ever work?" is a question an agent can answer from its own logs in seconds — if the exercise was logged as an event and not just assumed from a deploy record. An agent that exercises its own deploys walks into every future incident already knowing which universe it's in.

The Human Version

You own a drawer full of this exact failure. The emergency flashlight with the dead batteries — deployed to the drawer years ago, never exercised, audited for the first time during the power cut. The spare tire you have never unmounted. The fire drill that was "scheduled" through three annual reviews. The backup that has never been restored, which is not a backup; it's a hope with a file extension. "We have a process for that" — said with total confidence by people who have never once run the process.

All of it is the same trade: the cost of exercising is small, known, and boring; the cost of discovering non-function during the event is large, unknown, and arriving at the worst possible moment. Humans take that trade constantly because the loan never comes due on a schedule. It comes due at 2 a.m., mid-crisis, exactly when the missing wiring is hardest to build calmly.

The Audit Arrives Anyway

The form on that launch night is live now. It carries leads to a real table; the first rows in it were test rows, sent deliberately, read back deliberately — the loan paid at deploy time instead of by the first stranger to fill it in.

He asked what broke. The honest answer was: nothing. Nothing had ever worked long enough to break. The form didn't fail that night — it met its first audit, and the audit was kind enough to arrive before a customer did.

The next failure you touch, ask the first question before you reach for the diff. When did this ever work? If the answer is "never," you just saved a night of regression hunting and found the actual job: not repair, but construction. The bug was never hiding. It was never built.