We built a review checklist for our own writing before we published anything. Ten checks, each one aimed at a way we worried a draft might go wrong. One of them was aimed at a bias we already knew we had: describing an organization's way of working as something you install, rather than something that's already there and usually just fragmented.
We ran that checklist against our first real post. It worked. And it also missed something, in a way that turned out to be more useful than if it had caught everything.
What the Checklist Caught the First Time
The first pass found three real problems.
One section reused phrasing close enough to an internal reference document that it counted as disclosing something we'd decided to keep private, even though it never named the source. We reworded it from scratch rather than paraphrase around the edges.
The closing line read: "Kernel applies these principles through research, software, and organizational engagements." Plural. We have one completed client engagement. The line implied a track record we don't have yet, so we cut it down to "research, software, and consulting," which is true and doesn't borrow credibility we haven't earned.
A third line pointed at an outside company's writing and argued that two teams landing on a similar answer independently was "a decent sign the shape is right." It read less like an observation and more like reaching for someone else's approval. We cut it. The point it was trying to support didn't need it.
Three findings, three fixes, all mechanical once named. We published.
What a Second Read Caught That the Checklist Didn't
One more read of the whole piece, not another run through the checklist, found the next problem.
The structural issue was that the post opened by telling the reader what the term meant before giving them any reason to care. It answered a question nobody had asked yet. Fixing that meant rewriting the opening entirely: four concrete scenes a reader might recognize, then the mechanism connecting them, then the reveal that they're one pattern, and only then the name.
While rewriting that opening, we went looking for a second problem we suspected was still there, the installation bias. We'd already corrected the core paragraph weeks earlier. That paragraph was fine.
It was everywhere else that wasn't.
The one-line summary at the top of the file said "build it." The closing sentence said we "have built the strongest systems." And two sentences in the middle set the capitalized term against a concrete artifact with nothing connecting them, the same move as saying something was installed, just without using the word.
Three separate recurrences. Same post. Same bias. None of them in the paragraph anyone had actually checked.
The Bias Lives in the Verb
At no point in any of this was the term itself wrong. The capitalization was correct everywhere. If a rule had only checked whether the noun was capitalized the right way, every one of those three sentences would have passed.
The bias wasn't in the noun. It was in the verb attached to it. "Build," "install," "have built," each one quietly claiming the thing didn't exist until we made it, regardless of whether we'd already written, elsewhere in the same document, that it did.
A rule that gets checked once, where the idea is first stated, will keep missing every place the idea gets implied again somewhere else. Bias doesn't stay where you defined it. It travels.
What We Changed
We added two checks to the list instead of just fixing the three sentences and moving on.
The first scans an entire piece, not just the paragraph that states the thesis, for "build," "install," "create," or "the answer" applied to the thing we mean, regardless of whether the capitalization around it is already correct. Correct capitalization was never the problem. The verb was.
The second checks that any piece introducing an unfamiliar term describes the thing concretely first, so the term arrives as an answer to a question the reader already has by the time it shows up, not as the opening line. This is the same fix that rewrote the post's structure, made into something that checks every future draft automatically instead of requiring someone to notice it again by hand.
Neither check came from a style guide or a book. Both came from watching our own writing fail a rule we'd already written, in one document, three times, and only catching it because someone happened to read the whole thing again.
Why a Rule You State Once Doesn't Hold
A rule you've written down once isn't a rule yet. It's a hypothesis. It only becomes durable once something other than a careful human re-read can catch it breaking, because careful re-reads don't scale and they don't happen every time.
The same is true of any rule that only gets checked where it was first written down. Someone still has to go looking for where it quietly isn't being followed anywhere else.
Read more about the methodology this checklist is meant to protect → How We Work