Generated evals versus validated evals

You ask your coding agent to "add evals," and it happily obliges. In one conversation it scaffolds a dataset, pulls or invents a handful of examples, picks a metric, writes the reference answers it will grade against, and chooses a threshold the current behavior clears. A few minutes later you are looking at a green eval suite. The problem is not that the work is sloppy — it might be excellent. The problem is that every part of it was produced by the same agent grading the same application: the examples, the expected outputs, and the pass line all came from one interested party. A green run on that suite measures how agreeable the agent was willing to be, not how your application behaves. The question this article answers is the one you are left holding: how do you tell evidence an agent proposed apart from reference data a human actually stands behind — and what can a generated eval legitimately be used for before anyone does?

EvalGlass has a precise answer, and it is enforced in the library rather than left to discipline. There are two states an eval's evidence can be in, and only one of them can carry a gate. A generated eval — anything an agent, a generator, or a benchmark produced — lands as proposed: present, usable, readable, but not domain truth. A validated eval is reference data a host owner re-issued through a deliberate validation act, and it is the only state a check is allowed to gate on. The agent proposes; a host-owned record disposes. This is no self-approval applied to data: the actor that creates the evidence cannot also be the actor that authorizes it.

The eval your agent graded against itself

The common mistake is not laziness; it is a category error about what was actually produced. When an agent writes the gold answers and then runs a check against them, it has set the exam and marked it in the same motion. The reference answers are not an independent standard the application is measured against — they are an artifact of the same process that produced the behavior under test, drawn from the same model's idea of what "correct" looks like. A pass tells you the agent's output matched the agent's expectation. That is a coherence check on the agent, not a measurement of your product. The same trap appears one level up: a threshold the agent picks because the current run clears it is not a bar the behavior had to meet; it is a bar drawn around where the behavior already is.

A generated eval can be read, can inform you, and can compare two runs. What it must never do on its own is validate itself as gold or set a gate it then clears. Creating evidence and granting it authority are different acts — and they have to be performed by different parties.

Notice this is not a claim that the agent's examples are wrong. They may be exactly the cases that matter. The point is narrower and sturdier: nobody has checked, so the evidence cannot stand in for the judgment a check needs underneath it. EvalGlass does not try to detect whether generated data is good — it cannot, and a tool that claimed to would be inventing the very confidence it exists to refuse. What it does instead is structural and weaker, and therefore honest: it refuses to let the actor that created generated data also validate it, and leaves the judgment of quality where it belongs, with you.

Why generated is weaker than validated

The split is not house style; it tracks findings the research literature has documented, each of which bites hardest exactly when the generator of the data is also its judge. EvalGlass does not solve any of these — they are the reason the proposed-versus-validated line exists, not problems the line makes disappear.

The first finding is that synthetic evaluations quietly lose information even when they look fine. A 2025 study reconstructing reading-comprehension benchmarks found that LLM-generated evaluation datasets are systematically less challenging than their human-authored counterparts — valid and cheap, but less able to discriminate between models.¹ An eval that no longer separates a strong system from a weak one can lead you to a different deployment decision than a human-authored one would, while still reporting a confident number.

The second is that judges favor work that resembles their own. A 2024 study found that an evaluator's ability to recognize its own outputs correlates with rating them higher.² When the agent that generated your examples is also the model grading against them — the ordinary case when you let one coding agent do everything — that self-preference is not a corner case; it is the default tilt of the whole suite.

The third is that a number an interested party controls can be raised without doing the work. Evaluation examples leaking into training data — test-set contamination — inflate benchmark scores, rewarding memorization over capability.³ Agent-written gold is exposed to a cousin of this problem: gold drawn from the same model that produced the behavior can encode the model's blind spots as the standard of correctness. That is precisely why agent-written reference data needs an independent validation step rather than a self-issued one.

And the fourth is the constructive flip side: validation is a real, value-adding act, not a rubber stamp. A 2024 study of tool-using LLMs found that data passed through quality control outperforms unvalidated data even at smaller scale;⁴ and a 2025 study of human-in-the-loop refinement of LLM judges found that humans editing and curating synthetic cases catch edge cases and improve criteria.⁵ Read together, these are field context, not EvalGlass results: they explain why the proposed/ validated split is worth enforcing, and why "a human validated it" is a meaningfully stronger claim than "a model generated it."

Two lanes: one creates, one validates

EvalGlass models the difference as two lanes that run side by side and never merge on their own. One lane creates evidence; the other validates it; and the only bridge between them is a deliberate host act recorded in your own repo. The shape is the same one that governs every creator of evidence — here it is specialised to data.

1. lane A · creates evidence

   Agent scaffolds · generator (planned)

   A coding agent shapes examples, or a planned scenario workflow generates cases. The dataset lands proposed — even a hopeful validated label is read and discarded — and stays informational. It is read; it never gates.

