Foundation 2: Held-Out Evaluations

Document Purpose

This paper defines the Standards Body position on held-out evaluations for frontier artificial intelligence.

It is intended to serve as:

A first-principles explanation of why some evaluation material should remain unavailable during system development
A design framework for creating, securing, administering, and governing held-out evaluations
A bridge between scientific reproducibility and necessary confidentiality
A reference for future evaluation standards, auditor requirements, research programs, and institutional partnerships
A durable source document from which shorter articles, technical specifications, and implementation guides can be derived

This paper is not a universal security standard, legal rule, or certification scheme.

It does not argue that every evaluation should be secret.

It does not claim that held-out tasks automatically produce valid results.

It establishes the principles and institutional conditions required for held-out evaluation to improve measurement rather than merely hide it.

Executive Summary

Public benchmarks have played a central role in artificial intelligence research.

They enable comparison, reproducibility, open criticism, and rapid experimentation. Public tasks often help researchers understand what systems can do, identify weaknesses, and coordinate around shared measurement.

But public visibility creates pressure on the measurement itself.

Once benchmark items, formats, answer keys, scoring rules, and common solution strategies are broadly available, they can enter:

Pretraining corpora
Fine-tuning datasets
Reinforcement-learning data
Prompt libraries
Evaluation harnesses
Synthetic data pipelines
Developer workflows
Public leaderboards
Model-generated training material

A system may then perform well because it has encountered the evaluation, close variants, or its underlying template. Even when exact exposure cannot be proven, repeated optimization against a known benchmark can weaken the connection between benchmark performance and genuine generalization.

Held-out evaluations address this problem by reserving some evaluation material from normal development access.

The reserved material may include:

Tasks
Datasets
prompts
solutions
scoring rules
attack methods
environment configurations
hidden state
evaluator interventions
sampling procedures
task generators
capability thresholds
combinations of these components

The objective is not secrecy for its own sake.

The objective is to preserve the informational value of the evaluation.

A held-out evaluation should help answer questions such as:

Can the system generalize to tasks it was not optimized against?
Does performance persist under unfamiliar but valid conditions?
Can safeguards resist attacks not seen during development?
Has a capability crossed a threshold that public tests can no longer measure reliably?
Does an independent evaluator reproduce or challenge the developer's internal findings?
Does the system behave differently when it cannot predict the test?

Held-out evaluation is not a complete solution.

A private test can still be:

Poorly designed
unrepresentative
statistically weak
insecure
biased
unfair
irreproducible
captured by the organization administering it
disconnected from deployment
overinterpreted

Confidentiality can protect measurement integrity, but it can also shield weak methods from scrutiny.

The central institutional challenge is therefore to combine protected content with inspectable process.

Standards Body adopts the following core position:

Some frontier AI evaluations should contain held-out components when public exposure would materially reduce their validity. Those components should be governed through proportionate security, independent oversight, documented provenance, controlled access, reproducible administration, transparent methodology, explicit compromise response, and clear limits on interpretation.

Held-out evaluation should be understood as a spectrum, not a binary category.

A protocol may keep private:

Only the final test items
The task bank but not the construct
The attack library but not the scoring method
The sampling seed but not the generator
The thresholds but not the evaluation family
The full evaluation until administration, followed by delayed release
The evaluation indefinitely because disclosure would create misuse risk

Different choices create different scientific and institutional tradeoffs.

A mature held-out evaluation ecosystem should distinguish at least five questions:

What is being held out?
From whom is it held out?
For how long is it held out?
What threat is the holdout intended to mitigate?
Who can independently verify that the process remains valid?

The strongest held-out systems do not rely on obscurity alone.

They use defense in depth:

Task renewal
provenance records
access controls
compartmentalization
secure execution
logging
independent review
statistical sampling
cryptographic commitments where useful
compromise detection
result expiration
formal retirement

The purpose of this foundation is to make held-out evaluation a credible scientific and institutional practice rather than an informal collection of secret test questions.

1. Foundational Proposition

1.1 Core Thesis

When public exposure would materially weaken an evaluation, some content should remain unavailable during system development and should be administered under controlled conditions.

This thesis depends on four qualifications.

First, secrecy must serve a defined measurement purpose.

Second, the protected evaluation must still satisfy scientific and institutional standards.

Third, the process must be accountable even when the content is restricted.

Fourth, held-out evidence should complement other evidence rather than become the sole basis for broad claims.

1.2 Epistemic Thesis

A held-out evaluation is valuable only to the extent that it provides information not already available through public optimization.

The information gain may come from:

Unseen tasks
new distributions
hidden adversarial strategies
unpredictable sampling
unfamiliar environments
independent administration
protected system configurations
reduced opportunity for benchmark-specific tuning

If a held-out test closely reproduces public material, its secrecy may add little.

1.3 Institutional Thesis

Maintaining a credible holdout is an institutional function, not merely a data-storage function.

It requires:

Governance
security
funding
task development
quality assurance
evaluator competence
conflict management
access procedures
incident response
archival systems
versioning
renewal
appeals
public accountability

1.4 Fairness Thesis

The more consequential the result, the stronger the obligation to provide fair notice, consistent administration, reviewable process, and a path to challenge material error.

A developer should not need access to exact tasks in order to understand:

The construct
the domain
the permitted tools
the scoring principles
the consequences
the review process
the grounds for appeal

2. Scope and Boundaries

2.1 What This Foundation Covers

This paper covers held-out components used in:

Capability evaluation
safeguard evaluation
dangerous-capability evaluation
red teaming
agent evaluation
model-behavior evaluation
robustness testing
deployment-readiness review
third-party auditing
standards conformity assessment
incident-driven evaluation
threshold evaluation
post-deployment re-evaluation

2.2 Evaluated Objects

Held-out evaluations may apply to:

Base models
fine-tuned models
deployed products
agentic systems
multimodal systems
models with tools
models with retrieval
models with memory
safety layers
monitoring systems
full sociotechnical deployments

2.3 What This Foundation Does Not Claim

This paper does not claim that:

Public benchmarks are inherently inferior
Confidentiality guarantees uncontaminated data
A private evaluator is automatically independent
A hidden test is automatically fair
Every result should remain private
Every laboratory should receive identical access in every case
Cryptography can replace governance
A passing result proves safety
Exact reproducibility is always possible
Open-source communities should be excluded
One institution should control the global evaluation supply

2.4 Relationship to Dynamic Evaluation

Held-out evaluation is closely connected to FOUNDATION_01_DYNAMIC_EVALUATION_PROTOCOLS.md.

A static private test can become stale, leak, saturate, or lose relevance.

A strong holdout therefore requires:

Rotation
renewal
versioning
contamination monitoring
expiration
retirement

2.5 Relationship to Independent Review

Held-out systems concentrate information in a smaller number of institutions.

That makes independent review more important, not less.

2.6 Relationship to Security

Security protects:

The integrity of the test
the confidentiality of sensitive content
the safety of evaluation environments
developer intellectual property
personal information
national-security-relevant material
result integrity

Security should not be used to avoid methodological scrutiny.

3. Canonical Definitions

3.1 Held-Out Evaluation

A held-out evaluation is an evaluation in which one or more material components are intentionally unavailable to the evaluated system's developer, training process, tuning process, or ordinary users before administration.

3.2 Holdout Set

A holdout set is a reserved collection of tasks, examples, environments, or observations not used for development or routine validation.

3.3 Private Benchmark

A private benchmark is a benchmark whose content is not generally available.

A private benchmark may or may not be well governed.

3.4 Confidential Evaluation

A confidential evaluation is an evaluation whose content, process, results, or combination is restricted to authorized parties.

Confidentiality can serve security, privacy, commercial, or measurement purposes.

3.5 Secret Evaluation

"Secret evaluation" is not preferred Standards Body terminology because it does not identify who is authorized, what is restricted, or why.

Use more precise terms such as:

Held-out
controlled access
confidential
restricted
embargoed
security-sensitive

3.6 Blind Evaluation

A blind evaluation restricts information from one or more participants to reduce bias or gaming.

Examples include:

Developer does not see test items
rater does not know model identity
evaluator does not know treatment condition
model receives no indication that it is being evaluated

3.7 Double-Blind Evaluation

A double-blind design restricts relevant information from both the evaluated party and the assessor where feasible.

In frontier AI evaluation, perfect double blinding is often difficult because system interfaces, behavior, or infrastructure can reveal identity.

3.8 Embargoed Evaluation

An embargoed evaluation remains restricted until a defined time or event.

3.9 Retired Holdout

A retired holdout is no longer used for active decision-making.

It may be:

Published
archived under control
partially disclosed
destroyed under policy
preserved for historical replication

3.10 Evaluation Contamination

Evaluation contamination occurs when information about the evaluation enters the development or optimization process in a way that weakens the intended separation between training and testing.

3.11 Leakage

Leakage is unauthorized or unintended disclosure of protected evaluation information.

3.12 Compromise

An evaluation is compromised when its integrity, confidentiality, validity, or fairness has been materially weakened.

3.13 Chain of Custody

Chain of custody is the documented history of who created, accessed, transferred, administered, modified, or stored evaluation materials.

3.14 Access Tier

An access tier is a defined level of authorization governing which evaluation components a party may see or use.

