On 7 September 2026 we found out why a way into the estate had never worked for the thing it was built for. Three rules stood in the path. Each was correct, and the connection died between them.
Review finds defects inside a part. This one lived between parts, where every piece passes inspection and only running the whole path shows the fault. It was the fifth of its kind that week.
Five instances, 3 to 7 September 2026. We hold it as an observation, not yet doctrine.
Every part passed
The tunnel is the most complete of five instances we recorded that week. In each, every component was checked and found correct, and the fault lived only in how they met.
-
A rule for one machine broke eight
A firewall rule added for one machine used a variable that only that machine defined. The rules for every machine live in one shared structure, and one undefined reference stops the whole of it rendering. Eight of nine machines could no longer apply their firewall, and the error said their rules were missing while the rules sat in the file. It happened twice, two days apart, and both times the change was verified on the one machine where it worked.
8 of 9 broken · twice -
A rename that looked exactly like a rename
A merged change showed a clean file rename, which is exactly what a correct file move looks like. The edit that gave the new name a meaning had never been staged, so three machines lost the path they had been reached through for two days.
Clean diff · 3 cut off -
The reply had no route
The monitoring machine could not collect metrics from three others. The router rule, both firewalls and the metrics service were each checked and correct. The request arrived fine. The answers went to a router that is not ours, which had no route back, and died there. A probe that reads blocked does not say which direction failed.
Every part correct · no reply -
The name on the cover
A document template plainly contained the company name, and it did not appear on the cover. Reading the source showed it was there. Extracting the text showed it was in the file. Only looking at the page showed white text on white paper, pushed past the edge of a blue band by a title that wrapped to two lines. The template we copied has the same defect and does not show it, because its titles fit on one line and the name lands inside the band by about 4mm. It was never robust, only lucky.
In the text · invisible -
The tunnel that never worked
Told in full below. A source-only rewrite, a forward rule and an access rule, each right on its own, and a path that had never worked.
A day · 2 wrong hypotheses
Three correct rules
The first rule sat on the machine where the operator’s second remote-access tunnel lands. It rewrote the source address of traffic leaving it, so that machines which did not know the tunnel could still answer. That was correct. It matched on source alone, though, so it also rewrote traffic that was only passing through on its way to the router.
The second rule, on the router, forwarded that traffic on. Correct.
The third rule, also on the router, decided what the operator could reach, and it matched on the tunnel’s addresses. Correct too. But by the time traffic arrived, its source was no longer a tunnel address. It was the far machine’s own. The access rule could never match, and nothing the tunnel was set up to reach had ever answered through it.
It never failed loudly. It hung, because the reply went to a machine that had never asked. It survived a full day of looking. What found it was reading the address translation the kernel had actually written for a live connection, not the rules that were meant to produce it.
Why reading cannot find these
Review reads a part. A reviewer looks at a change and asks whether it is right, and in every case above it was. The defect was not in any change. It was in what the change met: a variable’s scope on machines the diff never touched, a route on a different machine, a line wrapping on a page nobody rendered, an address rewritten one hop earlier.
The diff shows what changed. It cannot show what the change meets.
So the rule is blunt. If a change spans two owners, reading either one proves nothing. Run the path. This estate had written the same point down about routes a week earlier: a forward rule on the router and a route on the machine are two halves, and adding one without the other gives a rule that is correct, live, and inert.
What running the path looks like
Running the path is specific. For each of the five it means a different, concrete act.
- A shared change is checked across the whole group, not on the machine it was written for. The machine it was written for is the one place it cannot fail.
- A connection is tested in the direction it is used. Connect in, from somewhere else, and see whether the answer comes back.
- A document is checked by looking at the page. Not the source, and not the text the file contains.
- An address translation is read off a live connection. Three correct rules is what this fault looks like, so reading the rules again finds three correct rules.
Each fix went where the next build keeps it. The variables the shared structure had missed now have empty defaults, and its error message says that if most machines fail and one passes, the one that passes owns the missing variable. The translation rule gained a destination scope rather than being deleted, since the machines it was written for still need it. The cover now anchors its title block at the bottom, so a longer title can only grow upward.
What it cost
The tunnel cost a day and two wrong hypotheses, and it had never carried the traffic it was set up for. The shared firewall structure left eight of nine machines unable to apply their rules, twice. The rename cost three machines the path they were reached through. The company name would have been missing from the cover of every document whose title wraps to two lines.
None of these was visible in review, and all of them had been through it. Here one of us writes a change and the other merges it. The reading happened. It read correct things.
Where we might be wrong
Four of the five instances come from infrastructure: routers, firewalls, machines. That domain has an unusual number of interfaces between separately owned parts, each correct on its own, which is exactly the shape this lesson describes. Application code with cheap rollback and fast tests may not behave this way. There, reading a diff may genuinely find most defects.
The cover template is the one instance from outside infrastructure, and one document-rendering bug is not yet enough to settle it. What would settle it is one project in a different domain. If faults between parts still dominate there, the lesson is about building with an agent. If they do not, it belongs in an infrastructure playbook.
None of this is new
Martin Fowler opens his essay on continuous integration with a memory from early in his career: a warehouse of programmers who had finished writing their parts, whose “separate units were now being integrated together, and they had been integrating for several months”. The lesson he drew from it: “integrating the work of multiple developers is a long and unpredictable process”.
Continuous integration answers that by putting the parts together constantly and running the result, rather than reading each part and hoping. That is the same answer as above. What is different here is where the parts meet. In a program they meet when the code is built. In an estate they meet on a live network, or at the next boot, or on a rendered page. No pipeline here runs those paths yet; each check above was run by a person. Continuous integration is planned for this estate, and until it runs it is a promise, not a practice.