2 · FAUCET FIXES

THE CITY

A stain appears on a third-floor ceiling. A crew goes up, cuts out the ruined plaster, replaces it, sands, repaints. The work is genuinely good — better than the original. Six weeks later the same stain appears on the ceiling next door. Same crew, same quality, same result. Then the floor below. Then the building across the courtyard.

There is a pipe in the wall behind all four ceilings. Nobody was ever asked about the pipe. Every repair was correct, and the city is now four repairs poorer and still owns the pipe.

Cities repair ceilings instead of pipes for a reason that has nothing to do with intelligence. The ceiling is what someone complained about. It is visible, it is bounded, and when the crew leaves you can stand in the room and see that it is fixed. The pipe is invisible on the day it is repaired and pays out only in leaks that never happen — the hardest work in the world to get credit for.

And the fourth leak is not four times the cost of the first. Each successful patch teaches the city that patching is what one does about stains. By the fourth ceiling, the pipe has stopped being a problem anybody hunts. It has become the weather.

THE TELL

• A problem you remember being fixed returns months later wearing a different costume.
• You read a new complaint and think "haven't we seen this?" — and nobody can tell you where.
• One area of your product keeps needing quick fixes, and every one of them works.
• You are the one who spots it, by eye, looking at a screen.
• You ask "what changed so this can't happen again?" and the answer describes the repair rather than a gate.

FROM THE FIELD

Four costumes. The first city takes in data files from several outside partners, and each partner's file is read by its own reader. One reader had a year frozen into it — a date written in as a fixed value instead of read from the file — and it produced wrong results at a season boundary. It was found and killed (the first city's ledger, DL-078). Then the same shape was found alive in a second partner's reader, and killed (DL-083). Then a third, which the ledger recorded in its own words as "the pinned-year class in a third costume" (DL-085). Then a fourth. Only after the fourth did the city install a guard that fails the entire class wherever it appears (DL-092).

The number is the story. This is not one bug and a fix. It is the same defect shape, found and killed four separate times, by a city repairing it correctly on every occasion. Three of those repairs were faucets. The fourth arrived with plumbing.

Three surfaces, three days. A missing short-circuit — a check that should have stopped a read before it went further — surfaced in three different places over three days. On the third, the record stopped treating them as three bugs: "This is the 2026-08-10 incident class, not a new bug." The repair went in "at the source layer, not the faucets" (the first city's ledger, DL-103).

That same ruling is worth reading for its other half, because it guards the opposite error. It also declared one missing guard deliberate and load-bearing: a place where the city does not catch a failure on purpose, so a genuine misconfiguration fails loudly instead of being quietly swallowed (the first city's ledger, DL-103). Absence is not always oversight. A crew that patches every gap it finds will eventually silence the alarms.

The ruling that did not travel. The first city ruled, in writing, for one part of the city: never trust a single arbitrary record when several exist. Later the identical mistake appeared in a different part, produced a status badge showing a wrong answer, and was caught by the founder looking at it. The ledger's own words: "THIS IS THE DL-019 'ZING BUG' CLASS RECURRING" (the first city's ledger, DL-058).

Read the catch mechanism, not the bug. A written ruling already existed; what it lacked was legs. What reached the second location was the owner's eye — which is not a control, and does not scale past the number of screens one person looks at.

Two dead theories in one day. This receipt is the builder's own scar and it belongs on the page. A set of automated checks began failing unpredictably — six occurrences in a single day. Two theories of the cause were written down, published, and acted on. Both were wrong. The incident log strikes them by name: "Both prior theories in this log are dead and are struck as diagnosis" (the first city's incident log, R2.4). The true cause, when finally captured, was that too many jobs were competing for too few hands, so some never got a turn.

Faucet fixing is not only a property of repairs. A diagnosis can be a faucet fix too — twice here, in writing, before anyone reached the pipe.

WHY AI WORKERS DO THIS

An AI worker is handed a symptom and judged on whether the symptom stops. It has no memory of the previous three times a cousin of this symptom appeared, so a pattern that exists only across sessions is invisible to it — not overlooked, unavailable. Nothing in "fix this screen" asks "where else does this shape live?", and the worker will not raise the question for you.

Neither will it tell you the honest fix is bigger than the one you requested, because that is a refusal. So the cheapest correct-looking repair wins every time, forever — and each win makes the next one likelier, on both sides of the desk.

THE COUNTERMEASURE

The ordinance, in these words:

"When you fix something, name the class of defect, not the instance. Then search the whole city for every other place that class could live, and show me that list before you touch anything. Ship the fix together with the thing that makes the class impossible to reintroduce — and write the class and its date into the record, so the next worker inherits the ruling and not just the repair."

The mayor's half is one question, asked every single time: "What changed so that this class of thing cannot happen again?" A description of the repair is not an answer. A named gate is.

Two honest limits. A class-wide guard costs more than a patch, sometimes much more — the first city paid for its guard on the fourth occurrence, not the first (the first city's ledger, DL-092), and pretending the discipline is free is how it gets skipped. And a guard covers only the classes you have already met. It does nothing about the shape that has not bitten you yet.

ASK YOUR OWN CITY

1. Think of the last change that broke something unrelated. What changed so that whole class of thing cannot happen again? (A description of the repair is not an answer.)
2. Take the last ten bug fixes. How many shipped with a check that would have caught the bug? Ask for the list, by name.
3. Your last outage or bad day: what happened, how long, who found out — and what changed afterward?
4. What is the workaround everyone on your team knows about and nobody has written down?
5. When an automated check blocks a change, does work stop — or does someone route around it? Ask for the last example of the route around.