Verifier vs LLM judge: how to pick a grader

This is a decision page. If you want the training-side how-to for designing reward functions, HUD's verifier and reward design guide covers that ground well and we are not going to rewrite it. What follows is narrower: given one step of one process, which grader do you attach to it, and what does the wrong answer cost you.

What is the difference between a verifier and an LLM judge?

A verifier decides whether an output meets a condition by executing code against state, and an LLM judge decides by asking a language model for an opinion. That is the whole distinction and everything else follows from it. A verifier reruns to the same verdict forever. A judge is a model, so it has a temperature, a prompt, a position preference, a training distribution, and a release schedule.

The word "verifier" gets used loosely for both, which is why "we have a verifier" carries no information. What matters is whether the verdict came from execution or from inference. See verifier and judge model for the definitions we use.

When should you use a deterministic verifier?

Use a deterministic verifier whenever the pass condition can be written as a statement about system state, which is more often than teams assume before they decompose the process. Concretely, prefer the verifier when any of these hold:

• The condition compares two values that both exist somewhere. Invoice total against sum of lines. Received quantity against invoiced quantity. Ledger balance before against after.
• The condition is existence or absence. The record was created. The duplicate was not created. The file landed in the right bucket.
• The condition is a format or bound. Schema valid, within tolerance, inside the date window, under the approval limit.
• The condition is reproducible by a second implementation. If two engineers writing it independently would agree on every case, it is code, not judgment.

Han Lee's taxonomy of RL environments states the default plainly: "Verifiable beats judgeable. Programmatic checks such as string match or code execution, are faster, cheaper, and more consistent than LLM-as-judge", and model-based evaluation should be deployed "when there's no other option, not as the default" (A Taxonomy of RL Environments for LLM Agents, March 2026).

The reason to care beyond cost: a deterministic verifier is the only grader whose error rate is zero by construction. Everything else has an error rate you have to measure and then carry forward into every reliability number you report.

When is an LLM judge the right tool?

An LLM judge is the right tool when the pass condition depends on meaning that no state comparison can capture and a human would otherwise have to read every output. Real cases: is this exception note actionable by the AP clerk, does this drafted dispute response address the customer's stated complaint, is this incident summary faithful to the reports it summarizes.

These are not verifier problems and pretending otherwise produces a check that passes garbage in valid JSON. The eval tooling has converged on the layered answer - Braintrust's position is that "deterministic checks should handle everything that can be measured directly" while the judge focuses "only on subjective dimensions that require language understanding" (What is an LLM-as-a-judge?). We agree with the layering and add one requirement: the judge tier ships with a measured agreement number or it does not ship.

What biases does an LLM judge inherit?

An LLM judge inherits the biases of the model underneath it, and the paper that established the method is also the paper that catalogued them. Zheng et al. found GPT-4 judges reaching over 80% agreement with human preferences, matching human-to-human agreement, while documenting "position, verbosity, and self-enhancement biases, as well as limited reasoning ability" (Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena). Follow-on work quantified position bias and self-preference bias as separate effects.

The one that bites hardest in an agent pipeline is correlated error. When the grader shares a family with the thing being graded, its mistakes line up with the agent's mistakes. Lee again: "Using the same model family to both generate completions and judge them creates a feedback loop - the agent learns to write prose that sounds good to its own judge rather than prose that's correct." His rule is that the judge should be "a different model class than the policy, and ideally one the training signal can't update".

Self-verification is the degenerate case of the same problem. Across Game of 24, graph coloring, and STRIPS planning, Stechly, Valmeekam, and Kambhampati report "significant performance collapse with self-critique" and "significant performance gains with sound external verification" (On the Self-Verification Limitations of Large Language Models on Reasoning and Planning Tasks). A model does not catch the error classes it reliably makes.

How many judge runs does one verdict take?

More than one, and the number has been measured. In a reliability study of pairwise LLM judging, "pairwise preferences flip on average 13.6% of the time, with 28% of questions exceeding a 20% flip rate and one question reaching 56%", cross-judge agreement came to 76% at kappa 0.51, and "11 repeated trials are needed for a majority vote to recover the 50-trial reference verdict with 95% probability on average" (The Coin Flip Judge? Reliability and Bias in LLM-as-a-Judge Evaluation, June 2026).

Take that seriously when you cost the judge tier. A single judge call is not a verdict, it is one sample from a distribution. If your pipeline calls a judge once per step and treats the answer as ground truth, your reported reliability is inflated by an amount you have not measured. Either budget for repeats, or push the check down to a verifier, or leave a human in it.

Verifier vs LLM judge, side by side

How do we choose between them?

Four criteria, applied per step, in this order. This is the actual sequence we run in a scoping call, not a diagram.

1. Can the condition be stated about state? If yes, it is a verifier and the conversation ends. We spend most of a first engagement here, because the decomposition usually reveals that steps assumed to be judgment calls were compound steps hiding computable ones.
2. If not, can it be decided by one narrow classifier scored on held-out examples? A single-purpose classifier with a holdout number beats a general judge with a clever prompt. Narrow scope is what makes the number meaningful.
3. If not, is there enough annotated data for a judge with measured agreement? A few hundred pass/fail examples annotated by the operators who own the process. If we cannot get the annotations, we do not get a judge, we get a guess.
4. If none of the above, the human stays in the check. This is a legitimate answer and we say it out loud. A step graded by a human forever is better than a step graded by an unmeasured model and reported as verified.

The engineering job over the life of an environment is moving checks up that list. Every step promoted from judged to computed removes a place where the verification itself can be wrong. How to decide when a rubric criterion is ready for that promotion is in rubric engineering, and the vocabulary for the three tiers is in approved checks.

What should you do first?

Take one process, list its steps, and mark each step V, C, J, or H for verifier, classifier, judge, or human. That single page tells you what fraction of your process can be graded without trusting a model, which is the only honest input to a reliability estimate. The step-by-step method is in how to verify AI agent work, and why programmatic rewards beat learned ones in training is in reinforcement learning with verifiable rewards.

If you want a second reader on the V/C/J/H pass, bring one process to [email protected]. If it comes back mostly H, we will tell you that on the call rather than sell you an environment.