2. the only bridge

   A deliberate host validation

   You review the examples and re-issue the dataset as validated reference data, recorded in a host-owned file. Generation never crosses this on its own — there is no verb that lets it.

3. lane B · can carry a gate

   Validated reference data → Verdict Engine

   Only validated data, with an approved threshold, resolves through the single Verdict Engine to can_gate. Until then a check is informational by construction.

Lane A is everything that can produce evaluation data. Today that is a coding agent shaping examples from your exported traces, or pulling turns and writing reference answers. A synthetic-scenario generator — a workflow that fabricates cases rather than drawing them from your behavior — is a decided non-goal: there is no generator, by design. What ships is the governance that will bound one, which is why this article describes a constraint that already holds rather than a feature you can run. Whatever the source, the artifact lands as evidence and nothing more: a dataset arrives proposed, and a generated case is generated, which is forced to proposed and can never enter as validated gold.

Lane B is the only lane a gate can rest on, and reaching it requires a host act. You review the proposed examples and validate the dataset, re-issuing it as validated reference data in a host-owned file. Only then can a reference metric gate on it — and only once you have also approved a threshold and set the metric to gating. The two lanes meet at exactly one point, and that point is an act of review, not a default. The table makes the asymmetry explicit.

Where the line is enforced

None of this rests on convention. The boundary lives in the library, at the exact points where a self-validation would otherwise happen. Importing a dataset that declares itself validated still returns a proposed dataset — the hopeful declared_status is accepted, recorded, and then not honored, because a label is not a review. Asking a benchmark to approve a threshold raises a governance error rather than returning an approval, because a benchmark is evidence and evidence does not authorize. The authority record starts empty, so a fresh install gates on nothing and a first run is informational by construction. And a single Verdict Engine is the only place a pass is ever minted — there is no validate, approve, gate, or certify verb the agent can call to short-circuit the act.

Those mechanisms are what turn "generated data can't self-validate" from a slogan into a property you can read in src/evalglass/harness/governance.py. It is worth being exact about what they do and don't establish. Forcing a case to proposed does not check whether the case is correct, representative, or unbiased; it only refuses to let the case promote itself. EvalGlass separates proposed from validated and bounds what each may claim; it does not certify generated data as truth, and it does not make a generated suite safe to gate on. The structural refusal is a deliberately weaker claim than detection — and the weaker claim is the one EvalGlass can actually stand behind.

A working rule for a generated eval

That leaves you with a clean, code-backed rule for the suite your agent just produced. A generated eval is good for three things immediately: you can read it to see what your agent thinks the behavior should be, you can let it inform where to look, and you can use it to compare two runs — a generated-but-consistent eval still tells you a model switch moved a number, even before anyone has blessed the number's meaning. What a generated eval must never do on its own is the rest: it cannot validate itself as gold, and it cannot set a gate it then clears. Those are the host's to grant, by validating the dataset, approving the threshold, and — if the check uses an LLM-as-judge — calibrating the judge against your own labeled examples.

The practical workflow follows from the rule. Ask the agent to scaffold the eval and leave it proposed; read what it produced as the draft it is; correct the examples that are wrong, add the cases it missed, and only then validate the dataset and approve a threshold. The agent did the typing; you did the validating; and the gate, when it exists, rests on data a human owns. EvalGlass measures, reports, bounds, and separates proposed from validated — it does not decide on your behalf, and it does not pretend a generated suite is more than a well-organised draft until you say otherwise.

Sources

The field evidence below describes why generated and validated evals are not interchangeable. None of it is a claim about EvalGlass, and EvalGlass does not solve these problems — the proposed-versus-validated governance is its own structural answer to them.

1. Gill, Ravichander & Marasović — What Has Been Lost with Synthetic Evaluation? (2025): LLM-generated evaluation datasets are valid but systematically less challenging than human-authored ones, weakening their ability to discriminate between models.
2. Panickssery, Bowman & Feng — LLM Evaluators Recognize and Favor Their Own Generations (2024): an evaluator's ability to recognize its own outputs correlates with rating them higher — strongest when the generator of the data is also its judge.
3. Xu et al. — Benchmark Data Contamination of Large Language Models: A Survey (2024): evaluation examples leaking into training data inflate scores — a number an interested party can raise without doing the underlying work.
4. Iskander et al. — Quality Matters: Evaluating Synthetic Data for Tool-Using LLMs (2024): models trained on quality-controlled data outperform those trained on unvalidated data, even at smaller scale.
5. Do et al. — Generate, Evaluate, Iterate: Synthetic Data for Human-in-the-Loop Refinement of LLM Judges (2025): human-in-the-loop curation of synthetic cases helps surface edge cases and refine judge criteria — validation is a distinct, value-adding act.