3.15 Controlled Evaluation Environment

A controlled evaluation environment is a technical and procedural setting designed to limit unauthorized access, data extraction, harmful action, and unlogged modification.

3.16 Attestation

Attestation is evidence used to determine whether a computing environment, code package, or security state is what it claims to be.

3.17 Cryptographic Commitment

A cryptographic commitment allows a party to commit to data or a decision before disclosure while later enabling verification that it was not altered.

3.18 Retro-Holdout

A retro-holdout is a newly created private evaluation designed to approximate the construct or distribution of an older public benchmark after the original benchmark may have become contaminated.[^retro-holdout]

4. Why Public Benchmarks Become Insufficient

4.1 Public Exposure Changes the Measurement Environment

A public benchmark is not only a neutral test.

Once it becomes influential, it becomes part of the environment that researchers and developers optimize within.

This can improve systems.

It can also reduce the benchmark's value as independent evidence.

4.2 Exact Contamination

Exact contamination occurs when evaluation items or solutions appear in training or tuning data.

The resulting score may partly reflect recall.

4.3 Semantic Contamination

A model may encounter paraphrases, transformed versions, translations, explanations, or synthetic variants.

Exact-string matching may therefore underestimate exposure.

4.4 Template Contamination

A model may learn the recurring structure of an evaluation even when individual items are new.

Examples:

Prompt format
answer schema
common distractors
scoring conventions
reasoning templates

4.5 Development Feedback Contamination

Repeated testing on the same benchmark can influence:

Checkpoint selection
model architecture
data curation
fine-tuning
system prompts
inference settings
safety tuning
tool configuration

The evaluation then becomes part of development.

4.6 Public Solution Ecosystems

Popular benchmarks often generate:

Tutorials
answer repositories
evaluation transcripts
leaderboards
benchmark-specific prompts
derivative datasets
synthetic training corpora

4.7 Benchmark Inflation

Research on retro-holdouts has reported that performance on newly constructed private analogues can reveal gaps not visible on established public benchmarks.[^retro-holdout]

This does not prove that all public benchmark scores are inflated by the same amount.

It supports the narrower conclusion that private comparison sets can reveal measurement weaknesses that public scores alone may miss.

4.8 Unknown Training Data

For closed or extremely large training pipelines, external evaluators may not know whether evaluation content was included.

A holdout created after the relevant training cutoff can reduce some forms of contamination, but it does not eliminate:

Generalization from related material
post-training exposure
developer access
template familiarity
model-generated leakage

4.9 Benchmark-Specific Optimization

Even with clean training data, developers can optimize around a known benchmark through repeated evaluation.

The resulting performance may be real, but the benchmark becomes less independent as evidence.

4.10 High-Consequence Thresholds

When a result influences:

Deployment
safeguards
access controls
insurance
procurement
regulation
national security
public claims

the cost of a misleading score increases.

Held-out components become more valuable when the consequence of false confidence is high.

5. What Held-Out Evaluation Can and Cannot Establish

5.1 What It Can Improve

A well-designed holdout can improve evidence about:

Generalization
resistance to direct benchmark optimization
unseen task performance
robustness to unfamiliar conditions
safeguard resilience
threshold crossing
independent replication
capability under controlled conditions

5.2 What It Cannot Prove

A held-out result cannot by itself prove:

Absence of dangerous capability
safe deployment
harmless intent
robustness across all environments
absence of contamination
absence of model awareness
future performance
compliance outside the test
institutional trustworthiness

5.3 Holdout Integrity Is Not Construct Validity

A perfectly secure evaluation can measure the wrong thing.

Security preserves the test as designed.

It does not establish that the design is meaningful.

5.4 Holdout Performance Is Configuration-Specific

The result depends on:

Model version
system prompt
tools
context
retries
compute
scaffold
safety layers
administrator
date

5.5 Negative Results Require Elicitation Analysis

Failure on a held-out task may mean:

Capability is absent
capability is present but poorly elicited
the task is invalid
the environment failed
the scoring is wrong
the system refused
the scaffold is inadequate
the model detected evaluation conditions
stochasticity affected the run

5.6 Positive Results Require Deployment Analysis

Success under a privileged evaluator configuration may not imply the same capability is available in normal use.

5.7 Complementarity

Held-out evaluation should be combined with:

Public benchmarks
dynamic protocols
expert review
operational evidence
incident analysis
mechanistic evidence
post-deployment monitoring
developer disclosure

6. Taxonomy of Held-Out Designs

6.1 Fully Private Fixed Test Set

A fixed set remains confidential.

Advantages:

Simple administration
stable comparison
clear chain of custody

Risks:

Leakage
saturation
stale content
insider optimization
small task supply

6.2 Rotating Private Test Set

Tasks are replaced periodically.

Advantages:

Reduced long-term exposure
adaptation
compromise recovery

Risks:

comparability
cost
governance burden

6.3 Private Item Bank with Random Sampling

The administrator samples from a larger protected bank.

Advantages:

Reduced predictability
repeated administration
statistical sampling

Risks:

bank compromise
uneven forms
calibration requirements

6.4 Procedurally Generated Holdout

Tasks are generated from protected rules, seeds, or environments.

Advantages:

Scale
renewal
reduced item reuse
adjustable difficulty

Risks:

generator leakage
artificial tasks
exploitable generator regularities
validation burden

6.5 Post-Cutoff Evaluation

Tasks are based on information created after the presumed training cutoff.

Advantages:

Reduces exact pretraining contamination
supports current-knowledge testing

Risks:

training cutoff uncertainty
retrieval access
recent-data noise
nonrepresentative sampling

LiveBench and related dynamic approaches illustrate this family of contamination-limited evaluation.[^livebench]

6.6 Event-Sourced Holdout

Tasks are derived from recent:

Incidents
competitions
software changes
scientific findings
professional cases
legal developments

Advantages:

Current relevance
authenticity

Risks:

uneven difficulty
event bias
incomplete coverage

6.7 Expert-Authored Confidential Evaluation

Domain experts create protected tasks.

Advantages:

Domain realism
nuanced scoring
high-stakes relevance

Risks:

cost
expert bias
limited scale
insider leakage
consistency challenges

The UK AI Security Institute has described structured processes for developing frontier question-answer evaluations, including expert involvement, question design, quality review, and controlled administration.[^aisi-qa]

6.8 Adversarial Holdout

Evaluators create or select attacks intended to expose weaknesses.

Useful for:

Safeguards
cyber capability
model control
policy compliance
deception
robustness

Risk:

Worst-case findings may be difficult to translate into prevalence or ordinary-use risk.

6.9 Hidden Environment Evaluation

The system operates in an environment with hidden:

State
objectives
tests
adversaries
monitoring
success criteria

Useful for agents.

Risk:

Environment artifacts can dominate performance.

6.10 Delayed-Release Evaluation

Tasks remain private during active use and become public later.

Advantages:

Eventual reproducibility
scientific learning
public accountability

Risks:

Future contamination
sensitive content exposure
limited value for repeated testing

6.11 Split-Knowledge Evaluation

No single party holds all sensitive components.

For example:

One party holds tasks
one holds model access
one administers infrastructure
one scores outputs
one audits logs

Advantages:

Reduced unilateral control
stronger compromise resistance

Risks:

Coordination
inconsistent responsibility
more attack surfaces

6.12 Secure Remote Evaluation

The model is evaluated in a controlled environment without transferring model weights or test data broadly.

Advantages:

Protects both developer IP and evaluator content

Risks:

Integration difficulty
limited observability
infrastructure trust
attestation complexity

6.13 Developer-Blind, Evaluator-Known

The evaluator knows the tasks, while the developer does not.

Common and practical.

Risk:

Evaluator compromise.

6.14 Developer-Known, Model-Blind

The developer knows the broad evaluation but the model cannot access protected task metadata or external leakage channels.

Useful in agent sandboxes.

Risk:

The model may infer the evaluation context.

6.15 Double-Blind Model Comparison

Raters do not know which system produced outputs.

Useful for reducing brand and expectation bias.

It does not address training contamination.

6.16 Hybrid Holdout

A mature protocol may combine:

Public construct definition
stable public anchors
rotating private tasks
protected attack library
independent administration
delayed task release
post-deployment monitoring

7. The Holdout Threat Model

A credible holdout begins with a threat model.

7.1 Assets to Protect

Assets may include:

Task text
solutions
scoring rubrics
generator code
sampling seeds
item difficulty
attack strategies
system prompts
evaluator identities
thresholds
model outputs
vulnerability findings
access credentials
environment images
result timing

7.2 Adversaries and Failure Sources

Threats may come from:

Malicious outsiders
insider actors
compromised vendors
developers seeking an advantage
evaluators seeking influence
accidental disclosure
model extraction behavior
insecure tooling
public repositories
logs
backups
collaboration platforms
generated reports
legal discovery
supply-chain compromise

A threat model should not assume malicious developers by default.

Many failures arise from ordinary operational mistakes.

7.3 Threat Goals

A threat actor may seek to:

Obtain test content
infer task families
alter scoring
substitute a model
change configuration
remove unfavorable runs
identify thresholds
manipulate judges
exfiltrate secrets
delay publication
falsely claim a pass
discredit the evaluation
expose harmful content

