We Audited Our Own Case-Study Register and Found 2 Wrong Claims

Our case-study register is the source every first-party claim on this site has to trace back to. If a page here says something about our own builds, the register is where that sentence is supposed to come from — which makes the register the single most load-bearing document in the library, and the one nobody was re-reading against the systems it describes.

On 2026-08-21 it was checked against the code, and 2 of its claims were wrong [our data]. This is that record. It is a short incident with one uncomfortable rule attached.

What was the situation?

A register entry describing our auto-finance migration build — a live WordPress domain that got a static content layer in front of it — was written while the design document was the only artifact that existed [our data]. That is the normal order of events. The plan is written first, the entry is written from the plan, and the implementation then does whatever implementation does.

Nothing about that is negligent, and that is the part worth noticing. The document was accurate on the day it was written and wrong by the time it mattered, with no event in between that anyone would have logged.

What did the verification pass find?

Two defects, in two different classes. Both were corrected in the register on 2026-08-21 [our data].

The first is a material difference, not a wording difference. A router that tries the new origin first makes every URL on the domain depend on the new deployment behaving correctly; a router that defaults to the old origin limits the new layer's blast radius to a list someone wrote down. Those are opposite risk postures, and the register had recorded the wrong one. The mechanics of the router that actually runs are documented at adding a citable content layer to a live WordPress domain.

The second is smaller and more insidious. "About 15 minutes" reads like a stopwatch result. It was a number from a plan, and a number from a plan wearing a measurement's clothes is exactly the kind of claim this library refuses to publish from anyone else.

Did anything wrong get published?

No. The correction landed on 2026-08-21, and the scenario page describing that router was written afterwards, against the corrected record [our data]. The live page states the allowlist behavior, the GET and HEAD restriction, and the cutover figure explicitly labeled as a design target rather than a measurement.

We are stating that plainly because the alternative framing — a near miss narrated as a catch — would be its own small dishonesty. What happened is that a verification pass ran before the page did. If the order had been reversed, this page would be a correction notice instead of a process note.

How was the error actually found?

The record documents a verification pass against the deployed Worker source, dated 2026-08-21, and the correction that followed. It does not record who ran the pass, what prompted it, or whether anything in particular raised the suspicion.

So that is all this page will claim. Reconstructing a detection story — a reviewer who noticed an inconsistency, an alert that fired — would be a more satisfying page and an invented one, and inventing the interesting half of an incident is the specific failure this library exists to argue against. The general discipline of verifying against the source rather than against the document that describes the source is laid out in how we fact-audit a page.

Why does a first-party record drift toward the plan?

Because of the order the artifacts get created in, and because nothing corrects for it automatically. The sequence is always the same: a design document exists, a summary is written from it, code is written next, the code diverges from the design in a dozen small decisions nobody documents, and the summary keeps describing the design.

There is no moment in that sequence where anyone is wrong on purpose. The drift has a direction — always from what runs toward what was planned, never the reverse — which is what makes it correctable. If a record and a system disagree, it is safe to assume the record is the one that is out of date.

The other half of the problem is that first-party claims have no external check. A statistic from a published study can be verified by anyone; a claim about our own infrastructure can only be verified by us. Google's people-first content guidance asks whether content demonstrates first-hand expertise and whether a reader would feel they can trust it, and first-hand experience is only worth anything while it is accurate. The same document set's generative-AI optimization guide points at content quality rather than markup for exactly this reason.

What did we change?

Three rules, all cheap, none of them clever.

1. Verify against the deployed artifact. A claim about a system is checked against the code, config, or log that runs it — not against the document that proposed it. The register entry now names the file it was verified against and the date.
2. Label every duration as planned or measured. Any number that could be read as a stopwatch result carries which one it is. "Planned procedure length" is a perfectly good fact; it is just not the same fact as a measurement.
3. Re-read on a cadence, not on suspicion. Suspicion is what failed here — nobody suspected anything, because there was nothing to suspect. A record that only gets re-read when someone doubts it will never get re-read.

We have run this cadence once, on one register, so treat the rule as reasoning rather than as a track record. What we can report is the one pass and what it found.

What is the generalizable rule?

A first-party record decays toward the plan that produced it. If your own case studies, capability decks, or documentation describe systems you built, something has to re-read them against the artifacts on a schedule — otherwise the record slowly becomes a description of what you intended to build.

Against our own interest, since original first-party data is what we tell clients makes a content library defensible: this is the failure mode that comes with it. Published studies can be checked by any reader; our numbers cannot, so the burden shifts entirely onto our own verification, and a register nobody re-reads is a marketing document with dates in it. That argument, made in the direction we like better, is at original data as content strategy, and the case for publishing episodes like this one at all is at why we publish negative results.

The evidence discipline that all of this feeds — what may be claimed, with what marking, from which source — is the spine of our operator's guide to generative engine optimization.