Blind the Test Before You Trust the Benchmark

A benchmark score can be precise and still answer the wrong question if the model has already encountered its cases or the tested build changes halfway through the run. On August 27, Google DeepMind described a double-blind evaluation pilot designed to keep an evaluator’s benchmark prompts hidden from the model owner while keeping the proprietary model weights hidden from the evaluator. Its technical report describes tests of Gemini 2.5 Flash Lite with a private MLCommons AILuminate corpus and a separate prompt set from Singapore’s AI Safety Institute, using a secure computing environment. These are the authors’ descriptions of a specific pilot, not an independent finding that the method eliminates contamination or predicts deployment performance. Google DeepMind’s pilot announcement Technical report

“Double-blind” has a specific meaning here. It describes mutual secrecy between model owner and evaluator; it does not, by itself, hide system identity from human raters, randomize answer order, or prevent an evaluator from favoring one output. Those are separate blinding choices. The distinction matters because a benchmark can protect its prompts and still have a weak rubric, an unstable build, or a score that rewards the wrong thing.

Define the claim before assembling the test

Write one question that the run is meant to answer. For example: “Does release B meet the approved factuality threshold on the held-out support-answer set under the same retrieval and tool configuration as release A?” That is testable. “Is B better?” leaves the task, threshold, and acceptable tradeoffs unstated.

Name the intended use, the owner who can act on the result, the consequence of a false pass, and the stop condition. If the use involves a consequential decision, the threshold should reflect the cost of a wrong answer, not just the desire for a clean chart. NIST’s AI Risk Management Framework calls for documented, repeatable testing, defined roles, test sets and metrics, and evidence gathered under conditions similar to the intended use. It also says independent review can reduce internal bias and conflicts. The framework is voluntary guidance, not a benchmark recipe; the protocol below adapts those principles to a sealed comparison. NIST AI RMF Core

Before collecting results, name the baseline. It might be the currently deployed release, a non-AI workflow, or a fixed reference system. The baseline and candidate must receive the same cases, tools, permissions, and scoring rules. Without a comparator, call the run a characterization, not an improvement claim.

Freeze the build and seal the cases

Create a build manifest containing the model or provider and exact release identifier, system instructions, application code, retrieval index version, tool definitions, permissions, decoding settings, runtime image, and relevant admin settings. Hash the files that can be hashed. If a hosted service will not expose an immutable model build, record the displayed release, deployment identifier if available, date and time, and the fact that the underlying version cannot be independently frozen. That limit belongs in the result.

The test custodian prepares the cases separately from the build team. Remove personal or confidential data unless its use has been explicitly authorized and protected. Mark which cases are public, development, calibration, and held out; a case used to tune a prompt is no longer a clean holdout for that prompt. Assign random case IDs and store the answer key and case text in restricted storage. A cryptographic digest can show that a file has not changed since sealing; it does not make predictable cases secret. Keep the file access-controlled, and do not publish unsalted hashes of small or guessable case sets.

Freeze a test fixture too: the input packet, initial database state, retrieval corpus, tool responses, and any simulated clock or user state. If a run changes one of those, start a new cohort or mark the affected case invalid. Do not quietly merge outputs from different fixtures under one score.

Preregister the score and split the roles

Before anyone sees candidate outputs, write down the primary metric, pass threshold, secondary measures, case strata, exclusions, number of runs, handling of timeouts and missing outputs, and any permitted retries. Include the exact scoring rubric and analysis script version. If human judgment is part of the score, state who will rate the outputs, whether system identities and answer order will be masked, how disagreement will be resolved, and which cases receive a second rating.

Assign distinct responsibilities: a case custodian holds the sealed cases and answer key; a build custodian freezes the candidate and baseline; an operator runs the approved harness; and an auditor checks the manifest, exceptions, and readback. One small team may combine some roles for a low-risk exercise, but write down the overlap. For a higher-stakes or externally reported comparison, use independent custody or an external evaluator where practical.

Google DeepMind’s reported pilot used a secure enclave and a code-approval process so each party could inspect the approved computation without receiving the other party’s private asset. A small internal evaluation may not need that infrastructure. The transferable requirement is to make access and changes visible: who can read the cases, who can alter the build, who can start the run, and who can reveal the mapping must be decided in advance.

Run once under the declared conditions

The operator records the manifest hashes, test-set version, start time, environment, random seeds where available, and run identifier before execution. Run the same harness against the baseline and candidate. Preserve every input, output, tool request and response, error, timeout, retry, and scoring event. Do not remove a bad result because it appears anomalous; first classify it using the preregistered rule. If a case is missing, report it as missing rather than silently shrinking the denominator.

Stop and invalidate the affected comparison if a model or prompt changes, cases are exposed to the tuning team, the harness behaves differently between systems, or the log cannot establish which build ran. For a stateful application, reset each case to the same fixture. If the benchmark permits retries, count them exactly as specified and preserve each attempt; otherwise a later successful answer can erase the failure the protocol was supposed to measure.

Reveal, audit, and limit the conclusion

After the primary analysis is saved, the custodian reveals the system-to-label mapping and the case-level results to the authorized reviewers. Recompute the score from the preserved raw outputs. Check that every expected case appears once, the build hashes match, exclusions follow the written rule, and the summary agrees with the case ledger. Record disagreements, missing data, deviations, and the identity of the person who approved the final report. For blinded human ratings, reveal model identities only after the ratings and adjudication are locked.

Treat each proposed benefit as a hypothesis. Sealed prompts may reduce one route by which benchmark cases reach a model developer before evaluation. Mutual secrecy may protect both test material and proprietary weights. Preregistered analysis may make selective reporting easier to detect. A pilot does not prove those benefits for every environment, nor does secrecy show that a model never saw similar cases during training. A private set can also be unrepresentative, and an accurate benchmark score is not evidence that an application is safe in every live setting.

The evidence standard is therefore modest and concrete: a reader should be able to reconstruct what was tested, against which comparator, with which cases and rules, and why each reported result was included. If the custody chain or build identity cannot be read back, publish no comparative claim from that run. The protocol earns trust through the record it leaves, not through the word “blind.”

Sources and limitations

• Google DeepMind, “Piloting the world's first double-blind AI evaluations” — checked October 21, 2026; describes Google DeepMind’s August 27, 2026 pilot and its stated goal of mutually protecting model weights and evaluation prompts. Limitation: the “world’s first” and expected-benefit language is the company’s characterization, not independently established here.
• Google DeepMind, “Double-blind evaluations: Technical report” — checked October 21, 2026; details the authors’ implementation and evaluation setup. Limitation: it documents a specific pilot and does not establish general benchmark validity, absence of prior training exposure, or deployment safety.
• NIST AI Risk Management Framework Core — checked October 21, 2026; supports documenting metrics, tools, context, limitations, repeatability, and independent review. Limitation: it is voluntary risk-management guidance, not a cryptographic benchmark standard; NIST notes that AI RMF 1.0 is being updated.