7.4 Attack Surfaces

Potential surfaces include:

Task-author devices
email
cloud storage
source control
evaluation harness
API traffic
model logs
sandbox
human raters
annotation platform
report drafting
backups
third-party vendors
remote access
conference presentations
retired-task archives

7.5 Model as an Active Participant

Advanced systems may:

Probe the environment
inspect files
infer evaluation context
exploit tools
search for hidden data
manipulate raters
encode information in outputs
attempt sandbox escape
identify scoring vulnerabilities

AISI research has examined what sandboxed agents can infer about evaluation environments and how container isolation should be assessed.[^aisi-sandbox-learning][^aisi-breakout]

7.6 Security Objectives

A held-out system may seek:

Confidentiality
integrity
availability
provenance
non-repudiation
controlled disclosure
recoverability
auditability
least privilege

7.7 Residual Risk

No holdout should be described as perfectly secure.

The threat model should state residual risk and assumptions.

8. Design Principles

8.1 Purpose-Limited Confidentiality

Restrict only what must be restricted to preserve validity, safety, privacy, or legitimate proprietary interests.

8.2 Transparent Construct

The capability, risk, or behavior being evaluated should normally be public or reviewable.

8.3 Fair Notice

Participants should know the general domain, administration rules, and decision consequences.

8.4 Independent Verification

A qualified party not controlled by the primary developer should be able to verify material aspects of the process.

8.5 Defense in Depth

Do not rely on one control.

Combine:

People
process
technology
governance
renewal

8.6 Least Privilege

Each participant receives only the access needed for their role.

8.7 Separation of Duties

Task creation, administration, scoring, approval, and appeals should be separated where consequence warrants it.

8.8 Provenance

Every task should have a documented origin and modification history.

8.9 Reproducible Administration

The same protocol should be administrable by qualified evaluators under controlled conditions.

8.10 Calibrated Disclosure

Disclosure should be sufficient for accountability without destroying the test.

8.11 Time-Bounded Authority

Held-out results should expire, be renewed, or be retired.

8.12 Compromise Readiness

The protocol should assume that some protected content will eventually leak.

8.13 Accessibility

Security should not unnecessarily exclude smaller qualified evaluators, researchers, or open-source communities.

8.14 Non-Exclusivity

No single private test should become the only accepted measure of a broad capability.

8.15 Contestability

Material errors and procedural failures should be appealable.

8.16 Proportionate Security

Security investment should reflect:

Consequence
sensitivity
replacement cost
misuse potential
likelihood of attack
duration of intended use

8.17 No Security Theater

Complex controls should not substitute for sound evaluation design.

9. What Should Be Held Out

A protocol should specify the minimum necessary protected surface.

9.1 Test Items

Protect when exact exposure would enable memorization or targeted tuning.

9.2 Solutions and Rubrics

Protect when answers reveal task construction or enable reverse engineering.

9.3 Sampling Rules

Protect when predictability allows developers to narrow preparation to a small subset.

9.4 Task Generators

Protect when access would enable generation of near-identical training data.

9.5 Attack Libraries

Protect when disclosure would:

Reduce safeguard-test value
expose vulnerabilities
enable misuse
reveal monitoring gaps

9.6 Thresholds

Threshold confidentiality is controversial.

Potential rationale:

Prevent cliff-edge gaming
preserve blinded assessment

Potential harms:

Reduced fairness
weak accountability
arbitrary decision-making

Standards Body position:

Decision thresholds should normally be disclosed at least in principle. Temporary restriction may be justified in narrow cases, but hidden thresholds should not become the default for consequential decisions.

9.7 Environment Details

Some hidden state can test generalization.

Core administration conditions should still be documented.

9.8 Model Identity

Raters may be blinded to model identity to reduce bias.

9.9 Results

Result embargo may be justified for:

Developer verification
security remediation
coordinated disclosure
legal review
peer review

Indefinite suppression requires stronger justification.

9.10 Evaluator Identity

Evaluator identity may need protection in sensitive work.

Governance should still verify competence and conflicts.

10. Task Development and Provenance

10.1 Task Specification

Each task should include:

Identifier
construct mapping
domain
difficulty
author
creation date
source
expected solution
scoring
validation status
security classification
contamination risk
retirement status

10.2 Source Categories

Tasks may come from:

Original expert authorship
public sources transformed after cutoff
real incidents
professional workflows
simulations
procedural generators
controlled data partnerships
adversarial discovery
user research
synthetic generation with expert validation

10.3 Provenance Risks

Risks include:

Copyright
personal data
trade secrets
dual-use content
hidden public duplicates
author conflict
incorrect solutions
unverifiable source
contaminated generation model

10.4 Model-Generated Tasks

Models can help generate tasks, but the protocol should record:

Generator model
version
prompts
source material
human review
filtering
contamination concerns
validation

A model trained on public benchmarks may reproduce benchmark-like tasks or solutions.

10.5 Expert Validation

Expert review should assess:

Correctness
relevance
ambiguity
realism
difficulty
safety
scoring
construct coverage

10.6 Independent Replication of Solutions

High-consequence tasks should have more than one qualified solution review where feasible.

10.7 Task Families

Organize tasks into families so coverage can be evaluated.

10.8 Item Exposure Accounting

Each administration should update:

Exposure count
parties with access
models tested
transcripts generated
disclosure events
estimated residual value

10.9 Retirement Conditions

Retire a task when:

It leaks
it saturates
its solution becomes obsolete
its environment changes
its validity fails
exposure becomes excessive
safety risk changes
it is superseded

11. Statistical Design and Sampling

11.1 The Task Population

A held-out set should represent a defined population, not merely a collection of difficult questions.

11.2 Sampling Plan

Specify whether sampling is:

Random
stratified
adaptive
risk-weighted
difficulty-balanced
scenario-based
purposive
exhaustive

11.3 Sample Size

Sample size should reflect:

Expected variance
desired precision
threshold consequence
task cost
model stochasticity
subgroup analysis
failure rarity

11.4 Repeated Runs

Repeated runs may estimate:

Reliability
success probability
stochastic variance
sensitivity to prompts
tail behavior

They also increase exposure.

11.5 Form Equivalence

If different participants receive different forms, the protocol should assess:

Difficulty equivalence
coverage
scoring
subgroup effects

11.6 Threshold Evaluation

Near a threshold:

Increase sample size
use independent replication
report confidence
avoid deterministic classification where evidence is weak
consider conservative interim status

11.7 Human Baselines

Human comparison should specify:

Expertise
tools
time
compensation
selection
sample size
scoring
assistance

11.8 Missing Data

Define treatment of:

Timeouts
refusals
infrastructure failures
invalid tasks
missing logs
aborted runs

11.9 Item-Level Records

NIST has emphasized the value of richer item-level analysis and statistical modeling because aggregate benchmark scores can hide uncertainty and assumptions.[^nist-statistical]

Held-out systems should retain item-level evidence under appropriate controls.

11.10 Avoiding Unjustified Precision

A private score is not more precise merely because the tasks are secret.

12. Security Architecture

12.1 Security Classification

Each component should be classified by sensitivity.

Example levels:

Public
internal
controlled research
confidential evaluation
restricted security
highly restricted

12.2 Identity and Access Management

Controls may include:

Named accounts
multi-factor authentication
role-based access
time-limited credentials
device requirements
geographic restrictions
approval workflows
periodic access review

12.3 Data at Rest

Use:

Encryption
key management
backup policy
access logging
retention controls
secure deletion
compartmentalization

12.4 Data in Transit

Use:

Authenticated encrypted channels
endpoint verification
transfer logging
restricted export

12.5 Data in Use

Conventional encryption does not protect data while actively processed.

Confidential computing uses hardware-based, attested trusted execution environments to protect data in use.[^ccc-technical]

Potential use cases include:

Running protected tasks against proprietary models
limiting administrator visibility
producing attestable execution records
supporting multi-party evaluation

Limitations include:

Hardware trust assumptions
side channels
implementation vulnerabilities
limited accelerator support
operational complexity
attestation interpretation
cost

12.6 Sandboxing

Agentic evaluations may require isolated environments.

AISI has released sandboxing tools for Inspect and has emphasized that sandbox selection should match the threat model.[^aisi-sandbox]

A sandbox is not automatically secure.

Validate:

Isolation boundary
network policy
filesystem
credentials
host access
logging
escape resistance
cleanup

12.7 Secure Logging

Logs should support:

Reproducibility
investigation
scoring
anomaly detection
appeals

Logs can themselves expose tasks or sensitive model behavior.

12.8 Endpoint Security

Task-author and evaluator devices are common weak points.

12.9 Vendor Risk

Third-party platforms should be assessed for:

Data access
subcontractors
training use
retention
breach notification
jurisdiction
deletion
model access

12.10 Backup and Recovery

A secure system should recover from:

Data loss
ransomware
accidental deletion
corrupted task bank
key loss
service outage

12.11 Destruction

Secure deletion may be appropriate for:

Temporary exports
expired access packages
sensitive intermediate files

Permanent destruction should not eliminate necessary audit records.

13. Access-Control Models

13.1 Tier 0: Public Access

Available:

Construct
methodology
governance
summary results
limitations
version history

13.2 Tier 1: Registered Research Access

Available:

