FrameworkLevel 3 · ContextLevel 5 · Admissibility
Right Is Not Fluent
Two completely different guarantees you can ask of an AI system, routinely conflated. More context makes a fluent system more convincingly fluent; it does not make it right.
The shape
There are two completely different guarantees you can ask of an AI system, and almost everyone conflates them:
- Fluent: the output reads well, sounds confident, and has the right shape. This is the default, and it's a trap — a fluent system performs knowing whether or not it actually knows.
- Right: every claim the system makes decomposes into parts that each individually check out, all the way down. If the chain doesn't close, the claim doesn't ship. A right system doesn't try not to be wrong; it is structurally unable to admit a claim it can't compose from validated pieces.
The hinge between them is typed structure. A raw string can mean anything, so a system that only holds strings can only guess. The moment a thing is typed — you've declared what it is, what it requires, what it connects to — the system can check whether a claim about it actually holds, and refuse it when it doesn't. Constraints aren't a cage here; they're the only thing that makes "right" even definable.
Why it matters
Your AI hallucinates not because it's broken but because its outputs are unconstrained: nothing in the system checks whether what it said composes from things that are real. People try to fix this with more context — more documents, bigger windows, more RAG. It doesn't work, because reading is not the same as understanding compositionally. You can stuff fifty pages of procedure into the context and the system will still confidently contradict page 23, because it has words about the domain, not a validated model of the domain that it cannot contradict.
The reframe is brutal and clarifying: the question is never "did it sound right?" It's "could a wrong answer here cost real money?" If yes, fluent is not enough — you need a system where wrong claims can't be admitted, not one where you hope they won't be generated. That's a different category of system, and most never become it, because it costs speed and it costs the freedom to throw any string at the problem.
How to think with it
- For any AI output you depend on, ask: is this fluent, or is it right? Could I trace every claim back to something validated, or am I trusting that it sounds plausible?
- Notice when "give it more context" is being proposed as the fix. More context makes a fluent system more convincingly fluent — it does not make it right. Different problem, different fix.
- Decide honestly whether your use case needs right at all. A lot don't — fluent is fine for a FAQ bot. The discipline is knowing which one your stakes demand, and not paying for the expensive guarantee where the cheap one suffices.
- Where you do need right: the unit of trust is the composition, not the sentence. The question becomes "does this decompose into validated parts?" — at every depth, not just the top.
Honest caveat. What this doesn't cover: the apparatus that does the composing and the refusing — how a claim is decomposed and checked at every depth, and what the validator says back to make the model repair it.
Distilled from: admissibility engineering · l5 admissibility · admissibility · composition · sanctot example