In the last piece I said a specification deserves a compiler: a gate that fails when the input is wrong. That sounds clean until you try to build one, because you immediately hit a question the word "wrong" was hiding: wrong how?
Verification is not one thing. When you check a spec, or a plan, or a chunk of generated code, you are actually asking up to three different questions that feel the same and are not.
Conflating them is the most common mistake I see in AI-for-products tooling, including in tools that are otherwise very good. So before any gate, the lens. There are three axes, and they are orthogonal.
Truth, Coherence, Intent
| Axis | The question | What you check it against | How you check it |
|---|---|---|---|
| Truth | Is this claim actually so? | The world outside the document — codebase, running system, data | Go and look: grep the source, call the endpoint, run the query |
| Coherence | Does this hang together? | The document itself | Read it against itself: contradictions, gaps, terms used two ways |
| Intent | Is this the right thing? | A human's head | No mechanical check exists |
Truth is groundedness in reality. "The API returns this field." "This table has a status column." "The consumer can tolerate the extra parameter."
Each is true or false against a world that exists independently of the document. Truth has an external referent, which is exactly why it's the most mechanizable of the three.
Coherence is internal consistency. Does the document contradict itself? Are there gaps — behavior specified for some inputs and silent for others? Is the same term used two ways?
Coherence needs no world outside the document. This is the axis most spec tooling has actually reached: when Kiro flags an ambiguous sentence or two requirements that can't both hold, or when Spec Kit's checklist asks whether every case is covered, that's a coherence oracle. It's genuinely useful and I don't want to undersell it.
Intent is the match to what was actually wanted. Not "is this consistent" and not "is this true" — "is this the right thing."
A spec can be flawlessly coherent and perfectly grounded in reality and still describe a feature nobody needed, or the wrong feature, or the right feature with a subtly wrong default that only the person who asked would recognize as wrong. Intent lives in a human's head. It has no external referent you can grep and no internal test the document can pass.
The reason to name all three is that they come apart. That's the whole utility of the lens.
They pull apart, and that's the point
A spec can be coherent and false. It hangs together beautifully, every requirement consistent with every other, and it's built on a claim about the system that isn't true. Nothing internal will catch it; the document is at peace with itself. Only a truth check, reaching outside the document, catches it.
A spec can be true and incoherent. Every individual claim checks out against the codebase, but two requirements quietly contradict each other, or half the input space is unspecified. Grounding passes claim by claim; coherence fails at the seams.
And a spec can be true, coherent, and wrong: the hardest case. It lies about nothing, contradicts nothing, and describes something other than what was wanted. No mechanical oracle catches this, because there's nothing mechanical to check it against.
Here's the tidy real-world proof that these axes are separable rather than a philosopher's distinction: look at where the industry stopped.
Everyone who climbed to the spec layer (Kiro, Spec Kit) built a coherence oracle and planted a flag. They can tell you your spec contradicts itself. Not one of them can tell you your spec is lying about the API — that's a different axis entirely, and it needs different machinery: something that leaves the document and goes to look.
The coherence gate and the truth gate are not the same gate at different strengths. They're different gates. The market accidentally ran the experiment and confirmed the lens.
A live example: coherence without truth
I'll give you one from the making of this very series, because it's the cleanest illustration I have and it happened to me last week.
I was researching whether anyone had already published a Truth/Coherence/Intent-style taxonomy.
What the agent reported. A 2026 paper that split verification oracles along exactly those lines and declared intent-matching to be fundamentally non-mechanizable — complete with a quotation. On-topic, well-phrased, and it fit my thesis so snugly I almost used it.
What a second pass found. The word "intent" appears twice in the paper, in unrelated sentences. The quoted line does not exist. The citation was fabricated.
Coherence: green. The summary was flawless — fluent, plausible, internally consistent. It passed every check a reader could apply to the summary itself.
Truth: red. It failed the only check that mattered: go read the source.
If I had a coherence gate and mistook it for a truth gate, that fabrication would be a citation in this article right now.
That is the entire argument for the lens in one anecdote. The dangerous errors are not the incoherent ones — those look wrong. The dangerous errors are the coherent-but-false ones, because they look right, and only an oracle pointed at the world rather than at the document will stop them.
The strength gradient — and the axis you can't mechanize
The three axes don't just differ in kind; they differ in how mechanizable they are, and that ordering should drive where you spend effort.
Truth is the most mechanizable. It has an external referent, so you can automate the check: grep, compile, execute, query. Build the hardest, most automatic gate here. This is where a spec compiler earns its keep, and, per the market, where the least has been built.
Coherence is partly mechanizable. Consistency and completeness checks can be automated to a real degree, and LLMs are decent at flagging contradictions. It has diminishing returns but it's tractable. The field is already here.
Intent is not mechanically oracle-able, and pretending otherwise is the trap. There is no external referent and no internal test. The ground truth is a state of mind — often underspecified even to the person holding it, and it changes when they see the result.
You can approximate it: acceptance tests encode a slice, examples pin the corners, accumulated human rulings (a later piece: case law) give you a weak, drifting proxy. But approximate is the ceiling.
So the honest engineering move is not to fake an Intent oracle with a confident LLM judge. It's to name Intent as the axis that requires a human, put the person exactly there, and mechanize Truth and Coherence hard enough that the human's scarce attention is spent only on the question no machine can answer.
That is what the lens buys you. Not a new gate — a way to know, for every gate you build, which of the three questions it actually answers.
So you never again let a coherence check stand guard over a truth-shaped hole, or let a machine pretend to hold the one gate that was always yours to hold.
Coming later in the series: the truth gate itself — grounding a specification against reality, and why the interesting failures are about layers, not lies.
Top comments (0)