Task taxonomy
selected retired items
validation materials
limited reference data

13.3 Tier 2: Qualified Evaluator Access

Available:

Active tasks
scoring tools
administration environment
controlled logs

Requirements:

Competence
conflict disclosure
security controls
agreement
monitoring

13.4 Tier 3: Domain-Sensitive Access

For:

Cyber
biology
critical infrastructure
other dual-use domains

Additional requirements:

Domain qualification
stronger security
need-to-know
incident obligations
legal review

13.5 Tier 4: Custodian Access

Limited personnel with authority over:

Full task bank
keys
generators
compromise response
archival systems

13.6 Developer Access

Developers may receive:

Broad scope
interface
configuration requirements
output format
process rights
limited debugging support

They should not receive active items unless the protocol explicitly requires collaborative testing.

13.7 Temporary Debug Access

Integration failures sometimes require developer visibility.

Use:

Synthetic tasks
public shadow tasks
retired items
narrowly scoped traces
supervised sessions

Avoid exposing active holdouts merely to solve ordinary integration problems.

13.8 External Researcher Access

Structured external access can improve critique and innovation.

Recent work on external access distinguishes dimensions such as model access, information access, and evaluation time as separate determinants of evaluator effectiveness.[^external-access]

14. Chain of Custody

14.1 Required Events

Record:

Creation
review
approval
classification
storage
transfer
access
modification
administration
scoring
export
publication
retirement
destruction

14.2 Minimum Record

Each event should include:

Person or system
date and time
purpose
material
action
authorization
location
integrity check
anomaly

14.3 Task Packaging

Evaluation packages should have:

Unique identifiers
hashes
version
manifest
expected files
signature or authenticated provenance

14.4 Pre-Administration Verification

Confirm:

Correct model
correct protocol version
correct environment
intact task package
approved access
logging
time synchronization
no unauthorized files

14.5 Post-Administration Verification

Confirm:

Complete logs
task integrity
scoring package
deviations
data transfer
cleanup
access revocation

14.6 Separation of Evidence

Preserve:

Raw outputs
scored outputs
adjudicated results
final report

Do not overwrite original evidence.

15. Administration Protocol

15.1 Pre-Registration

Before seeing results, record:

Scope
configuration
tasks or sampling method
scoring
thresholds
exclusion rules
retry policy
adjudication
publication plan

The exact tasks may remain private.

15.2 Model Verification

Confirm the evaluated system identity through available methods.

15.3 Configuration Lock

Document and, where possible, lock:

System prompt
tools
sampling
context
safety settings
model endpoint
scaffold
compute budget

15.4 Dry Run

Use non-active tasks to test integration.

15.5 Active Run

Apply:

Authorized personnel
monitoring
incident procedures
deviation logging
access controls

15.6 Transcript Review

NIST guidance on evaluation cheating emphasizes transcript review as a way to detect cheating, integration problems, tool issues, and task failures.[^nist-cheating]

Transcript review should combine:

Automated screening
targeted human review
anomaly investigation
documented adjudication

15.7 Scoring

Use the pre-specified method.

Any post-hoc scoring change should be recorded and justified.

15.8 Adjudication

Ambiguous cases may require:

Second rater
domain expert
blind review
appeals panel

15.9 Developer Notification

Before public release, the developer may be given a limited period to identify:

Configuration errors
factual errors
security concerns
proprietary disclosures

The developer should not receive veto authority over unfavorable findings.

15.10 Publication

Publish according to the disclosure plan.

16. Scoring, Uncertainty, and Reporting

16.1 Score Types

Possible outputs include:

Accuracy
success probability
severity-weighted failure
pass band
capability tier
safeguard bypass rate
time-to-completion
cost
calibrated confidence
qualitative finding

16.2 Hidden Scoring Rules

Hidden scoring rules can reduce gaming but weaken fairness.

Preferred approach:

Public scoring principles
protected item-specific answers
protected adversarial details where justified

16.3 Model Judges

Model judges may reduce cost.

They require validation for:

Bias
consistency
sensitivity
model-family favoritism
prompt injection
manipulation
domain competence

16.4 Human Raters

Human scoring should document:

Qualification
training
rubric
blinding
agreement
compensation
conflicts

16.5 Uncertainty Sources

Include:

Sampling
stochasticity
scoring
task ambiguity
configuration
environment
missing data
contamination
judge error

16.6 Result Bands

Use bands or ranges when point estimates imply unjustified certainty.

16.7 Public Reporting Minimum

A public report should include:

Protocol name
version
date
evaluator
system
configuration
construct
task categories
sampling
scoring
uncertainty
limitations
deviations
conflicts
result status
expiration
disclosure restrictions

16.8 Private Technical Annex

A controlled annex may include:

Item-level results
transcripts
vulnerabilities
scorer details
task provenance
security incidents

16.9 Claims Boundary

State what the result cannot establish.

17. Reproducibility Without Full Disclosure

17.1 Exact Public Reproduction

Useful but not always compatible with a live holdout.

17.2 Controlled Reproduction

A qualified independent evaluator reruns the protocol under controlled access.

17.3 Method Reproduction

Researchers recreate the method using different tasks.

17.4 Result Verification

An auditor verifies:

Model identity
task integrity
execution
scoring
report

without receiving unrestricted task access.

17.5 Delayed Reproduction

Tasks are released after retirement.

17.6 Cryptographic Verification

Potential tools include:

Hash commitments
signed manifests
timestamping
attestation
reproducible build records
tamper-evident logs

These can show that materials were not changed after commitment.

They do not establish:

Task validity
fairness
correct interpretation
absence of hidden selection bias

17.7 Multi-Party Verification

Several institutions can independently verify parts of the process.

17.8 Replication Package

A controlled replication package can include:

Protocol
environment
scoring code
public sample tasks
retired tasks
access process
validation report
expected behavior

18. Transparency and Confidentiality

18.1 False Choice

The choice is not between total secrecy and total openness.

A protocol can protect test content while disclosing:

Purpose
construct
governance
funding
methods
access policy
validation
limitations
change history
result summary

18.2 Transparency Layers

Layer A: Constitutional Transparency

Why the holdout exists and what principles govern it.

Layer B: Methodological Transparency

How tasks are created, sampled, scored, and validated.

Layer C: Procedural Transparency

Who administers, reviews, approves, and hears appeals.

Layer D: Evidentiary Transparency

What evidence supports the result.

Layer E: Content Transparency

The exact tasks, solutions, and attack methods.

Content transparency may be delayed or restricted.

18.3 Justification Record

For every restricted category, record:

What is restricted
why
authority
duration
who can review
disclosure trigger
appeal

18.4 Public Summary of Restricted Findings

When detailed disclosure is unsafe, publish:

High-level finding
evidence category
confidence
decision relevance
mitigation status
independent-review status

18.5 Transparency Failure

A protocol fails transparency when outsiders cannot distinguish:

Strong evidence from assertion
valid security restrictions from convenience
independent review from internal approval
current results from expired results

19. Fairness and Access

19.1 Procedural Fairness

Participants should receive consistent:

Rules
timelines
configuration requirements
scoring
appeal rights
confidentiality
publication treatment

19.2 Unequal Resources

Large laboratories may have:

Better elicitation teams
more compute
direct evaluator relationships
faster integration
specialized legal and security staff

The protocol should report developer assistance and resource differences.

19.3 Open-Source and Open-Weight Participation

Open communities may lack one legal entity or centralized developer.

Possible approaches:

Community-nominated representative
independent evaluator runs
public configuration track
controlled access without privileged developer support
transparent asymmetry statement
subsidized testing

Open-source representation should not be symbolic.

Experts should have meaningful participation in:

Construct design
task review
access policy
result interpretation
governance

19.4 Small Evaluator Participation

Security requirements can unintentionally create a closed market.

Options:

Shared secure facilities
standardized environments
grants
tiered accreditation
supervised access
federated evaluation
pooled infrastructure

19.5 Geographic Access

International participation may be limited by:

Export controls
privacy law
security clearance
sanctions
data localization
language
funding

These constraints should be explicit.

19.6 Disability and Language

Task design should distinguish the intended construct from irrelevant accessibility barriers.

19.7 Fairness Does Not Mean Identical Treatment

Different systems may require different integration.

The reasons should be documented.

20. Developer and Evaluator Relationship

20.1 Necessary Cooperation

Developers may need to provide:

Model access
configuration
safety information
technical support
system limitations
training cutoff
tool documentation
risk analysis

20.2 Independence Risks

Dependence can arise through:

Funding
access
infrastructure
publication approval
legal restrictions
repeated contracts
personnel relationships

20.3 Recommended Agreement Terms

Cover:

Scope
access
confidentiality
data handling
evaluator independence
publication
developer review period
no result veto
incident handling
IP
liability
termination
audit
dispute

20.4 Developer Challenge Process

Developers should be able to present evidence concerning:

Configuration
invalid tasks
scoring
environment failures
interpretation
security

20.5 No Benchmark Coaching

Evaluator support should solve integration problems without teaching active test content.

20.6 External Testing

OpenAI has described structured external testing and subject-matter-expert probing as complements to internal Preparedness Framework evaluations.[^openai-external]

Google DeepMind's early-warning proposal similarly envisioned structured access for external safety researchers and auditors.[^deepmind-warning]

