What a Verifier Is, and Why an LLM Judge Is Not One

An LLM judging another LLM is not verification. It is a second opinion with the same failure modes, dressed up as quality assurance. When you ask a model to evaluate the output of another model, you are not building a test suite. You are building a conversation. Conversations are probabilistic. They drift. They hallucinate. They change their mind based on the phrasing of the prompt. If your pipeline relies on this pattern for critical checks, you have not eliminated risk. You have merely shifted it from the generation step to the evaluation step. The verifier we are building in this course rejects this premise. It is deterministic. It contains no model in the loop. It returns located violations rather than a score. It is reproducible across runs. This distinction is not academic. It is the difference between a system you can trust in production and one you have to babysit.

Determinism Versus Probability

The core failure mode of the LLM-as-judge pattern is non-determinism. Run the same evaluation prompt ten times with the same input and output. You will often get different results. Sometimes subtle. Sometimes contradictory. This happens because the judge model samples from a distribution. It does not execute a rule. It guesses the intent of the rule. Consider a simple constraint: the output must contain exactly three bullet points. A deterministic verifier checks the structure. It counts the list items. It returns true or false. Every time. An LLM judge reads the text. It might decide that a paragraph break looks like a bullet point. It might decide that three bullet points are too many for the context. It might simply fail to count correctly. This is not a bug in the judge. It is the nature of the tool. In the pipeline we have been building, this matters because we need to catch regressions. If the verifier says the output is invalid today, it must say the same thing tomorrow when the input is identical. If it does not, you cannot automate the fix. You cannot write a test that passes. You are stuck in a loop of manual review. The verifier we are constructing avoids this by relying on code. Code does not have mood swings. Code does not get tired. Code does not interpret "approximately three" as a valid answer when the rule says "exactly three". This approach has a cost. It requires you to formalise the rules. You cannot write a vague guideline and expect the verifier to understand it. You must translate the guideline into logic. This is harder work upfront. It is slower to write. But it pays off in reliability. Once the rule is coded, it is fixed. It does not drift. It does not need re-prompting. It does not need fine-tuning.

Locality and Auditability

A score tells you nothing about where the error is. A violation tells you exactly where. When an LLM judge returns a score of 4 out of 5, you have to read the output again to find the problem. You have to guess. You have to hope the judge was looking at the same thing you are. This is not auditability. This is faith. The verifier returns located violations. It says: line 12, column 5. Missing required field. It says: paragraph 3. Contradicts source document at section 2.1. This allows you to fix the generation step directly. You can adjust the prompt. You can adjust the retrieval. You can adjust the formatting. You do not have to guess. This locality is critical for the pack we are building. The pack contains multiple checks. Each check is independent. Each check returns a list of violations. If one check fails, the others still run. You get a complete picture of the output. You do not have to run the checks sequentially. You do not have to worry about one check masking another. This parallelism is only possible because the checks are deterministic. They do not depend on the state of a conversation. They depend on the structure of the text. Auditability also means you can trace the violation back to the rule. You can see the code that flagged it. You can see the input that triggered it. You can see the output that failed. This trace is transparent. It is not hidden in the weights of a model. It is not obscured by attention maps. It is plain text. It is code. It is something you can read. It is something you can change.

Cost and Scope

LLM judges are expensive. They require inference. They require tokens. They require compute. Running a judge model on every output in a high-volume pipeline adds latency and cost. This cost scales with the length of the output. It scales with the number of checks. It scales with the frequency of runs. The verifier avoids this cost. It runs locally. It runs fast. It uses negligible compute. It is a script. It is not a service. This does not mean the verifier replaces the judge everywhere. The judge has a legitimate role. It is useful for fuzzy qualities. Tone. Style. Creativity. Nuance. These are hard to formalise. They are hard to code. They require human judgment. Or at least, model judgment that approximates human judgment. If you need to check whether the output sounds empathetic, a deterministic verifier will struggle. It can check for keywords. It can check for sentence length. It cannot check for empathy. But most production constraints are not fuzzy. They are structural. They are factual. They are logical. The output must be JSON. The output must cite sources. The output must not contain PII. The output must be in English. These are rules. They are not opinions. They are not styles. They are constraints. The verifier handles these constraints. It handles them cheaply. It handles them reliably. It handles them at scale. The table below compares the two approaches across key dimensions. It is not a comprehensive list. It highlights the tradeoffs that matter for the pipeline.

The implementation effort is the real limitation. Writing a verifier is not trivial. It requires you to understand the domain. It requires you to understand the output. It requires you to translate natural language constraints into code. This is hard work. It is slow. It is error-prone. You will write rules that are too strict. You will write rules that are too loose. You will write rules that miss edge cases. You will have to iterate. You will have to test. You will have to maintain. This is the cost of determinism. It is the price of reliability. But the cost is front-loaded. Once the rules are written, they are fixed. They do not drift. They do not degrade. They do not need re-prompting. They do not need fine-tuning. They just run. This is the tradeoff. You spend time upfront to save time downstream. You spend effort now to gain reliability later. This is the engineering choice. It is not the easy choice. It is the correct choice for production systems. The next lesson, Modelling the Domain: Required Elements, Prerequisites, Orderings, Vocabulary, will show you how to start this work. It will define the structure of the rules. It will show you how to break down a constraint into testable parts. It will give you the vocabulary for the verifier.

Apply it to your work