You pay twice

Unverified documentation costs you twice. It costs you before release, in rewrites nobody budgeted for, and again after release, when your customers become your QA. It is the same missing check both times, running on two different clocks.

The first bill

A typical new page goes through the same cycle every time. Engineers describe what they remember, the writer drafts from that, QA finds an edge case, beta users ask a question the page does not answer, and the page is rewritten. Each pass feels like new work because the original source was a conversation, when the merge, the ticket, and the running system were all sitting there the whole time.

That bill is internal, and it is paid in writer hours, engineer review time, and a launch that waits on documentation. It rarely appears as a line item anywhere.

The second bill

The second bill comes from the same missing step, except that it is now paid in public. A single omitted sentence tends to escalate on a predictable schedule:

• On day 1, nobody has hit it yet.
• By day 5, support has spent half an hour explaining what the page left out.
• By day 12, an engineer has been pulled off other work to confirm the answer.
• By day 20, it has become a tracked issue with a priority attached.
• By day 35, the page is being revised everywhere it was reused.

I will not invent a payback period for you, because the numbers depend on your product. The shape, though, is stable: an error caught on merge day is a page edit, and the same error on day 35 is an incident.

Who pays which part

The two bills land on different desks, which is a large part of why neither gets fixed. Organizations notice the second bill, because it shows up in support volume and customer satisfaction scores, and they rarely see the first at all. Writers live inside the first bill and are blamed for the second. Developers and QA receive the day-12 escalation over a sentence they never owned.

The gap

Nothing in the default toolchain compares what actually merged against what the published page names, and nothing does it before the release is tagged. Vendor drafters read one system at a time. Linters read a word list. Test suites read the binary. None of them is positioned to notice that the three descriptions of a release have drifted apart.

How to bridge it once

Start from the merge rather than from the meeting.

Take a single release, or a thirty-day window, and ask three questions. What changed in the product? What changed in the documentation? Where do those two lists fail to overlap? Answering them is a matter of matching identifiers between systems, which means it uses no AI model and contains nothing that needs a long security review before a pilot can start.

I ran exactly that comparison against nine public repositories. The interesting result was that there was no catastrophe to report, because these are well-run projects. The value was not in finding disaster. It was in replacing an argument about documentation quality with a measurement that a skeptic can re-run and check.