Anthropic's 2026 Responsible Scaling Policy revisions formalized external review under specified governance conditions.[^anthropic-rsp]

These examples reflect a broader movement toward combining developer evaluation with external scrutiny. They do not yet establish a common external-access standard.

21. Governance

21.1 Governing Principle

The institution controlling the holdout should not possess unreviewable authority over:

Task selection
scoring
result interpretation
disclosure
appeals
compromise determination

21.2 Roles

A mature system may include:

Protocol sponsor
task-development lead
domain panel
security custodian
evaluation administrator
scoring team
independent review panel
appeals panel
archive custodian
public-interest representative
open-source representative
developer liaison

21.3 Separation of Duties

For high-consequence evaluations:

Task author should not unilaterally score
administrator should not unilaterally approve
funder should not control publication
developer should not control active tasks
security custodian should not determine scientific validity alone

21.4 Conflict Disclosure

Disclose:

Employment
consulting
funding
equity
research collaboration
competitive interest
policy advocacy
prior disputes
intellectual commitments

21.5 Recusal

Material conflicts may require recusal.

21.6 Dissent

Allow:

Minority technical reports
unresolved issue register
alternative interpretations
publication of disagreement where security permits

21.7 Appeals

Appeals should be:

Time-bounded
evidence-based
reviewed by qualified people not responsible for the original decision
documented
capable of correcting error

21.8 Funding

Funding sources should be disclosed.

No payer should obtain:

Task access beyond role
result suppression
favorable scoring
unilateral change authority
exclusive ownership of a public-interest protocol

21.9 Oversight

Oversight can include:

Board committee
independent council
public auditor
government institute
multi-institution consortium
accreditation body

21.10 Governance Review

Review governance after:

Major leak
disputed result
funding change
personnel concentration
protocol expansion
international adoption

22. Compromise Detection and Response

22.1 Signs of Possible Compromise

Indicators include:

Unexplained performance jump
exact solution reproduction
suspicious phrasing
benchmark-specific behavior
unusual access logs
unauthorized downloads
model probing of hidden files
leaked task fragments
employee report
public appearance of content
hash mismatch
missing logs
changed scoring code

22.2 Detection Methods

Possible methods:

Transcript review
similarity analysis
canary tasks
access analytics
file-integrity monitoring
red-team testing
audit
developer disclosure
environment monitoring
controlled replication

22.3 Initial Response

Preserve evidence
restrict access
pause administration if necessary
notify security and protocol owners
assess scope
avoid premature public accusation

22.4 Investigation

Determine:

What was exposed
when
to whom
how
which results are affected
whether scoring changed
whether the model may have encountered content
whether the task bank remains usable

22.5 Result Status

Possible statuses:

Valid
valid with caveat
under review
suspended
withdrawn
superseded
invalid

22.6 Remediation

Options:

Replace items
rotate bank
revise generator
re-evaluate
change access
patch infrastructure
retrain personnel
disclose incident
retire protocol

22.7 Public Notice

A public notice should state enough to prevent continued misuse of invalid results.

22.8 Learning Review

Every material compromise should generate:

Root-cause analysis
corrective action
governance review
update to FAILURE_DATABASE.md
update to VERSION_HISTORY.md

23. Lifecycle of a Held-Out Evaluation

Stage 1: Need Identification

Determine why public evaluation is insufficient.

Output:

Holdout justification

Stage 2: Threat Modeling

Identify:

Assets
adversaries
exposure paths
security objectives
residual risk

Output:

Threat model

Stage 3: Construct Design

Define:

Capability
subdomains
task universe
decision use
exclusions

Output:

Construct map

Stage 4: Governance Charter

Define:

Owner
roles
conflicts
access
appeals
publication
funding

Output:

Charter

Stage 5: Task Development

Create:

Items
generators
environments
scoring
provenance

Output:

Candidate bank

Stage 6: Validation

Assess:

Correctness
difficulty
coverage
reliability
fairness
security
contamination

Output:

Validation report

Stage 7: Security Build

Implement:

Classification
access
storage
execution
logging
incident response

Output:

Security plan

Stage 8: Pilot

Run on:

Reference systems
human baselines
controlled configurations

Output:

Pilot report

Stage 9: Independent Review

Review:

Science
security
fairness
governance
interpretation

Output:

Review and response

Stage 10: Approval

Authorize a version for defined use.

Stage 11: Administration

Conduct controlled evaluation.

Stage 12: Reporting

Issue public and restricted outputs.

Stage 13: Monitoring

Track:

Exposure
leakage
saturation
validity
disputes
cost
result use

Stage 14: Renewal

Add, replace, or recalibrate tasks.

Stage 15: Retirement

Withdraw active authority and archive appropriately.

24. Specialized Domains

24.1 Cybersecurity

Held-out cyber evaluations may protect:

Vulnerabilities
target environments
credentials
attack chains
scoring triggers
defensive configurations

Requirements may include:

Sandboxing
network isolation
safe targets
logging
exploit handling
responsible disclosure
domain experts

AISI's Inspect Cyber work provides standardized infrastructure for agentic cyber evaluations.[^inspect-cyber]

24.2 Biology and CBRN

Held-out biological evaluation may involve:

Sensitive knowledge
expert judgment
safe proxies
access controls
staged disclosure
institutional biosafety review

Task design should avoid creating harmful operational guidance unnecessarily.

NIST work on AI-assisted protein design has used safe biological proxies as part of a TEVV approach, illustrating how evaluation design can reduce experimental risk while investigating relevant capability.[^nist-protein]

24.3 Autonomous Agents

Held-out agent evaluation may protect:

Environment state
objectives
monitoring
credentials
adversarial events
task sequence

Security should account for active model attempts to inspect or escape the environment.

24.4 Safeguard Evaluation

Protecting attack methods can preserve test value and reduce misuse.

AISI's principles for evaluating misuse safeguards emphasize threat modeling, representative attacks, and careful interpretation.[^aisi-safeguards]

24.5 Persuasion and Human Interaction

Tasks may involve human subjects, private conversations, or experimental conditions.

Additional requirements:

Consent
privacy
ethics review
de-identification
secure retention
human-risk monitoring

24.6 Critical Infrastructure

Evaluation may require simulated or digital-twin environments rather than live systems.

24.7 Scientific Capability

Held-out tasks should distinguish:

Knowledge recall
hypothesis quality
experimental design
tool use
result interpretation
real-world validation

25. Technical Options for Protected Evaluation

25.1 Secure API Evaluation

Evaluator sends tasks to a controlled model endpoint.

Benefits:

Developer retains model control
limited integration

Risks:

Developer may observe tasks
endpoint may differ from evaluated model
logs may leak content

25.2 Evaluator-Controlled Deployment

Model is deployed in evaluator infrastructure.

Benefits:

Strong evaluator control
richer observability

Risks:

Weight transfer
IP
security
hardware requirements

25.3 Joint Secure Facility

Developer and evaluator operate within a controlled facility.

Benefits:

Shared trust
direct troubleshooting

Risks:

Cost
scheduling
personnel access

25.4 Trusted Execution Environment

Protected computation can reduce the need for either party to expose all assets.

Attestation can help verify the environment.[^ccc-attestation]

Limitations must be assessed case by case.

25.5 Cryptographic Commitments

Commit to:

Task bank
sampling seed
scoring code
threshold
report draft

before administration or disclosure.

25.6 Secure Multi-Party Computation

Potentially allows computation across parties without revealing all inputs.

Current practicality depends on workload and implementation.

25.7 Homomorphic Encryption

Potentially enables computation on encrypted data.

It may be too costly or limited for many frontier model evaluations.

25.8 Federated Evaluation

Tasks remain with custodians while systems or outputs move through controlled interfaces.

25.9 Remote Desktop or Clean Room

Authorized personnel work in a monitored environment without unrestricted export.

25.10 Air-Gapped Evaluation

Useful for highly sensitive content, but operationally expensive and not immune to insider risk.

25.11 Technical Neutrality

Standards Body should specify desired security properties rather than prematurely mandating one technology.

26. International Interoperability

26.1 Cross-Border Challenge

Evaluation materials may cross:

Legal regimes
privacy systems
export controls
security classifications
languages
professional standards

26.2 Shared Metadata

Institutions should align on:

Protocol identifier
version
construct
task category
access tier
evaluator qualification
result status
compromise status
expiration
confidence

26.3 Mutual Recognition

One institution may recognize another's result when there is confidence in:

Competence
security
governance
methodology
administration
reporting
appeals

26.4 Distributed Custody

Different national institutes may hold different task subsets.

Advantages:

Reduced single-point compromise
regional expertise
resilience

Risks:

Form equivalence
geopolitical distrust
inconsistent access
coordination

26.5 Shared Retired Banks

Retired tasks can support international research without exposing active holdouts.

26.6 No Forced Centralization

Interoperability should not require one global task bank controlled by one institution.

26.7 Institute Cooperation

International AI safety and security institutes have increasingly collaborated on evaluation practices and research. Such cooperation can support shared methods while preserving national authority.

27. Maturity Model

Level 0: Informal Private Test

Characteristics:

Private questions
no formal governance
weak provenance
no access record
no compromise plan

Use:

Internal exploration only

Level 1: Documented Holdout

