Writing
Why enterprise AI should say UNKNOWN instead of guessing
Every system I build refuses to invent a fact. A gap gets marked UNKNOWN and filed as a numbered question. It sounds like a small design choice. It is the single rule the whole method rests on, and this is the argument for it.
The week that turns a guess into a fact
Here is the failure, mechanically. A helpful system is asked for a number it does not have. It produces a plausible one, because plausible is what these models are best at, and the number lands in a facts file at eleven at night. One week later that line is indistinguishable from every sourced line around it. Same font, same folder, same authority. Nobody remembers which entry was researched and which was inferred by a helpful machine, and then it gets cited into a document a partner receives.
Now the guess is a claim the company made. Not a model error, not a hallucination in a chat window that scrolled away: a commitment, in writing, with the company's name over it. That is the full cost of a plausible guess, and it is why fluency without grounding is the worst property a company system can have.
UNKNOWN is an answer, not an apology
So every system I ship holds one rule above the rest: when a fact cannot be sourced, the answer is UNKNOWN, written exactly like that, visibly, in the output. Not a soft hedge, not a guess with a disclaimer attached, and never silence. The gap is marked where a reader will see it and filed as a numbered question in the system's register, with the person who can actually answer it named as the owner.
The refusal has structure. Grounding runs against an explicit trust order: the approved library outranks the facts layer, and the facts layer outranks drafts, so the system always knows whether it is standing on rock. Anything found nowhere in that chain is, by definition, not the company's fact to state. A live example from my systems: a one-pager ships with two entries marked UNKNOWN and filed as questions 41 and 42, rather than shipping two invented numbers that would have read just as smoothly.
What the question register buys
The register is the part nobody expects to matter, and it changes the whole engagement. An unanswered intake field does not block a build and does not get guessed. It becomes a tracked item. Which means the client receives something better than send me whatever you have
: a finite, ranked list of the things only they can answer. That list gets worked down, and the packet actually comes back, because a person can finish a list in a way they can never finish a vague request.
There is a quieter benefit. Every UNKNOWN is a diagnostic of the knowledge layer itself. If the same question keeps surfacing, a file is missing or a routing rule is wrong, and the register is where that pattern becomes visible. A system that guesses smooths over its own gaps. A system that says UNKNOWN maps them.
An accurate gap is worth more than a confident error
The objection writes itself: does it not look weak, a system admitting ignorance in front of the room? The observed answer, from systems with 100+ daily users behind them, is the opposite. People do not adopt a tool they have to supervise. They adopt a colleague who says UNKNOWN in front of the CEO rather than guessing in private, because that behavior is exactly what makes the rest of the output sendable without re-checking.
Trust in these systems is not built by the answers that impress. It is built by the refusals that hold. The first confidently wrong answer a system gives is remembered longer than a hundred correct ones, and adoption dies from that memory: quietly, one user at a time, with nobody ever telling you the reason. UNKNOWN is how the first time never happens.
How to install the rule
Three mechanics, none of them exotic. First, one home per truth: every fact the system may state lives in an authority file, so can this be sourced
is a lookup rather than a judgment. Second, the trust order, written into the constitution the system reads first, so conflicts resolve the same way every time. Third, the register, with numbered questions and named owners, so a gap is a work item rather than an embarrassment. In the Company OS the rule is held by the Gates rather than by memory: an unsourced claim is a check that fails, not a style note.
And one guardrail over the humans, which is where the rule actually gets tested: when a deadline arrives and the number is still missing, the deliverable ships with the gap marked or it waits. The one thing it never does is ship with a plausible line where a fact should be, because a week later nobody will remember it was plausible instead of true.
The rule sits beside the other three that survived all four builds, and you can watch a live system apply it in the refusal demo.
The Shelf
- → From experimenting with AI to operating with itThe manifesto. Why buying AI produces ten private ways of working and no new company capability, and what changes when the system around the model gets built instead of another login getting issued.7 min read
- → How to build a company AI knowledge layerThe architecture under every Company Brain I ship: a constitution read first, a routing table instead of a crawl, one home per truth, and a folder tree where position is approval status.8 min read