ZharfAI Team
Imagine a procurement team comparing two assistants on 400 contract questions. Model B wins by nine points, so the team prepares to buy it. Then an engineer notices that 60 questions came from a public repository used in prompt tuning, the agent could browse solution pages during the run, and the same questions had appeared in weekly regression reports sent to both vendors.
The arithmetic is correct. The decision evidence is not.
The practical question is: may this score still support model selection or release, or must it be qualified, rerun on sequestered material, or retired? Answering requires an exposure record for the test—not a confident claim that a benchmark is “clean.”
A benchmark result joins at least four things: a configured AI system, a set of tasks, an execution environment, and a scorer. Contamination occurs when exposure to the tasks, answers, close variants, or solution-producing resources changes what the result measures. Instead of estimating performance on unseen work, the run may partly measure memorization, prior tuning, retrieval skill, or knowledge of the grader.
Exposure is not automatically misconduct. Public examples are valuable for development, documentation, and comparison. The error is using a familiar set as if it were independent decision evidence. A question used to fix a prompt can remain a regression test for that fix; it should not also be presented as untouched evidence that the new prompt generalizes.
This guide goes deeper than ZharfAI's broader frontier-model evaluation guide. The reader decision here is narrower: what standing should one result have after the complete test-exposure path is considered?
Several current primary sources point to the same control problem from different directions.
NIST's new AI Technology Evaluation program says its initial-phase testbed uses blind data in a sequestered environment to mitigate train/test contamination. Data providers keep original datasets inaccessible to model providers, while submitted models are scored under common tasks and metrics. It is a developing NIST program, not a certification for an organization's local evaluation.
Google DeepMind's August 27, 2026 double-blind evaluation pilot describes a cryptographically protected environment intended to keep confidential prompts from the model owner and proprietary weights from the evaluator. Google calls it the first double-blind evaluation of a proprietary frontier-class model. That is Google's description of its pilot, not evidence that every confidential benchmark needs identical infrastructure.
OpenAI's May 29, 2026 playbook for third-party evaluations distinguishes the claim being tested from the evidence that the result is valid. It lists contamination alongside reward hacking, refusals, broken tasks, and sandbagging, and notes that tasks or answers may be present in training data or discoverable by an agent through browsing.
NIST CAISI's analysis of cheating in agent evaluations adds an important distinction: solution contamination gives the system improper access to solution information, while grader gaming exploits a scoring gap without satisfying the intended task. Both can produce a passing result that does not support the intended claim.
Those are verified positions. The exposure ledger, decision states, and release gate below are ZharfAI's operating synthesis.
An exact benchmark file inside pretraining data is only the most obvious path. Review five layers:
Map these as edges between actors and artifacts. “The developer never opened the answer file” is weak if a prompt optimizer consumed scores item by item, or if the agent's browser could retrieve a walkthrough.
Absence is difficult to establish, especially for a closed model whose training corpus is unavailable. Even with training access, surface matching has limits. The GPT-4 Technical Report describes a substring method that removed matched exam items and reran scores, while explicitly noting possible false negatives from small differences and false positives from partial matching. It also states that the smaller post-training set was not checked explicitly.
Semantic exposure can cross representations. The EMNLP 2024 paper Data Contamination Can Cross Language Barriers deliberately trained open models on translated benchmark test sets. Performance rose on the original English tests while several memorization-oriented checks missed the injected exposure. This controlled experiment does not prove that a particular commercial model is contaminated. It proves that “no English text match” is not equivalent to “no exposure.”
The defensible statement is bounded: which paths were examined, which evidence was available, which checks ran, and what remains unknown. Use labels such as no known exposure under stated controls, suspected exposure, or exposure unknown. Do not turn a hash scan into a certificate.
Create the record before the first run. A useful manifest contains:
evaluation_id
decision_claim
task_release + item digests
item sources + creation dates + licences
secrecy class + permitted viewers
public, practice, calibration, or decision partition
model and system configuration digest
allowed tools, domains, repositories, data and time cutoff
scorer, rubric and judge versions
all prior runs and item-level feedback recipients
overlap, reproduction and generalization checks
known, suspected and unknown exposure events
result status + owner + expiry condition
Bind the manifest to raw outputs, observable tool traces, scorer artifacts, exclusions, and the final report. The audit-evidence guide explains how to preserve integrity and custody without claiming that an artifact proves more than it does.
The exposure record should travel with the score. A dashboard that shows 83% without task release, system digest, access policy, and exposure status has separated the number from its meaning.
One dataset should not do every job. Use distinct roles:
| Partition | Who may see it | Proper use | What happens after exposure |
|---|---|---|---|
| Practice | Developers and systems | Understand the task, debug the harness, create examples | Remains useful for development; not independent evidence |
| Calibration | Evaluation owners and limited developers | Set thresholds, validate graders, estimate variance | Freeze decisions; record every use |
| Decision | Sequestered runner or independent evaluator | Support selection, release, or assurance claim | Qualify or retire affected scope after leakage |
| Sentinel | Custodian only until scheduled use | Detect drift and test future releases | Rotate slowly; never return item-level answers to development |
The public/private split in Google DeepMind's FACTS Grounding benchmark offers a concrete example: 860 examples were public and 859 were held back, with the leaderboard combining both portions. A private split reduces some exposure paths; it does not by itself control provider logs, evaluator access, similar source material, or future reuse.
Fresh operational cases add value because they represent local work and have a shorter exposure history. Freshness is not secrecy. A new question placed in a shared ticket, copied into a vendor prompt, or returned with item-level feedback can be exposed before its first formal run.
For an agent, “the model did not train on the answer” is incomplete. The evaluated system may reach it at inference time. NIST CAISI found examples of agents searching for cyber walkthroughs, inspecting newer repository versions, disabling assertions, and exploiting unintended scoring paths. The reported rates were lower bounds from observed logs, not population estimates for all agents.
Write the affordance contract before execution:
Enforce those limits outside the model. If real work requires browsing, do not disable it merely to raise cleanliness; instead use a frozen web corpus, deny known solution locations, or define the claim as performance with open-web access. The relevant comparison is between systems under declared conditions, not between hidden affordance mismatches.
The containment issues are separate from, but connected to, cyber-capable evaluation isolation: a sealed evaluation must protect both the outside world from the run and the test from unintended sources inside or outside the sandbox.
No single detector covers exact copying, paraphrase, translation, solution retrieval, repeated development tuning, and grader exploitation. Combine checks that fail differently:
A positive signal needs investigation. A negative signal only narrows what was detected. If a score falls sharply on a clean variant, possible explanations include contamination, poor robustness, a broken variant, or a distribution shift. Adjudicate the tasks before assigning a cause.
Return to the 400-question contract assistant. The evaluation owner reconstructs the exposure record:
The team does not subtract 60 questions and publish the remainder as unquestionably clean. Exposure to item-level feedback may have changed the whole configuration, and web access was part of the tested system. It takes four actions:
Suppose Model B still leads on exact fields but loses on unsupported clauses and Persian abstention. The release decision can then be scoped: Model B may draft low-risk English extractions under citation checks; it has not earned the broader claim that the original nine-point lead suggested.
The decision owner should issue a status, not an adjective.
| State | Conditions | Allowed use |
|---|---|---|
| Accept | Exposure is controlled for the claim; configuration and scoring are valid; residual limits are stated | Supports the named decision until an expiry event |
| Qualify | Bounded exposure or uncertainty remains, but unaffected evidence still supports a narrower claim | Supports only the documented slice or comparison |
| Rerun | A fresh or sequestered test can materially resolve the uncertainty | No release claim until terminal evidence arrives |
| Retire | Exposure is broad, provenance is missing, the scorer was gamed, or independence cannot be reconstructed | Historical development signal only; no current decision use |
Do not average an invalid slice into a larger score and call the effect immaterial without a predeclared analysis. Do not silently swap leaked questions after seeing results. Preserve the original report, mark its status, and create a new evaluation release.
If the result gates production, connect it to the change-control release unit. A new model, prompt, tool, corpus, judge, or access rule can expire the evidence even when the benchmark file is unchanged.
Accuracy remains necessary, but the evaluation operation needs its own measures:
Do not optimize for a zero incident count by discouraging reports. Track time to detection and correct invalidation as well. An evaluation program becomes more trustworthy when it can withdraw a score cleanly.
Before a score changes a vendor, model, or production release, ask:
A hidden test is not automatically a good test, and a public benchmark is not automatically useless. The control objective is simpler: do not let prior exposure masquerade as generalization. A score becomes trustworthy evidence only when its exposure history, execution boundary, and remaining uncertainty are attached to the decision it is asked to support.
Rare events change what an AI alert is worth. Use deployment prevalence, missed cases and review capacity to choose a threshold that your operation can actually support.
Read More
A release guide for defining who is protected, bounding contributions, accounting for repeated use, testing utility, and deciding whether a differentially private output is fit to publish.
Read More
Turn agent loops, graph orchestration, scoped retries, evidence gates, and human approval into one testable production architecture.
Read MoreIf this note maps to a real system in your organisation, start with the services page or a shipped case study.