Characteristics:

Defined purpose
named owner
task records
basic access controls
versioning
scoring

Use:

Research validation

Level 2: Controlled Held-Out Protocol

Characteristics:

Threat model
chain of custody
validated tasks
reproducible administration
uncertainty
result expiration
compromise response

Use:

Serious organizational decisions

Level 3: Independently Reviewed Secure Evaluation

Characteristics:

Separation of duties
independent review
formal security
appeals
controlled replication
rotating task bank
public methodology

Use:

High-stakes pre-deployment decisions

Level 4: Interoperable Evaluation Ecosystem

Characteristics:

Multiple qualified evaluators
shared metadata
mutual recognition
accreditation
international coordination
distributed custody
incident exchange
formal retirement

Use:

Mature standards and conformity-assessment ecosystem

28. Implementation Pathway

Phase 1: Select the Decision

Start with a specific question.

Example:

"Does this system demonstrate a defined level of long-horizon cyber capability under controlled tool access?"

Phase 2: Justify the Holdout

Explain why public tests are insufficient.

Phase 3: Build the Construct Map

Define subcapabilities and exclusions.

Phase 4: Create Governance

Assign roles, conflicts, access, and appeals.

Phase 5: Develop the Threat Model

Identify leakage and active-agent risks.

Phase 6: Build the Task Bank

Use multiple task sources.

Phase 7: Validate

Test tasks with experts, reference models, and human baselines.

Phase 8: Build Secure Infrastructure

Implement access, logging, packaging, and incident response.

Phase 9: Pilot

Run on non-consequential reference systems first.

Phase 10: Independent Review

Review science and security separately.

Phase 11: Launch

Publish methodology and access rules.

Phase 12: Monitor Exposure

Track every use.

Phase 13: Rotate

Replace tasks based on exposure and evidence.

Phase 14: Audit the Holdout

Evaluate whether the holdout remains worth its cost and authority.

29. Proposed Standards Body Pilot

29.1 Candidate Pilot

Held-Out Evaluation Protocol for Long-Horizon Technical Agent Tasks

This would complement the pilot proposed in Foundation 1.

29.2 Purpose

Measure whether AI agents can complete unfamiliar, verifiable technical tasks without prior access to the active task set.

29.3 Public Components

Construct
task taxonomy
administration rules
scoring principles
governance
result format
limitations

29.4 Held-Out Components

Active tasks
reference solutions
sampling seed
selected environment details
adversarial variants

29.5 Task Sources

Expert-authored software tasks
newly created repositories
procedural variants
recent dependency changes
incident-derived repair tasks

29.6 Security

Controlled repository access
isolated execution
no public network unless required
signed task packages
complete logging
task exposure accounting

29.7 Evaluation Tracks

Standard Track

Common evaluator-defined scaffold.

Developer-Elicited Track

Developer proposes configuration without task access.

Independent Optimization Track

Evaluator attempts stronger elicitation.

29.8 Outputs

Protocol
threat model
task-development manual
security plan
pilot results
exposure ledger
compromise exercise
public methodology
controlled replication package

29.9 Success Criteria

Low evidence of contamination
reliable scoring
useful difficulty spread
reproducible administration
fair integration
manageable cost
credible external review
clear result limits

30. Metrics for Evaluating the Holdout System

30.1 Integrity Metrics

Unauthorized access events
leaked items
hash mismatches
unexplained task changes
compromised results
access-review findings

30.2 Measurement Metrics

Discrimination
reliability
coverage
uncertainty
human agreement
external validity
public-private score gap

30.3 Exposure Metrics

Number of administrations
number of viewers
model families tested
transcript copies
retired-item rate
residual item value

30.4 Operational Metrics

Cost
administration time
integration failure
evaluator burden
security burden
task-development throughput

30.5 Fairness Metrics

Access approvals
approval time
participation by smaller actors
geographic participation
appeals
form-equivalence findings

30.6 Governance Metrics

Conflict disclosures
recusals
independent reviews
unresolved dissent
funder concentration
change-record completeness

30.7 Decision Utility

Decisions informed
errors corrected
false confidence avoided
correlation with later evidence
result misuse
user understanding

31. Failure Modes and Safeguards

31.1 Secret but Invalid

Failure: The test is confidential but poorly designed.

Safeguard: Independent validity review and public construct explanation.

31.2 Single-Point Custodian

Failure: One person controls the full bank and scoring.

Safeguard: Separation of duties and access logging.

31.3 Permanent Holdout

Failure: The same private set is reused until it becomes stale or informally known.

Safeguard: Exposure limits, rotation, expiration.

31.4 Security as Authority

Failure: Maintainers dismiss criticism by citing confidentiality.

Safeguard: Controlled independent audit and public methodological disclosure.

31.5 Developer Capture

Failure: Access dependence gives the developer control over findings.

Safeguard: Contractual independence, diversified access, no result veto.

31.6 Evaluator Capture

Failure: A private evaluator benefits from making its test indispensable.

Safeguard: Multiple evaluators, protocol registry, interoperability, review.

31.7 Unequal Form Difficulty

Failure: Participants receive materially different tests.

Safeguard: Calibration, bridging, reference systems, uncertainty.

31.8 Task-Bank Leakage

Failure: Active content enters public or training systems.

Safeguard: Compromise plan, rotation, investigation, result withdrawal.

31.9 Generator Leakage

Failure: Protected task generator becomes a training target.

Safeguard: Generator versioning, defense in depth, alternative generators.

31.10 Hidden Threshold Manipulation

Failure: Decision thresholds move after results are observed.

Safeguard: Pre-commitment, governance, change records.

31.11 Overclaiming

Failure: Passing a private test is described as proof of safety.

Safeguard: Claims boundary and complementary evidence.

31.12 Under-Elicitation

Failure: The evaluator misses capability because of weak configuration.

Safeguard: Multiple elicitation tracks and developer input without task disclosure.

31.13 Model Awareness

Failure: The model detects evaluation and changes behavior.

Safeguard: varied contexts, environment analysis, monitoring, operational evidence.

31.14 Insider Threat

Failure: Authorized person leaks or modifies content.

Safeguard: least privilege, logging, dual control, monitoring, culture.

31.15 Excessive Cost

Failure: Security and task renewal become unsustainable.

Safeguard: proportionality, shared infrastructure, prioritization.

31.16 Exclusion of Open Communities

Failure: Only large corporations can access evaluation.

Safeguard: supervised access, subsidies, shared facilities, representative governance.

31.17 Harmful Evaluation Content

Failure: The evaluation itself creates misuse or safety risk.

Safeguard: domain review, safe proxies, sandboxing, restricted disclosure.

31.18 Retired-Task Mishandling

Failure: Old tasks are released in ways that expose active methods or sensitive content.

Safeguard: retirement review and staged disclosure.

32. Serious Objections

Objection 1: Science Requires Open Tests

Open access supports replication and criticism.

This objection is strong.

Response:

Publish methodology
release retired tasks
enable controlled replication
use public anchors
permit independent audit
document governance

Residual concern:

Some scientific scrutiny will remain weaker while active tasks are private.

Objection 2: Secret Evaluations Are Unaccountable

They can become arbitrary instruments of power.

Response:

Fair notice
public construct
independent review
pre-registered scoring
appeals
change records
conflict disclosure

Residual concern:

Information asymmetry cannot be eliminated.

Objection 3: Holdouts Will Leak Eventually

Often true.

Response:

Design for rotation, compromise detection, and recovery.

A holdout should be renewable infrastructure, not a permanent vault.

Objection 4: Developers Need Tasks to Debug Integration

Response:

Use public shadow tasks, retired examples, synthetic tasks, and supervised troubleshooting.

Residual concern:

Some active-task exposure may occasionally be necessary. It should be recorded and those items reconsidered.

Objection 5: Private Tests Advantage Insiders

Response:

Use formal access policy, exposure records, evaluator rotation, and independent governance.

Residual concern:

People close to the evaluation ecosystem may still learn its style.

Objection 6: A New Private Set Can Still Resemble Public Training Data

Correct.

Response:

Use provenance, post-cutoff sourcing, expert creation, procedural generation, and contamination analysis.

Residual concern:

Proving complete non-exposure is difficult.

Objection 7: Holdouts Encourage Test-Centric Governance

Response:

Require complementary operational and contextual evidence.

Objection 8: Held-Out Tests Are Too Expensive

Response:

Use them selectively where public exposure materially weakens high-value decisions.

Objection 9: Cryptographic and Secure-Compute Solutions Are Premature

Often true for complex workloads.

Response:

Specify security properties, pilot technologies, and avoid dependence on one mechanism.

Objection 10: Developers Can Train Against the General Domain Anyway

Yes.

A holdout does not prevent legitimate domain improvement.

Its purpose is to test generalization beyond exact known content, not to stop learning.

Objection 11: Confidential Results Can Be Misrepresented

Response:

Public reporting minimums, independent verification, and result status.

Objection 12: Open-Weight Models Cannot Receive the Same Developer Support

Response:

Report the difference and create standardized community participation paths.

33. Evidence Gaps

33.1 Magnitude of Contamination Effects

How much do different forms of contamination inflate different benchmark results?

33.2 Detection

Which detection methods work without access to training data?

