Entry 014 — Seven gates passed fifty of fifty, and none fetched the one page the message exists to send a person to

Theory — the hypothesis held before the instruments answered

“The release gate has seven assertions and it fetches things over the network. A message it passes is a message a recipient can act on.”

Date — introduced 2026-09-09, detected 2026-09-10, cured the same day.

Symptom

Seventy-five businesses received an email whose entire purpose was to show them one page: a recording of what an AI helper saw when it visited their website. Every one of those links returned a 404. The page did not load, for anybody, from the first message onward.

  tranche one   50 links  ->  50 x 404
  tranche two   25 links  ->  25 x 404      (halted mid-send)
  total         75 links  ->  75 x 404 · 0 x 200

Nothing about the send looked wrong while it was happening. The release gate passed fifty of fifty, twice. The messages were correct email: right headers, right copy, right images.

Diagnosis

Two separate faults, arriving together.

The link was keyed wrong. Each business has two identifiers. One is public — the business’s own id, and it is what the email prints. The other is internal — the id of the stored document, which for this campaign is a signature computed from the business id and the recipient’s address. The page looked records up by the internal id only. The email linked by the public one. Those never matched, so 41 of the 75 had a page that was real and unreachable.

Thirty-four had no page at all. They were never created. Fixing the key alone would have turned 41 links green and left 34 businesses on a dead link, which is the trap worth naming: a repair that makes most of a number move is the easiest kind to stop halfway.

One sentence in the code carried the whole thing. It said a record id is a business id and is also the document id. It is not, and had never been. Everything downstream was built on it.

Why the gates did not see it

The gate fetched the icons and asserted they loaded. It never fetched the recording link.

Seven gates passed fifty of fifty and none fetched the one page the message exists to send a person to.

That is the finding, and it is not that the gate was weak. It was doing real network work on every message. A gate that fetches something is not a gate that fetches the right thing, and from the outside those two produce the same green.

Cure

Four parts, and the rule was all four or none.

1. The page now resolves a business by either id — the public one it is linked by, or the internal one of the document. Every link already in an inbox works, unchanged, and no email had to be reissued. That mattered: 75 messages had already been sent and none can be recalled.
2. The 34 missing pages were built from the same crawl evidence the emails were written from. The evidence id printed in each message was checked against the record used to build its page: 34 of 34 agree, and every character count the email published matches the page’s.
3. The release gate now fetches the recording link exactly as printed in the message, and refuses on anything that is not a 200 carrying that recipient’s own business name. A 200 rendering somebody else’s recording is the failure this incident is about, not a cure for it.
4. The message builder refuses earlier still: it will not render a link to a record with no page.

The new checks ship with their own failures proven rather than described. The controls plant a missing page and a wrong-name page and watch both get refused, and a correct page raises nothing — because a check that only ever fails proves as little as one that only ever passes.

What we are keeping

An unreachable page holds the release. It does not pass. A timeout, a refused connection, a certificate error: none of those is a working link, and silence must never be the same answer as success.

And the smaller one, which is really the same lesson: the 75 already sent cannot be unsent. Fixing the page does not undo the week those businesses spent with a link that went nowhere.