Part IV
Your benchmark is a build dependency
Take a claim that sounds like wordplay and is not: the benchmark and the training environment are the same object.
Scope that properly before going further, because the unscoped version is false and someone will say so. Under held-out evaluation with no gradient path back to the model, an eval is a measurement instrument and nothing more. The identity holds under reinforcement learning from verifiable reward, where the evaluation artifact defines the reward signal. There the two are not analogous. They are one file, read twice, by two teams who think they are doing different things.
Once you accept the scoping, the security reading is immediate and uncomfortable.
The reframe
What a build dependency gets that a benchmark does not
If an artifact determines the behaviour of a shipped system, your industry has a well-developed opinion about how it should be handled. Package ecosystems learned this the hard way over fifteen years and the resulting apparatus is real: signing, provenance attestation, version pinning in consuming repositories, revocation paths, maintainer accountability, typosquatting detection, reproducible publication.
Now go and look at how an evaluation dataset used in a published RLVR setup is handled.
| Property | Package registries | Evaluation datasets and RL environments |
|---|---|---|
| Cryptographic signing | Standard | Essentially absent |
| Provenance attestation | Increasingly standard | Absent |
| Version pinning downstream | Standard | Inconsistent — often "latest" or a git URL |
| Revocation path | Exists | None |
| Maintainer count / bus factor | Tracked, discussed | Untracked |
| Declared vs. actual scope | Reviewed | Rarely stated at all |
The artifacts that shape model behaviour have a weaker security posture than the packages that merely run it. That is the finding, and it is a measurement rather than an argument — it is checkable against public data today, requires no model access, no ethics review, and no disclosure gating. It is the single most tractable piece of empirical work in this whole research program and it produces a number the field does not currently have.
Season 3 spent ten episodes on the dependency graph beneath your applications. This is the same argument one layer over, on a substrate that has not yet had its Heartbleed.
The second-order problem
Difficulty is not a neutral property of an item
There is a mechanical fact about training that turns benchmark design into something more consequential than it looks.
A training item carries the most gradient signal when the model is genuinely uncertain about it — when the pass rate sits near the middle rather than near either end. Items the model always gets right teach it nothing. Items it always gets wrong teach it nothing. The band in between is where learning happens, and it is also where a small number of items has maximum influence per item.
Which means: good benchmark design and high influence-per-item are the same design criterion. A well-built frontier benchmark — calibrated to sit right at the edge of current capability, which is exactly what makes it useful — is by construction the most efficient possible vehicle for influencing a model that trains on it.
I am deliberately not writing the operational version of that observation. The defensive corollary is the part that is actionable and it is entirely sufficient:
Frontier-difficulty evaluation items are the highest-value artifacts in your training supply chain, and they are currently the least protected. Provenance controls should be strongest exactly where the items are hardest, which is the inverse of current practice, where the hardest benchmarks are the newest and least scrutinized.
Attestation
Why a capability evaluation goes stale without being wrong
Capability attestation is becoming a governance primitive: evaluate the model, publish the result, gate deployment on it. The structure is sensible and I would rather have it than not.
But look at what an attestation actually is. It is a measurement of a specific artifact — model weights M, benchmark B — at a specific time t. It is a true statement about that measurement.
Systems in production are not that artifact. They are that artifact plus scaffolding, plus tools, plus retrieval, plus a prompt architecture, plus whatever got added last quarter. Each addition can be individually below any declared threshold for re-evaluation. None of them modify the weights. Every one of them can change the capability being attested.
The attestation remains valid. The measurement becomes stale. Nothing in the pipeline notices, because nothing in the pipeline is measuring the distance between the attested configuration and the deployed one.
Attestation scope decay is that distance expressed as a half-life: the modification budget at which the evaluation's predictive validity drops below threshold. And the prediction that makes it worth measuring is uncomfortable — decay should be fastest for compositional and agentic capabilities, and slowest for knowledge recall. Attestation reliability is inversely related to security relevance. The capabilities we most want a governance gate on are the ones whose gate expires quickest.
This is a measurable quantity and nobody is measuring it. It would take a modification-budget sweep against a fixed eval and would produce, for the first time, a defensible answer to "how long is this evaluation good for?"
The tension
Publishing the eval is publishing the target
Here is a genuine conflict, and one where the governance community has largely picked a side without acknowledging there was one.
Publishing an evaluation suite is an accountability mechanism. It lets outsiders reproduce a claim, compare across labs, and catch overstatement. That is good, and the field is better for the ones that exist.
Publishing an evaluation suite also publishes exact target coordinates. An eval that is public is an eval that can be optimized against — in either direction. A model can be shaped to underperform a specific public instrument while retaining the capability on a private functional equivalent, and the result is a clean attestation for a capable system.
I am not going to develop the how. The point that matters is structural: transparency and integrity are in tension here and the tension is not resolvable by choosing harder.
What makes this episode's version of the problem tractable is that the resolution shape already exists, in a field that has fought this exact battle for decades. High-stakes testing — professional licensure, standardized admissions — solved it with item-bank security: a large pool of calibrated items, a rotating subset exposed publicly for transparency, a held-out subset used for scoring, and periodic rotation with statistical equating so scores stay comparable across item sets.
That machinery is mature, it is well documented, and to my knowledge nobody in AI evaluation is using it. Adopting it would cost real effort in item calibration and would give up the simplicity of a single fixed public benchmark. It would also make the sandbagging problem substantially harder without giving up accountability, which is more than any current proposal does.
Monday
Four things, in ascending cost
Commit hash, not branch. Vendored copy, not URL fetch at runtime. This is a one-line change in most training configurations and it closes the most trivially exploitable gap in the chain.
Maintainer count, last-commit recency, whether there is any revocation path if something is found wrong. You do this for your Python dependencies. The artifact that defines your reward function deserves at least parity.
Model version, scaffolding version, tool set, retrieval configuration, prompt architecture, date. Then define what change to any of those triggers re-evaluation. Most organizations have an attestation and no scope statement, which means the attestation has no expiry and therefore no meaning.
Public subset for accountability, held-out subset for scoring, documented rotation. It is more work. It is the only approach that gets both properties, and the testing profession has fifty years of practice at it.
Next episode moves to the sharpest version of the "artifact that defines correctness" problem — formal proof libraries, where the artifact is the definition of truth itself, and where an optimizer rewarded on output has a strategy available that makes every subsequent theorem trivially provable.