33.3 Retro-Holdout Validity

When do newly created analogues measure the same construct as older public tests?

33.4 Task Exposure

How many administrations can a task tolerate before its value declines?

33.5 Model Awareness

Can systems reliably detect controlled evaluation contexts and alter behavior?

33.6 Controlled Replication

Which institutional models produce credible replication without broad disclosure?

33.7 Secure Compute

When do trusted execution environments and related methods provide practical assurance for frontier evaluation?

33.8 Fair Access

How can smaller evaluators and open communities participate without weakening security?

33.9 Threshold Fairness

What procedural protections are required when held-out results influence deployment or legal status?

33.10 Real-World Predictive Value

Do held-out results predict deployment behavior better than public benchmarks?

33.11 Evaluator Incentives

How do funding and access relationships affect conclusions?

33.12 International Recognition

What evidence should support mutual recognition of confidential results?

34. Research Agenda

Priority 1: Contamination Measurement

Compare:

Exact exposure
semantic exposure
template exposure
repeated benchmark optimization
post-training exposure

Priority 2: Holdout Construction

Study:

Expert-authored
post-cutoff
procedural
event-sourced
adversarial
hybrid methods

Priority 3: Retro-Holdouts

Develop methods for testing whether a new private set is genuinely comparable to an older public benchmark.

Priority 4: Exposure Accounting

Model task value as a function of:

Administrations
viewers
model families
time
transcript retention
public derivatives

Priority 5: Secure Evaluation Infrastructure

Pilot:

TEEs
attestation
secure APIs
joint facilities
federated evaluation
cryptographic commitments

Priority 6: Controlled Reproducibility

Compare:

Independent reruns
retired-task release
method replication
multi-party verification

Priority 7: Model Awareness and Cheating

Develop methods to detect:

Environment probing
judge manipulation
hidden-data search
sandbox escape
strategic underperformance
test-specific behavior

Priority 8: Fairness

Study access models for:

Small labs
academia
public-interest groups
open-source communities
international evaluators

Priority 9: Governance

Pilot:

Distributed custody
appeals
public-interest oversight
evaluator rotation
funding safeguards

Priority 10: Decision Utility

Measure whether held-out evidence improves actual deployment and policy decisions.

35. Near-Term Experiments

Experiment 1: Public Versus Held-Out Performance

Create matched public and private task forms.

Compare:

Performance
ranking
confidence
error type
model-family effects

Experiment 2: Exposure Decay

Administer a task bank repeatedly and measure whether performance changes after controlled exposure.

Experiment 3: Retro-Holdout Validation

Construct a private analogue of a known benchmark and test construct equivalence.

Experiment 4: Generator Security

Compare public and protected procedural generators.

Experiment 5: Controlled Replication

Have two independent evaluators administer the same protected protocol.

Experiment 6: Elicitation Tracks

Compare standard, developer-elicited, and evaluator-optimized performance without exposing active tasks.

Experiment 7: Attested Execution

Pilot a trusted execution environment for a limited evaluation workload.

Experiment 8: Compromise Drill

Simulate a task-bank leak and test response time, result-status changes, and replacement.

Experiment 9: Open-Source Participation

Create a supervised evaluation path for an open-weight model community.

Experiment 10: Delayed Disclosure

Release retired tasks and assess whether the disclosure improves scientific scrutiny without harming active evaluation.

36. Implications for Future Standards

A future held-out evaluation standard could require:

36.1 Holdout Justification

Explain why restriction is necessary.

36.2 Protected-Surface Definition

Identify exactly what is held out.

36.3 Threat Model

Define assets, threats, controls, and residual risk.

36.4 Governance

Specify ownership, roles, conflicts, review, and appeals.

36.5 Provenance

Maintain task and solution history.

36.6 Access Control

Define tiers, authorization, review, and revocation.

36.7 Administration

Standardize configuration, logging, deviations, and scoring.

36.8 Validation

Demonstrate correctness, reliability, coverage, and fairness.

36.9 Reproducibility

Provide controlled replication or equivalent assurance.

36.10 Disclosure

Publish methodology, results, limitations, and restriction rationale.

36.11 Compromise Response

Define detection, investigation, status, remediation, and notice.

36.12 Rotation and Retirement

Define exposure limits, renewal, expiration, and archival treatment.

Such a standard should be developed through the future STANDARDS_DEVELOPMENT_PROCESS.md.

37. Relationship to the Other Foundations

Foundation 1: Dynamic Evaluation Protocols

A holdout must evolve as tasks leak, saturate, and lose relevance.

Foundation 3: High-Stakes Capability Evaluation

The higher the potential consequence, the stronger the case for protected, independently administered evidence.

Foundation 4: Independent Expert Review

Restricted content requires qualified external review to maintain accountability.

Foundation 5: Third-Party Auditor Ecosystem

Held-out evaluation depends on trustworthy organizations capable of secure administration.

Foundation 6: Progressive Standards and Requirements

Held-out protocols may evolve from research practice into procurement, certification, or regulatory evidence.

Foundation 7: Incentives and Prestige

Participation should reward genuine scrutiny, not private-test mystique.

Foundation 8: Global Interoperability

Institutions need compatible metadata, access, security, and recognition systems.

38. Canonical Standards Body Positions

Standards Body adopts the following working positions.

Public benchmarks remain essential to open science.
Some frontier evaluations require held-out components because public exposure can weaken validity.
Held-out evaluation is a spectrum, not a binary category.
Every restriction should have a defined purpose, scope, owner, duration, and review path.
Confidentiality does not establish scientific validity.
Transparent governance can coexist with protected content.
The construct and broad methodology should normally be disclosed.
Exact tasks, solutions, attack libraries, or environment details may remain protected when disclosure would materially reduce validity or create harm.
Held-out results should not be the sole basis for broad safety claims.
High-consequence held-out evaluations require independent review.
Task provenance and chain of custody are core evaluation evidence.
Access should follow least privilege and separation of duties.
Developers should receive fair notice without active-task disclosure.
Developers should be able to challenge material errors but should not control publication.
Open-source and smaller actors require meaningful participation pathways.
A private evaluator is not automatically independent.
Result uncertainty should be reported even when the task set is confidential.
Held-out tasks should rotate, expire, or retire.
Compromise should change result status transparently.
Security controls should be proportionate and auditable.
Cryptographic or confidential-computing methods can support assurance but cannot replace governance.
Retired-task release should be considered when safe and useful.
International interoperability should favor shared requirements over one global task bank.
Passing a held-out evaluation is not proof of safety.
The holdout system itself should be regularly evaluated.

39. Decision Rules

A held-out component is justified when:

Public exposure would materially increase contamination or gaming
the decision consequence is substantial
task replacement is costly or slow
attack disclosure would undermine safeguard testing
the domain contains sensitive or harmful content
independent generalization evidence is otherwise unavailable
the protocol can support secure and fair administration

A held-out component is not justified merely because:

Secrecy makes the evaluation appear authoritative
maintainers want exclusive control
public criticism is inconvenient
the methodology is weak
a sponsor prefers confidentiality
the evaluator wants commercial lock-in

A task should be rotated when:

Exposure exceeds policy
leakage is suspected
performance saturates
validity declines
environment changes
solutions become common
the task is used for development

A result should be suspended when:

Active tasks may have leaked
model identity is uncertain
configuration materially deviated
scoring integrity failed
logs are incomplete
independent review finds a serious flaw

A protocol should be retired when:

The holdout can no longer be protected
task renewal is not feasible
construct validity fails
governance legitimacy fails
cost exceeds decision value
a stronger successor exists

40. Held-Out Evaluation Plan Template

A. Identity

Protocol name
identifier
version
owner
status
date

B. Purpose

Decision question
intended users
intended use
prohibited use
holdout justification

C. Construct

Definition
subdomains
exclusions
deployment context

D. Protected Surface

Tasks
solutions
scoring
generator
environment
thresholds
results
identities

E. Threat Model

Assets
adversaries
attack surfaces
controls
residual risk

F. Governance

Roles
conflicts
funding
review
appeals
disclosure authority

G. Task Bank

Sources
provenance
validation
difficulty
coverage
exposure policy
retirement

H. Access

Tiers
qualification
approval
monitoring
revocation

I. Infrastructure

Storage
transfer
execution
logging
backup
deletion
attestation

J. Administration

Model verification
configuration
tools
retries
dry run
deviations

K. Scoring

Metrics
judges
adjudication
uncertainty
thresholds

L. Reporting

Public report
restricted annex
developer review
result status
expiration

M. Compromise Response

Detection
investigation
suspension
remediation
notice

N. Renewal

Rotation triggers
review cycle
successor
retirement

41. Access Request Template

Applicant:
Organization:
Role:
Requested protocol:
Requested access tier:
Purpose:
Duration:

Competence

Describe relevant technical and domain expertise.

Security Controls

Describe identity, device, storage, execution, logging, and incident controls.

Conflicts

Disclose relevant financial, professional, competitive, and intellectual interests.

Data Handling

Explain how protected materials and outputs will be handled.

Publication

Describe intended outputs and review process.

Subcontractors

Identify all third parties.

Prior Incidents

Disclose relevant security or integrity incidents.

Decision

Approved
approved with conditions
supervised access only
deferred
rejected

