TL;DR

  • In AI model evaluation, a grader asked to “score this out of 10” returns a plausible number whether or not it checked anything. Nobody can audit that number later.
  • The grader in Groundtruth, our geology benchmark, must show its work in a fixed format. Software checks that breakdown before accepting it.
  • If the check fails, the grader tries again, up to three times. After that, the question stays unscored instead of getting a made-up number.

Key Takeaways

  • Nobody can audit a bare score. A number alone doesn’t show which requirement an answer met or missed.
  • The grader has to show a structured breakdown, not just a total. Software checks every part of it: the math adds up, every required item appears, and no extra item sneaks in.
  • The harness rejects a broken breakdown and asks again; it never patches one. After three failed attempts, the question stays ungraded instead of getting a guess.
  • Automatic checks catch structure, not judgement. A well-formed breakdown can still reach the wrong conclusion. That is why we test every rubric against known answers first.

An LLM judge is an AI model that grades another AI’s answers. Ask it to “score this answer out of 10” and it returns a number that looks reasonable whether or not it applied the rubric. A score of 8 with no breakdown does not belong among AI model evaluation metrics: nobody can tell which requirement the answer met or missed.

Groundtruth Dynamic Benchmarking, our benchmark for geological reasoning, grades every answer with one fixed judge, openai/gpt-5.5, against a rubric with a gate and graded components. Rigorous AI model evaluation treats that judge’s output as something to validate, not trust. This post covers what we ask the judge for, what the harness checks, and what happens when a check fails.

What goes into the AI model evaluation prompt

Of all AI model evaluation techniques, an LLM judge depends most on what it is given. For each answer, the harness renders that question’s marking block into a pointwise scoring prompt. The judge receives:

  • the gate’s pass condition, followed by concrete examples of answers that fail it;
  • every component with its points, the gate marked as such, and its credit condition;
  • the required concepts, and a separate list of indicative terms that earn no marks on their own;
  • accepted name variants, so a spelling or transliteration difference is not penalised;
  • a do-not-credit list of plausible wrong answers;
  • marking rules drawn from the rubric’s scoring settings, such as positive marking after the gate and whole-number scores only;
  • the question, the reference answer, the underlying principle, and the candidate’s answer with leaked control tokens stripped out.

Our rubrics split into a gate plus scored components, and the gate’s fail examples are there for a specific reason. A pass condition on its own tends to let a plausible adjacent answer through, and concrete failing answers give the judge something to compare against.

The prompt then walks the judge through fixed steps. Check the gate first, and score zero if it fails. Assess each component independently, never award marks for vocabulary alone, and withhold credit for the listed distractors. Finally, treat correctly evaluated competing interpretations as sound reasoning, not hedging.

An output contract for AI model evaluation

The JSON block the judge must return

The judge may reason at whatever length it needs, but it has to finish with one fenced JSON block in a fixed shape:

json 
{
  "gate_passed": true,
  "gate_reason": "one sentence on why the gate passed or failed",
  "components": [
    {"id": "C1", "awarded": 3, "maximum": 3, "reason": "what earned or withheld this credit"}
  ],
  "total": 8,
  "adjudication_required": false,
  "adjudication_note": null
}

The eleven rules the validator checks

The harness extracts the last valid JSON block from the response and checks it against the rubric for that question. It rejects the result if:

  • gate_passed is missing or is not a boolean.
  • the components list is missing or empty.
  • a component id does not exist in the rubric.
  • a component id appears twice.
  • an award or maximum is not a whole number.
  • a component’s maximum differs from the points the rubric gives it.
  • an award falls outside zero to its maximum.
  • any rubric component is missing from the list.
  • the total is missing or is not a whole number.
  • the gate failed but the total or any award is not zero.
  • the gate passed but the total does not equal the sum of the awards.

None of these rules is subtle. Each one blocks a way a judge can produce a plausible number the rubric does not support. Examples: inventing a component, awarding a mark the rubric caps lower, rounding to a half point, or letting partial credit leak past a failed gate. That is why an LLM-as-a-judge needs a structured output contract like this, not just a rubric.

What happens when the check fails

The harness logs a rejected result with the specific problem and asks the judge to grade the answer again from the same prompt, for up to three attempts in total. If the judge still has not produced a valid result, the harness records the question with a null score and a warning.

A null is deliberate, following the same rule we apply across AI agent evaluation: record a question as unscored, never guessed. The alternatives are to take the judge’s last number or to fall back on a default. Both would put a figure into the results that nobody can defend. A null shows up in the summary, excludes the question from the average, and can be re-scored later.

The harness handles network problems separately. Each judge request gets up to four HTTP attempts, with increasing waits between them, before the scoring attempt counts as an error. The API bills every successful response, including the ones the validator rejects, and the harness records the cost of each call as it happens.

Validating the rubric before the judge sees it

The same problem exists one step earlier. The harness reads rubric fields defensively, so a malformed rubric would not crash anything. It would quietly hand the judge empty criteria, and a judge grading against empty criteria still produces plausible-looking scores.

So the harness validates a rubric as soon as someone chooses it, before it generates or scores any answer. The schema version must match, every gate needs a pass condition, and every question needs components with non-empty credit conditions. The harness rejects an older or malformed rubric with a message naming the questions at fault. That schema check runs earlier than calibration-fixture testing. The schema check catches a rubric the harness cannot parse; the fixtures catch a rubric that parses fine but grades wrong.

The adjudication flag

Some answers take an approach the rubric’s author did not anticipate. The prompt tells the judge to set adjudication_required only when an answer may deserve credit it cannot verify from the material in front of it. The judge then explains why in adjudication_note. The harness lists flagged questions at the end of every scoring run, and the public leaderboard shows a count of flags per submission. A flag does not change the score. It marks where a person should look.

One AI model evaluator, recorded and disclosed

Every run uses the same judge at temperature 0 with medium reasoning effort, and the harness writes the judge’s id into the run record. An AI model evaluator is only as trustworthy as its own consistency. A score only means something next to other scores from the same grader. Changing judges partway through a benchmark breaks the comparison, and letting a model grade its own answers invites self-preference.

There are two limits to state plainly. The judge is not perfectly deterministic even at temperature 0, so a re-run can move a close comparison. And the judge belongs to a model family that is also on the leaderboard. GPT 5.6 Sol lands in the top tier under that judge, in third place. That it does not come first is some reassurance, and an independent judge is on the roadmap.

What validation cannot catch in AI model evaluation

The contract guarantees that a score is internally consistent and matches the rubric’s structure. It says nothing about whether the gate decision was right. A judge can return perfectly valid JSON that passes an answer it should have failed.

We found exactly that case while calibrating one benchmark. A fabricated answer reached the right conclusion by an argument the question existed to reject. The judge still scored it 10 out of 10 against an expected 0, with a clean, valid JSON block. Structural validation is necessary. Fixtures of known score catch judgement errors.

The prompt templates are in prompts.py and the validation logic is in main.py in the Groundtruth Dynamic Benchmarking repository.