What a Truth Gate Is and Why Our Marketing Has One

Every operation that documents itself accumulates the same quiet problem over time: a sentence gets written when it's true, and nothing ever goes back to check whether it still is. A status doc says a feature is live. A README warns about a bug that got fixed months ago. A pitch deck cites a metric that was accurate the day it was pulled and has drifted ever since. None of that is anyone lying on purpose. It's just what happens when a claim is written once, in prose, and never re-checked against reality.

We hit this hard enough, in enough places, on a single day of auditing our own documentation, that it became worth naming as a category of failure rather than a one-off mistake to fix and forget.

What we actually found

On one day of review, we found: a queue of pending review items that was actually a third resolved already, because nobody had re-checked it after they were resolved. A build status doc claiming "nothing exists yet" for a capability that had shipped hours earlier. A warning about an already-fixed bug, still sitting in an onboarding doc, telling new readers to worry about something that stopped being true. A framework-version claim that hadn't been checked against the actual dependency file in a long time. A port number cited in a memory doc that never actually existed in any real config.

None of these needed a human to be careless in the moment they were written. Every one of them needed only one thing to go wrong: a sentence that made a factual claim, with nothing in place to notice when the fact underneath it changed.

The fix: three classes of claim, and a rule for each

The discipline we built sorts every factual statement in our documentation into exactly one of three categories, because each one needs a different kind of honesty:

Generated claims are rendered directly from the real source — a script counts the actual rules in a config, or checks the actual version in a dependency file — and stamps the result into the doc. A human never hand-types these numbers. If the doc and the source ever disagree, that's not a judgment call; it's a mechanical drift check, and the fix is always "re-run the generator," never "edit the sentence by hand."

Asserted claims are still hand-written by a person, but they carry a fact a machine can verify independently — a port that should exist in an inventory, a branch that should still exist in git, a version number that should match a dependency file. The sentence stays prose. The check that keeps it honest lives separately, and runs on a schedule, so a stale assertion gets flagged instead of sitting quietly wrong for months.

Dated narrative is the honest exception: history, postmortems, "here's what I found and did on this date" write-ups. These are allowed to age — that's their nature — but only if they say so plainly, with a visible date, so nobody mistakes a snapshot of the past for a claim about right now.

The rule underneath all three: if a sentence describes something currently true — a port, a version, a status, a "this feature is live" claim — and someone could act on it being wrong, it has to be checked mechanically or dated honestly. It doesn't get to just sit there as unverified prose and hope nobody asks.

Why this governs marketing too, not just engineering docs

It would be easy to treat this as an internal engineering discipline that has nothing to do with what gets published publicly. We built it the other way on purpose: the same rule that keeps an internal status doc honest is the rule every piece of outward-facing copy in this launch has to clear before it goes out.

Concretely, that means every case study in this launch is checked against the actual state of the product it's describing, not against how we'd like it to be described — verified live URLs, verified feature lists, verified commit history, not a marketer's confident paraphrase. It means a quote from a customer doesn't get written by us and attributed to them; if we don't have a real quote yet, the space stays a visible placeholder rather than getting filled with something plausible-sounding. It means a feature that's still in build gets called "in build," not quietly implied to be live because "live" sounds better in a sentence. It means we don't cite a revenue number or a user count we haven't actually verified, no matter how good the sentence would read with one in it.

The uncomfortable part, said plainly

This standard costs something real. It means some of the most impressive-sounding claims we could make simply don't go out, because we can't verify them yet — not because they're false, necessarily, but because "probably true" and "checked" are different states, and only one of them clears the bar. It means a case study sometimes reads more modestly than a competitor's would, because theirs didn't have to survive the same check ours did.

We think that's the actual point, not a cost to minimize. A marketing claim that can't survive being checked against the real system it's describing isn't marketing — it's a promise nobody verified, made to someone who has no way to verify it themselves. The truth gate is what turns "trust us" into "here's what's actually true, and here's how you'd check." That second version is slower to write and harder to make sound exciting. It's also the only version that's still true a year from now, which is the only kind of claim worth making in the first place.