Conditions

Expiration

42. Compromise Incident Template

Incident identifier:
Date discovered:
Reporter:
Protocol:
Affected version:

Description

Assets Affected

Suspected Exposure

Timeline

Immediate Actions

Evidence Preserved

Results Potentially Affected

Investigation Lead

Status

Suspected
confirmed
contained
remediated
closed

Result Action

No change
caveat
suspend
withdraw
re-evaluate

Root Cause

Corrective Action

Public Notice

Governance Review

Follow-Up Date

43. Holdout Scorecard

Dimension	Core Question
Purpose	Is the measurement reason for holding content out explicit?
Construct	Is the evaluated capability clearly defined?
Protected surface	Is it clear what is restricted and why?
Provenance	Can each task and solution be traced?
Coverage	Does the bank represent the intended task universe?
Validity	Does evidence support the intended interpretation?
Reliability	Are results sufficiently consistent?
Integrity	Are contamination and manipulation risks addressed?
Security	Are controls proportionate to the threat model?
Access	Is authorization role-based and reviewable?
Chain of custody	Is every material access and change recorded?
Administration	Can qualified evaluators run the protocol consistently?
Scoring	Are rules, judges, and uncertainty defensible?
Transparency	Is enough public for accountability?
Reproducibility	Can independent parties verify the process?
Fairness	Are participants treated consistently?
Independence	Is evaluator judgment protected from interested parties?
Appeals	Can material error be challenged?
Compromise response	Can the system detect, suspend, recover, and disclose?
Renewal	Are tasks rotated before authority decays?
Retirement	Can obsolete or compromised evidence be withdrawn?
Accessibility	Can qualified smaller and open actors participate?
Interoperability	Can other institutions understand and recognize the result?
Decision utility	Does the holdout improve a real decision?

44. Final Perspective

A benchmark loses independence when the people building the system know exactly how success will be measured.

That does not make public evaluation useless.

It means public evaluation answers a different question.

A public benchmark can show how well a system performs on a shared, inspectable target.

A held-out evaluation can provide additional evidence about how the system behaves when the exact target has not become part of development.

Both matter.

The future evaluation ecosystem should preserve the openness that allows science to progress while protecting enough unseen evidence to test genuine generalization, resilience, and threshold capability.

That balance is difficult.

Too little protection produces contaminated or gameable measurement.

Too much secrecy produces unaccountable authority.

The answer is not a permanent secret benchmark.

The answer is a governed holdout system.

Such a system should know:

What it protects
why it protects it
who can access it
how access is recorded
how tasks are validated
how results are reproduced
how participants appeal
how compromise is detected
how tasks are renewed
when evidence expires
when content can be disclosed
when the protocol should end

The second foundation of Standards Body is therefore not secrecy.

It is protected evidence under accountable control.

References and Research Basis

[^nist-tevv]: National Institute of Standards and Technology, AI Test, Evaluation, Validation and Verification. https://www.nist.gov/ai-test-evaluation-validation-and-verification-tevv

[^nist-rmf]: National Institute of Standards and Technology, AI Risk Management Framework. https://www.nist.gov/itl/ai-risk-management-framework

[^nist-statistical]: National Institute of Standards and Technology, Expanding the AI Evaluation Toolbox with Statistical Models, 2026. https://www.nist.gov/news-events/news/2026/02/new-report-expanding-ai-evaluation-toolbox-statistical-models

[^nist-cheating]: National Institute of Standards and Technology, Practices for Detecting and Preventing Evaluation Cheating, 2025. https://www.nist.gov/caisi/cheating-ai-agent-evaluations/4-practices-detecting-and-preventing-evaluation-cheating

[^nist-protein]: National Institute of Standards and Technology, Experimental Evaluation of AI-Driven Protein Design Risks Using Safe Biological Proxies, 2025. https://www.nist.gov/publications/experimental-evaluation-ai-driven-protein-design-risks-using-safe-biological-proxies

[^aisi-lessons]: UK AI Security Institute, Early Lessons from Evaluating Frontier AI Systems, 2024. https://www.aisi.gov.uk/blog/early-lessons-from-evaluating-frontier-ai-systems

[^aisi-qa]: UK AI Security Institute, Early Insights from Developing Question-Answer Evaluations for Frontier AI, 2024. https://www.aisi.gov.uk/blog/early-insights-from-developing-question-answer-evaluations-for-frontier-ai

[^aisi-sandbox]: UK AI Security Institute, The Inspect Sandboxing Toolkit: Scalable and Secure AI Agent Evaluations, 2025. https://www.aisi.gov.uk/blog/the-inspect-sandboxing-toolkit-scalable-and-secure-ai-agent-evaluations

[^aisi-sandbox-learning]: UK AI Security Institute, What Can Sandboxed AI Agents Learn About Their Evaluation Environments?, 2026. https://www.aisi.gov.uk/blog/what-can-sandboxed-ai-agents-learn-about-their-evaluation-environments

[^aisi-breakout]: UK AI Security Institute, Can AI Agents Escape Their Sandboxes?, 2026. https://www.aisi.gov.uk/blog/can-ai-agents-escape-their-sandboxes-a-benchmark-for-safely-measuring-container-breakout-capabilities

[^aisi-safeguards]: UK AI Security Institute, Principles for Safeguard Evaluation, 2025. https://www.aisi.gov.uk/blog/principles-for-safeguard-evaluation

[^inspect]: UK AI Security Institute, Inspect AI, evaluation framework. https://inspect.aisi.org.uk/

[^inspect-cyber]: UK AI Security Institute, A New Standard for Agentic Cyber Evaluations, 2025. https://www.aisi.gov.uk/blog/inspect-cyber

[^openai-pf]: OpenAI, Preparedness Framework v2, 2025. https://cdn.openai.com/pdf/18a02b5d-6b67-4cec-ab64-68cdfbddebcd/preparedness-framework-v2.pdf

[^openai-external]: OpenAI, Strengthening Our Safety Ecosystem with External Testing, 2025. https://openai.com/index/strengthening-safety-with-external-testing/

[^deepmind-fsf]: Google DeepMind, Frontier Safety Framework, updated 2025. https://deepmind.google/blog/updating-the-frontier-safety-framework/

[^deepmind-warning]: Google DeepMind, An Early Warning System for Novel AI Risks, 2023. https://deepmind.google/blog/an-early-warning-system-for-novel-ai-risks/

[^anthropic-rsp]: Anthropic, Responsible Scaling Policy, Version 3.2, 2026. https://www.anthropic.com/responsible-scaling-policy

[^extreme-risk]: Toby Shevlane et al., Model Evaluation for Extreme Risks, 2023. https://arxiv.org/abs/2305.15324

[^dangerous-capabilities]: Mary Phuong et al., Evaluating Frontier Models for Dangerous Capabilities, 2024. https://arxiv.org/abs/2403.13793

[^external-access]: Jacob Charnock et al., Expanding External Access to Frontier AI Models for Dangerous Capability Evaluations, 2026. https://arxiv.org/abs/2601.11916

[^contamination-survey]: Cheng Xu et al., Benchmark Data Contamination of Large Language Models: A Survey, 2024. https://arxiv.org/abs/2406.04244

[^contamination-trust]: Yihong Dong et al., Data Contamination and Trustworthy Evaluation for Large Language Models, 2024. https://arxiv.org/abs/2402.15938

[^retro-holdout]: Jack Haimes et al., Benchmark Inflation: Revealing LLM Performance Gaps Using Retro-Holdouts, 2024. https://arxiv.org/abs/2410.09247

[^livebench]: Colin White et al., LiveBench: A Challenging, Contamination-Limited LLM Benchmark, 2024. https://arxiv.org/abs/2406.19314

[^c2leva]: Yanyang Li et al., C2LEVA: Toward Comprehensive and Contamination-Free Language Model Evaluation, 2024. https://arxiv.org/abs/2412.04947

[^clean-eval]: Wenhong Zhu et al., CLEAN-EVAL: Clean Evaluation on Contaminated Large Language Models, 2023. https://arxiv.org/abs/2311.09154

[^ccc-technical]: Confidential Computing Consortium, A Technical Analysis of Confidential Computing. https://confidentialcomputing.io/wp-content/uploads/sites/10/2023/03/CCC-A-Technical-Analysis-of-Confidential-Computing-v1.3_unlocked.pdf

[^ccc-attestation]: Confidential Computing Consortium, Why Is Attestation Required for Confidential Computing?, 2023. https://confidentialcomputing.io/2023/04/06/why-is-attestation-required-for-confidential-computing/

Revision Record

Version 1.0

Date: July 16, 2026

Change type: Complete replacement

Summary: Replaces the earlier outline edition with a fully developed canonical working white paper. Adds first-principles rationale, definitions, design taxonomy, contamination analysis, holdout threat modeling, task provenance, statistical design, security architecture, access tiers, chain of custody, administration, reporting, controlled reproducibility, transparency, fairness, developer-evaluator relationships, governance, compromise response, lifecycle, domain-specific requirements, protected-compute options, international interoperability, maturity model, implementation pathway, a Standards Body pilot, metrics, failure analysis, objections, evidence gaps, research agenda, standards implications, operational templates, scorecard, and primary-source research basis.

Status: Ready for internal review and future expert critique.