Scott Cohen, CEO, October 2026

Every rule depends on facts. Each one is a claim the document has to answer, and oftentimes the document doesn’t. What does your verification system do then? It is the first question to ask of any tool that claims to verify LLM outputs.

This is the question that sorts verification vendors fastest, because there are only three possible behaviors and two of them are bad:

Almost nothing in this market does the third. Jaxon’s DSAIL^® (Domain-Specific AI Language) was built to, treating uncertainty as an explicit and governed outcome. With DSAIL, when a document is missing a fact a rule depends on, the system can return UNKNOWN instead of guessing.

Why AI hallucinations survive RAG and LLM-as-a-judge

A large language model (LLM) is a guessing machine. Ask it whether a file meets a rule and it gives the most likely answer, whether or not the file contains what the rule needs.

Retrieval-augmented generation, or RAG, was supposed to fix that by handing the model passages from your documents before it answers. The trouble is what retrieval looks for: text that resembles the question. Resembling the question and answering it are different things, and a typical retrieval step returns its top matches whether or not any of them contains the fact. The model gets a handful of close matches and treats them as evidence. RAG improves what the model reads, but leaves how it decides untouched.

Using an LLM as a judge, the most common way to check another model’s work, runs into the same problem. The judge is a guessing machine too. When the document is silent, it gives its most likely verdict, the same way the first model did. Stacking one guessing machine on top of another gets you two guesses.

Nothing makes an LLM hedge reliably, and once its output feeds an automated workflow, a hedge usually gets collapsed into a yes-or-no answer anyway. Run the same file again and you may get the opposite answer.

Stacking one guessing machine on top of another gets you two guesses.

We know the failure mode is real because we measured it.

The benchmark found something worse than wrong answers

Jaxon ran leading frontier models three ways: (1) with RAG and a tuned prompt, (2) with the same setup plus a second model acting as judge, and (3) with DSAIL enforcing the rules. Same models. Same documents. The only variable was the setup around them. With a tuned prompt, the models got about a third of their answers wrong, and neither RAG nor an LLM judge raised the accuracy. With DSAIL, the strongest models got every rule right, every time.

The surprise was what kind of wrong answers the models gave without DSAIL. Most of them were a TRUE or a FALSE where the right answer was UNKNOWN. The document didn’t contain the fact the rule needed, and the models answered anyway, with the same confidence as answers the document backed up.

Full methodology and results are in our benchmark post.

UNKNOWN is a verdict, not a fallback

Every DSAIL rule returns one of three verdicts: TRUE, FALSE, or UNKNOWN. Each one comes back as structured JSON with a cryptographically signed verification token.

That third verdict carries information of its own. It records that the rule was applied and the evidence didn’t reach it. A system that can only say yes or no throws that away at the moment it matters most, before the decision ships and long before an examiner asks about it.

Two other places UNKNOWN does real work:

Judgment-heavy criteria. A rule that reads as a single subjective question rarely needs to be encoded as one. The checkable conditions surrounding the judgment get broken into explicit claims your own experts author from your internal procedures. What decomposition can’t reach returns UNKNOWN by design.

Conflicts of authority. When two governing sources collide and your encoded hierarchy doesn’t resolve which one wins, DSAIL surfaces the contradiction and names both rules rather than quietly picking a side.

Silence means what your rules say it means

Some silence is an answer. If a rule asks whether a document states something and the document doesn’t, that’s a fact about the document, and the claim comes back FALSE. Other silence settles nothing. If a rule asks whether something happened, a document that never mentions it hasn’t answered the question, and the claim stays UNKNOWN.

DSAIL lets rule authors declare which reading each claim takes, so a silent document gets the same treatment on every run. When a claim’s wording could go either way, the platform flags it so an author can settle the reading before it reaches production.

You decide what UNKNOWN does

What happens to an UNKNOWN is a choice you make in advance. Every rule carries a completion policy, and there are three: (1) neutral, the default, leaves the result UNKNOWN; (2) pessimistic treats it as FALSE; (3) optimistic treats it as TRUE.

Pessimistic is the natural setting for any rule that guards against an adverse outcome. When compliance can’t be established, the rule returns FALSE, and nobody has to remember to catch it. Your policy owners pick the setting rule by rule, and it’s written into the rule itself, where anyone reviewing the ruleset can read it.

In a RAG pipeline or an LLM-as-a-judge setup, nobody decides what happens to missing information. It falls out of the retrieval settings, the prompt wording, and whichever model version is running, and it changes when any of them does. A written DSAIL policy applies the same way to every output until someone deliberately changes it.

What to do with the UNKNOWNs

An UNKNOWN names the missing information and the rules waiting on it. That list is already your request for the missing information, so nobody has to rebuild it from a stack of near-misses.

At the portfolio level it becomes a monitoring signal. DSAIL verdict streams natively expose UNKNOWN-rate and verdict-mix telemetry, so a ruleset drifting away from the documents it was written against shows up as a moving number rather than as a surprise. Language changes over time, and a verification system should show you when it does.

And the workload sorts itself. Every verdict comes back at API speed with its reasoning attached. Routine cases pass with no human-review bottleneck. Your judgment goes to the exceptions that actually need it.

Evaluating AI Verification Systems

Anyone can say deterministic. Anyone can say verified. The question that separates a proof from an estimate is narrower than either: what does your system do when the document doesn’t contain the information a rule needs?

Be wary of vendors who say “we return the most likely determination.” They’re telling you their system will guess at the missing fact and hand you the result in the same format as everything else.

Next year’s model will guess better than this year’s, and it will still be guessing.

Next year’s model will guess better than this year’s, and it will still be guessing. A system whose output space has two values fills the silence with one of them every time. That’s the part you can’t fix with a better model.

Jaxon’s DSAIL answers “we return UNKNOWN, and you decided in advance what UNKNOWN does,” which gives you something you can put in front of an examiner: the rule that was applied, the document it was applied to, and the fact that wasn’t there.