Your check is already an eval

Using a model to grade another model's output is now the default, and the usual objection is that you can't trust the grader. The research says something more useful than “yes you can” or “no you can't”: how much you can trust it depends almost entirely on how specifically you asked. The specificity lives in the rubric — and if you have ever written down what a good output looks like, you have most of one already.

Andriy Kudelya · 2026-07-26 · 7 min

There is a version of this argument that is just marketing — use evals, they're good for you — and it doesn't survive the first hour of trying. You write a judge prompt, it returns 8/10 for everything, you conclude the whole practice is astrology, and you go back to reading outputs by hand. That reaction is correct about the thing you built. It is wrong about the reason.

The number that isn't about the model

The clearest result here is nearly three years old and still under-quoted. Prometheus is a 13-billion-parameter open model trained to evaluate long-form text against a rubric you supply. Given 45 customised score rubrics, its scores correlate with human evaluators at 0.897 Pearson — level with GPT-4's 0.882 on the same task.

Read the top two rungs together. A 13B model you can run yourself matched the best available model at judging, once both were handed explicit criteria. Whatever is doing the work in that comparison, it is not parameter count.

The judge is a commodity. The rubric is the asset.

Where the trust actually breaks

The reason a naive judge feels like astrology is that its reliability is wildly uneven, and the unevenness tracks the question rather than the grader. A scoping review of LLM judges in healthcare measured expert-model agreement across 21 separate dimensions of empathic communication and found weighted kappa ranging from 0.17 to 0.86 — from barely better than chance to genuinely useful, with the same model, on the same outputs, depending only on what it was asked to assess.

That range is the whole story. Ask “is this response good?” and you are somewhere on the low end, because the model has to invent the criteria before it can apply them — and it will invent different ones each time. Ask “does this contain at least two verbatim quotes per theme, with the interview each came from?” and you are somewhere on the high end, because there is nothing left to invent. Rubric-guided approaches like G-Eval improve alignment for exactly this reason: the chain of reasoning is pinned to criteria that were fixed before the output was seen.

Which means the practical question is never “can I trust an LLM judge?”. It is “have I told it what I actually care about?” — and that is a question about your own clarity, not the model's.

You have probably written a rubric already

Here is the part that annoyed me into writing this. If you have ever reviewed an AI output and formed an opinion, you applied criteria. If you have ever told a colleague “it's close, but it needs to cite the source and stop hedging”, you said the rubric out loud. If you have written a prompt with an output contract — five to eight themes, each under three sentences — you wrote it down and then used it exactly once.

That is the waste. Not that people don't have criteria; that the criteria are produced fresh, applied once, and discarded. An eval is not a new artifact you have to invent. It is the thing you already do, written in a form that can run again tomorrow without you.

The mechanical version, for a workflow with steps:

1. Each step's output contract is an assertion. Whatever the next step needs to receive — that is checkable, and it is the failure that actually breaks things.
2. Each failure mode you predicted is an assertion. You listed them when you designed the thing; you were guessing about the future, which is exactly what a test is for.
3. Each quality gate is already a judge. If a step in your workflow reviews another step's work, you have a judge with a rubric. It just isn't written down anywhere you can rerun.

What we changed here, and why it was embarrassing

Prowrit's engineer runs a readiness review on every workflow it designs — a fresh-context pass that grades the blueprint against five aspects and hunts six named defects, using a rubric built from the failure modes it predicted for your specific brief. It is exactly the specific-rubric case the research says works.

And we threw the rubric away. Every single run. Users saw a verdict — reviewed before you saw it — and never the criteria behind it. We computed a bespoke eval spec, used it once internally, and deleted it.

So now the studio exports it. Every workflow comes with a runnable promptfoo suite generated from its own criteria: one config per step, each step's placeholders as variables, each step's contract as an assertion, and the predicted failures as rubric checks.

One config per step, not one file, because a promptfoo config runs every prompt against every test — three steps in one file would be nine runs, six of them nonsense. And it runs on your models with your keys; we run nothing. There is no service here to depend on.

It also settles a fair objection to our own review, which is that a model is grading its own homework. Handing you a runnable version of the rubric turns that from a thing you have to take on faith into a thing you can point at a different model and check.

The part that will actually bite you

Generated tests come with placeholder inputs. An empty variable renders as an empty string, an empty string usually satisfies a vague rubric, and so an eval you haven't filled in passes everything. That is worse than no eval, because it produces a green light you didn't earn. The generated README says so in the first paragraph; it is the one instruction that matters.

Two more, in the same spirit. A rubric written from what you expected to go wrong will miss what actually goes wrong — the first real failure you hit belongs in the suite the same day. And a model-graded assertion needs a grader key, so a suite that reports all-pass in a shell with no credentials is telling you about your environment, not your workflow.

None of which is an argument against doing it. The alternative is re-deriving your own standards from scratch every time you look at an output, which is the thing you were already tired of.

Sources: the 0.897 / 0.882 / 0.392 correlations, and the 45 customised score rubrics — Kim et al., “Prometheus: Inducing Fine-grained Evaluation Capability in Language Models” (arXiv:2310.08491, ICLR 2024) · the 0.17–0.86 weighted-kappa range across 21 dimensions — “LLM-as-a-Judge in Healthcare: A Scoping Analysis of Applications, Methods, and Human Alignment” (arXiv:2605.25273), which is a specific domain and should be read as an illustration of variance rather than a universal figure · rubric-guided chain-of-thought judging — “A Survey on LLM-as-a-Judge” (arXiv:2411.15594) · the config format — promptfoo documentation. Correlation coefficients and kappas are not interchangeable measures; each figure above is quoted with the metric its authors used.