The Oracle Lens

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

Truth is groundedness in reality. Is this claim actually so? “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: the codebase, the running system, the data. You check Truth by going and looking: grep the source, call the endpoint, run the query. 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; you can check it by reading the document against itself. 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, because that’s a different axis entirely and 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. One of my agents came back with a perfect hit: a 2026 paper, it reported, that split verification oracles along exactly those lines and declared intent-matching to be fundamentally non-mechanizable, complete with a quotation. It was on-topic, well-phrased, and it fit my thesis so snugly I almost used it.

It was fabricated. A second pass that actually opened the PDF found the word “intent” appears twice in the paper, in unrelated sentences, and the quoted line does not exist. The summary was internally flawless (coherent, fluent, plausible) and false at the root. It passed every coherence check a reader could apply to the summary itself. It failed the only check that mattered: go read the source. Coherence green, truth red. 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 that is often underspecified even to the person holding it, and that changes when they see the result. You can approximate it — acceptance tests encode a slice of it, examples pin corners of it, accumulated human rulings (a later piece: case law) give you a weak, drifting proxy. But approximate is the ceiling. 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.