Last week's post was about a quiz that showed a visitor one score on screen and a different one in their inbox. Before we published it, we found that the draft had got the bug's own history wrong. This week we fixed the process that let that happen, and a second one just like it.
The backstory that was never checked
The draft explained how the quiz bug came about: it said the server's scoring formula arrived later than the page that needed it, as if the page had shipped first and the real calculation had been bolted on afterwards. It read well. It also had the order backwards.
Running the actual commit history against the files the fix touched showed the opposite. The server's scoring had existed well before the page redesign that introduced the bug. The bug was never "the real formula arrived late." It was "a new page needed a number to show immediately and used the wrong one while the real one already existed elsewhere." A different story, and a different lesson, hiding behind a sentence that merely sounded plausible.
Nobody checked, because nothing about the sentence looked wrong. It was confident, specific and in the right tense. A plausible sentence and a true one are not the same thing, and a draft cannot tell you which it wrote. We caught this one by hand before it went out. We do not get that lucky by default.
The fix was to stop trusting the narration and start requiring the receipt. Our drafting brief now says: before stating how a problem came about, run the project's own history against the exact files the fix touched, and write down only what that history shows. If it does not settle the question, the backstory gets left out rather than guessed at. The rule exists because of this one sentence, and it is written into the brief itself so the next draft cannot quietly skip it.
A title nobody would have seen anyway
The second fix was duller and just as real. Our site already clamps an overlong page title or description at the nearest word boundary before it reaches a search result, because a July audit found roughly fifty of our sixty pages carrying a description past the length a search snippet actually shows, and about fifteen titles running well past it too. That clamp has existed for months. It protects the site. It never protected this weekly routine's own output, because the two checks were built separately and the newer one was never taught the older one's limits.
So four of our own build-notes posts had gone out with a search listing their intended headline would be cut off in, mid-word, with nobody deciding where the cut should fall. The content on the page was fine. What a reader would actually see in Google before clicking was not the title we wrote. We added the same length checks our drafting checklist already runs for banned terms and currency figures, matching the exact budget the rest of the site enforces, and gave those four older posts the shorter alternate title and description the rest of the site already relies on.
What both bugs were actually about
Neither of these was a writing problem. Both were a step that stated something as settled when nobody had checked it against the record that would settle it. One sentence described causation it had not verified. One frontmatter field described a length it had not measured against the limit that applied to it. In both cases the fix was the same shape: move the check to before publication, and make it automatic enough that skipping it is not an option on a day someone is in a hurry.
If any part of your own business publishes content, whether that is a founder writing LinkedIn posts, a team running a content calendar, or a model drafting your SEO content, the question worth asking is not whether the writing reads well. It is what, in that piece, was stated as fact without anyone checking it against something that could confirm or deny it. A backstory nobody verified and a headline nobody measured fail the same way: quietly, and only to the reader who was paying closer attention than the person who wrote it.
This sits squarely in the Signal pillar of the Hexagram: what you publish and whether it says what you think it says once it leaves your hands. We wrote about the earlier half of this same routine in how we built the routine writing this post, and the bug whose backstory we got wrong is the subject of the quiz that said one score and the email said another.
A draft that reads well has told you nothing about whether it is true. That is what the check is for.
If you want a clear-eyed look at what your own content operation is publishing unchecked, the Hexagram Diagnostic is a free place to start.
