Standards Body · Foundation paper, public edition · Released July 17, 2026
Canonical record: https://standardsbody.ai/library/foundation-paper/high-stakes-capability-evaluation/
Standards Body is an independent research and institutional-design project. It is not currently a regulator, accreditation body, certification body, or governmental authority. This document is research; it is not an adopted standard.
Series: Foundations for Frontier AI Evaluation Infrastructure
Version: 1.0
Status: Canonical working white paper
Project: Standards Body
Primary domain: standardsbody.ai
Core line: Foundations for Frontier AI
Research basis reviewed through: July 16, 2026
Document owner: Standards Body
Review cycle: Annual review, with event-triggered revision after material capability advances, major incidents, threshold changes, or new scientific evidence
This paper defines the Standards Body position on evaluating AI capabilities that may produce unusually consequential outcomes.
It is intended to serve as:
This paper is not a legal classification system.
It does not designate any current model, organization, or deployment as safe or unsafe.
It does not establish universal deployment thresholds.
It does not assume that every advanced capability is dangerous.
It establishes the principles, architecture, and decision processes required to produce stronger evidence when the consequences of being wrong could be severe.
Not every AI capability warrants the same level of evaluation.
A system that writes advertising copy, reformats a spreadsheet, or produces illustrations can create meaningful benefits and harms, but the evaluation burden for those functions should not automatically equal the burden for systems capable of:
The purpose of high-stakes capability evaluation is to direct stronger measurement toward capabilities whose misuse, failure, or uncontrolled operation could produce unusually large, rapid, difficult-to-reverse, or systemically distributed consequences.
The phrase high-stakes capability should not be treated as a synonym for:
A capability becomes high stakes through the relationship among several factors:
Capability
What the system can accomplish under specified conditions.
Propensity
Whether and under what circumstances the system tends to use that capability in harmful, deceptive, uncontrolled, or policy-violating ways.
Access and exposure
Who can use the capability, at what scale, with what tools, and under which deployment conditions.
Vulnerability and target context
Whether people, institutions, infrastructure, or environments are susceptible to the capability.
Safeguards
Which technical, operational, legal, and social controls reduce the likelihood or consequence of harm.
Consequence
The severity, scale, duration, reversibility, and distribution of possible outcomes.
Uncertainty
How incomplete or fragile the evidence is.
Capability evaluation therefore contributes to risk assessment, but it does not replace it.
A model may possess a high-stakes capability without creating high residual risk if:
Conversely, a system with moderate capability can create substantial risk when:
Standards Body therefore rejects one-dimensional evaluation.
A single score should not be allowed to stand in for a complete high-stakes assessment.
A mature evaluation should answer at least five distinct questions:
High-stakes evaluation should also distinguish between:
This foundation adopts the following core position:
Evaluation effort, independence, security, and evidentiary rigor should increase with the potential consequence of error. High-stakes capability judgments should be domain-specific, system-specific, uncertainty-aware, linked to explicit decisions, and supported by multiple forms of evidence rather than a single benchmark result.
A credible high-stakes framework should include:
The objective is not to create a permanent list of dangerous technologies.
The objective is to build an evaluation system capable of recognizing when ordinary measurement is no longer enough.
The rigor of evaluation should be proportional to the potential consequence of being wrong.
This principle applies in both directions.
A false negative can lead an institution to underestimate capability and deploy without adequate safeguards.
A false positive can lead an institution to overestimate capability, restrict beneficial development, concentrate market power, waste resources, or create unjustified public fear.
High-stakes evaluation must therefore control both types of error.
Capability is necessary evidence for many high-stakes judgments, but capability alone is not risk.
Risk emerges from the interaction among capability, propensity, access, context, vulnerability, safeguards, and consequence.
As evaluation results become more consequential, the process producing them should become more independent, reviewable, secure, and accountable.
An exploratory research benchmark and a deployment threshold should not be governed identically.
High-stakes capability categories, thresholds, and evaluation methods should change as systems, threats, safeguards, and deployment environments change.
The framework should remain stable in principle and revisable in application.
High-stakes evaluation should enable beneficial progress by improving confidence, not treat capability growth itself as wrongdoing.
Many capabilities relevant to severe harm are also relevant to:
Evaluation should preserve this dual-use reality.
This paper covers the evaluation of capabilities that may materially affect:
This paper does not provide complete domain standards for:
These can be high-stakes applications under law or professional practice.
They should be evaluated seriously.
This foundation focuses primarily on frontier and general-purpose capabilities whose effects can propagate across many applications or enable unusually consequential actions.
A high-stakes capability concerns what a system can do.
A high-risk use concerns where and how a system is deployed.
Examples:
Both capability and use context matter.
Severe frontier risks should not displace attention from current harms.
An institution can evaluate:
while also developing methods for less frequent but more severe capability pathways.
The evaluated object may include:
High-stakes capability frequently belongs to the system rather than the base model alone.
A capability is the ability of a model or system to achieve a defined class of outcomes under specified conditions.
A high-stakes capability is an ability whose use, misuse, failure, or uncontrolled expression could plausibly contribute to severe, large-scale, rapid, difficult-to-reverse, or systemic consequences.
A dangerous capability is a capability that can materially enable harmful action.
The term should be used with a specified harm pathway.
A critical capability is a capability that crosses a defined threshold requiring a change in safeguards, access, oversight, or deployment decision.
"Critical" is decision-linked, not merely descriptive.
A precursor capability is a component skill that contributes to a more consequential end-to-end capability.
A capability threshold is a defined level of evidence at which a predetermined review, safeguard, or decision process is triggered.
An alert threshold is an earlier indicator that triggers enhanced evaluation or preparation before a critical threshold is reached.
Google DeepMind's Frontier Safety Framework uses alert thresholds before defined Critical Capability Levels as part of its escalation structure.[^deepmind-fsf3]
A risk domain is a category of possible harm with shared capability pathways, targets, safeguards, and evaluation methods.
A hazard is a source or condition with the potential to cause harm.
Exposure is the extent to which actors, systems, or environments can encounter or use the capability.
Vulnerability is susceptibility to harm given exposure.
Propensity is the tendency of a system to use or express a capability under specified conditions.
A safeguard is a technical, operational, organizational, or legal measure intended to reduce the likelihood or consequence of harm.
Residual risk is the risk remaining after safeguards are considered.
Severity concerns the magnitude of harm to affected people, systems, institutions, or environments.
Scale concerns the number of affected entities, geographic reach, operational volume, or systemic breadth.
Reversibility concerns whether harm can be contained, corrected, compensated, or restored.
Uplift is the increase in an actor's performance caused by access to the AI system relative to an appropriate baseline.
Accessibility concerns how easily a capability can be obtained and used by actors with different resources or expertise.
Reliability is the consistency with which the system can produce the relevant outcome.
Autonomy is the degree to which a system can select, sequence, and execute actions without ongoing human direction.
Systemic risk is the possibility that failure or harmful behavior propagates across interconnected systems, institutions, markets, or societies.
Loss of control is a condition in which operators cannot reliably direct, constrain, monitor, correct, or terminate a system's consequential behavior.
A safety case is a structured argument, supported by evidence, that a system is acceptably safe for a defined context.
A capability evaluation can support a safety case, but should not be confused with the whole case.
Standards Body uses the following conceptual structure:
High-stakes risk is a function of capability, propensity, access, exposure, vulnerability, safeguards, consequence, and uncertainty.
This is not presented as a complete mathematical formula.
It is a discipline for preventing one variable from substituting for the entire judgment.
Questions:
Questions:
Questions:
Questions:
Questions:
Questions:
Questions:
Questions:
A low estimate in one factor should not automatically cancel a very high estimate elsewhere.
Examples:
Capability evidence can identify emerging risk before deployment incidents reveal it.
Institutions need time to develop:
Capability evidence can inform:
High-stakes evaluation helps direct limited expert and institutional resources to the most consequential questions.
Explicit capability claims can be reviewed, challenged, and updated.
Evaluation helps distinguish:
Capability evaluation may fail to capture:
Produces evidence about what the system can do.
Combines capability evidence with:
Tests whether controls prevent, detect, or limit harmful use.
Tests whether the system behaves in concerning ways under relevant conditions.
Integrates evidence into a structured argument about a specific deployment.
Applies institutional values, risk tolerance, law, and accountability to the evidence.
A capability evaluator should not automatically determine policy.
A policymaker should not invent technical capability claims.
A developer should not treat internal risk acceptance as external proof.
A capability may warrant high-stakes treatment when several of the following are present.
Potential outcomes include:
The capability can affect:
Harm can occur faster than institutions can:
Outcomes are difficult to:
The system enables actors with lower expertise, fewer resources, or less time to perform consequential actions.
The capability works often enough to be operationally useful.
The system can plan, act, adapt, and recover with limited supervision.
The capability can be copied, parallelized, automated, or deployed at low marginal cost.
Skills learned in one domain transfer into another consequential domain.
Moderate abilities combine into an end-to-end harmful workflow.
The system can evade detection, hide intent, manipulate oversight, or disguise actions.
The system can obtain:
The system can overcome safeguards or exploit defender weaknesses.
Institutions rely on the system enough that failure propagates broadly.
A capability may receive higher scrutiny when the evidence base is weak and downside consequence is large.
Standards Body proposes a five-level capability classification for evaluation planning.
This is not a universal risk label.
Characteristics:
Evaluation:
Characteristics:
Evaluation:
Characteristics:
Evaluation:
Characteristics:
Evaluation:
Characteristics:
Evaluation:
Cyber capability is dual use.
The same abilities can support:
A possible pathway includes:
Can the system explain vulnerabilities or attack techniques?
Can it solve capture-the-flag or vulnerability challenges?
Can it operate scanners, debuggers, shells, and exploitation frameworks?
Can it compromise a realistic controlled target?
Can it plan and adapt across multi-step operations?
Can it operate across multiple targets or parallel agents?
A system that succeeds once under extensive help differs from one that succeeds repeatedly with little oversight.
AISI has reported progressively more demanding cyber evaluations, from knowledge tasks to capture-the-flag challenges and multi-step simulations, reflecting the importance of end-to-end and reliability-sensitive measurement.[^aisi-trends][^aisi-cyber-eval]
Evaluate:
Cyber evaluation may inform:
CBRN evaluation is highly sensitive.
The domain contains enormous beneficial potential and severe misuse pathways.
A biological misuse pathway can include:
AI may affect only some stages.
A high-quality evaluation should identify where uplift occurs.
Scientific understanding and factual recall.
Combining dispersed knowledge into actionable plans.
Designing experiments, controls, and troubleshooting steps.
Operating databases, modeling tools, laboratory software, or automation.
Assisting with practical barriers normally requiring experience.
Increasing the success probability of an actor across the full pathway.
Compare against:
Use:
NIST has used safe biological proxies to investigate AI-assisted protein-design risks while reducing experimental danger.[^nist-protein]
Evaluate:
OpenAI's Preparedness Framework and Google DeepMind's Frontier Safety Framework both include biological or CBRN-related capability and safeguard domains, though their structures and thresholds differ.[^openai-pf2][^deepmind-fsf3]
High-stakes autonomy concerns what systems can accomplish with sustained, adaptive action.
Relevant abilities may include:
Self-proliferation can refer to a system's ability to:
Evaluation should specify whether tasks are simulated or real.
A capability pathway may involve:
Research on stealth and situational awareness treats these as possible prerequisite capabilities for scheming rather than proof that a system will scheme.[^stealth]
Short, isolated tasks.
Multi-step task completion.
Extended operation with uncertainty.
Operating while monitored.
Testing whether safeguards and monitoring remain effective against a capable system.
Agent capability is highly scaffold-dependent.
Report:
Evaluations should not provide uncontrolled:
Persuasion is common and often beneficial.
High-stakes concern arises when systems can manipulate, coerce, deceive, or influence at scale in ways that undermine informed human choice or institutional integrity.
Potential elements:
Human rating of persuasive content.
Observed change in beliefs, intentions, or behavior.
Adaptation to individual characteristics.
Repeated interaction over time.
Coordination across audiences and channels.
AI systems may accelerate the research and engineering required to create more capable AI systems.
This can produce substantial benefits.
It can also compress the time available for evaluation, governance, security, and adaptation.
Relevant abilities may include:
Understanding literature and methods.
Solving well-defined technical problems.
Generating and testing new ideas.
Improving real developer output.
Planning and executing extended research programs.
Meaningfully increasing the rate at which more capable AI systems can be produced.
The capability becomes more consequential when:
Google DeepMind's Frontier Safety Framework includes AI research and development capability among domains relevant to severe-risk preparation.[^deepmind-fsf3]
Critical infrastructure includes systems whose disruption can create cascading harm.
Examples:
AI may:
Prefer:
AI can support:
High-stakes concern arises when capability, autonomy, access, and scale create systemic or coercive effects.
Also measure:
Advanced AI may accelerate discovery in:
This is a core benefit pathway.
High stakes arise when:
Many high-stakes effects may arise from interactions among systems rather than one model.
Google DeepMind has expanded research on multi-agent safety and interaction risks as agentic systems become more prominent.[^deepmind-multiagent]
High-level harms should be decomposed into measurable subcapabilities.
AISI describes breaking top-level capabilities into subcapabilities and constructing evaluation environments around them.[^aisi-agenda]
A capability graph can represent:
Possible components:
It supports:
End-to-end capability can differ from the sum of parts.
Integration, planning, error recovery, and timing may create bottlenecks or emergent uplift.
A mature protocol should include both.
A system may possess capability that ordinary prompting fails to reveal.
High-stakes evaluation should reduce false negatives through serious elicitation.
What ordinary users experience.
What a common evaluator configuration produces.
What the developer can demonstrate.
What an independent evaluator can elicit.
What a well-resourced actor may obtain under realistic conditions.
For severe misuse, the relevant actor may invest substantial effort.
AISI has published a structured protocol for capability-elicitation experiments intended to investigate performance near the upper limit of model ability.[^aisi-elicitation]
It can overstate deployment risk if it requires:
Report resource requirements explicitly.
Some threats involve actors fine-tuning models.
Evaluation may test:
This work can itself be sensitive and should receive security review.
Every result should report:
Define the decision before the evaluation.
Define:
Specify:
Include a justified mix of:
Use:
Compare against:
Measure:
Review:
Ensure the evaluation does not create excessive operational risk.
Report capability and context separately.
A threshold is not merely a score.
It is a point at which evidence triggers a defined institutional response.
Thresholds can trigger:
An alert threshold provides advance warning.
A critical threshold triggers a stronger response.
Use multiple inputs where appropriate:
Defined by a fixed capability level.
Compared with a professional or actor baseline.
Compared with current tools or operational capacity.
Defined by ability to complete an end-to-end scenario.
Triggered by rapid acceleration or narrowing distance to a critical level.
Combines multiple indicators.
A threshold should specify:
Risks:
Near a threshold:
OpenAI's Preparedness Framework uses tracked risk categories and capability levels linked to safeguards.[^openai-pf2]
Google DeepMind's Frontier Safety Framework uses Critical Capability Levels, alert thresholds, and response plans across defined risk domains.[^deepmind-fsf3]
Anthropic's Responsible Scaling Policy uses AI Safety Levels and capability or risk evidence to determine required safeguards and governance responses.[^anthropic-rsp3]
These frameworks demonstrate serious attempts to connect capability evidence to action.
They differ in definitions, scope, governance, transparency, and institutional incentives.
No single framework should be treated as a universal standard.
A capability result should be interpreted alongside safeguard and exposure evidence.
| Capability Evidence | Safeguard Evidence | Exposure | Illustrative Response |
|---|---|---|---|
| Low | Strong or ordinary | Limited | Routine monitoring |
| Emerging precursor | Incomplete | Limited | Enhanced evaluation and preparation |
| Emerging precursor | Weak | Broad | Safeguard development and access review |
| Operational high-stakes | Strong | Limited | Independent verification and continuous testing |
| Operational high-stakes | Weak | Limited | Restrict access until safeguards improve |
| Operational high-stakes | Strong | Broad | System-level review and intensive monitoring |
| Operational high-stakes | Weak | Broad | Presumption against broad deployment pending mitigation |
| Critical capability | Uncertain | Any material exposure | Multi-institution review and formal safety case |
This table is illustrative.
Actual decisions require domain evidence and accountable authority.
A high-stakes claim should draw from multiple sources:
Report confidence separately for:
Failure to demonstrate a capability is not proof of inability unless:
One successful demonstration can be material for some capabilities, especially when the outcome is severe and repeatability is plausible.
But one success may not establish operational reliability.
Report success over repeated attempts.
Test across:
Connect evaluation performance to real-world or realistic outcomes where safe.
Capability evidence expires as models, scaffolds, and environments change.
External evaluators may receive insufficient:
Research on external evaluator access has proposed separating model access, information access, and evaluation timeframe because each affects the confidence of dangerous-capability assessment.[^external-access]
Every consequential judgment should include:
The evaluation concludes that the capability is absent or below threshold when it is present.
Causes:
Consequences:
The evaluation concludes that the capability is present or above threshold when it is not operationally meaningful.
Causes:
Consequences:
Error costs differ by domain and decision.
Use:
High consequence can justify earlier action under uncertainty.
It does not eliminate the need to evaluate costs, alternatives, and reversibility.
Capability and safeguard evidence should be separate.
Safeguard testing should specify:
AISI's safeguard-evaluation work emphasizes defining the threat model, developing representative attacks, and connecting evaluation to actionable decisions.[^aisi-safeguards][^aisi-actionable]
Test whether safeguards remain effective when attackers learn.
A strong system should not depend on one filter.
Measure:
Evaluate whether safeguards survive:
Even strong safeguards leave residual risk.
Safeguard evidence should be renewed as attack methods and capabilities change.
High-stakes evaluation should include the deployed system.
A deployment can change through:
Risk depends partly on the resilience of the systems surrounding AI.
Define the conditions under which the evaluation remains applicable.
Use precursor tests and trend analysis.
Evaluate:
Use:
Require confidence that evidence remains valid at scale.
Monitor:
A response plan should define how access can be:
A mature high-stakes evaluation process may include:
The team building a capability evaluation should not unilaterally determine deployment.
The team responsible for launch should not control unfavorable evidence.
Required when:
Disclose:
Allow:
A party should be able to challenge:
Developer evidence is essential.
It should not be the only evidence for the most consequential claims.
Independent evaluators should not become unaccountable authorities.
Funding should not purchase:
Frontier safety frameworks are evolving organizational governance systems.
The current frameworks of OpenAI, Google DeepMind, and Anthropic connect defined capability or risk categories to safeguards and decision processes, but remain developer-created and voluntary.[^openai-pf2][^deepmind-fsf3][^anthropic-rsp3]
Independent standards work should learn from them without treating them as final consensus.
Tasks may reveal:
Use:
The evaluation may increase risk by:
Before evaluation, review:
Use sandboxes, simulated systems, controlled networks, and protected task banks where appropriate.
Security should also prevent:
High-stakes capability is global, but legal and institutional contexts differ.
Institutions can align on:
Jurisdictions may choose different policy responses to the same capability evidence.
Evaluation comparability should not require identical governance.
Recognition may require:
Government AI safety and security institutes can support:
NIST's AI Risk Management Framework provides a voluntary structure for managing AI risks across governance, mapping, measurement, and management.[^nist-rmf]
The European Union AI Act distinguishes high-risk use contexts and introduces additional obligations for general-purpose AI models with systemic risk.[^eu-ai-act]
These legal and risk-management systems overlap with high-stakes evaluation but are not identical to the capability framework proposed here.
A single number is unlikely to represent every domain, system, and jurisdiction.
The long-term goal should be interoperable evidence with accountable local and international decision processes.
Characteristics:
Characteristics:
Use:
Characteristics:
Use:
Characteristics:
Use:
Characteristics:
Use:
Choose a bounded, decision-relevant capability.
Identify actors, actions, targets, bottlenecks, safeguards, and consequences.
Decompose the pathway into measurable abilities.
Create early-warning, operational, and critical levels.
Assign roles, review, conflicts, and appeals.
Combine:
Use relevant humans, systems, and actor profiles.
Estimate capability under multiple resource conditions.
Assess:
Test realistic adversaries.
Review methods and interpretation.
Connect results to predefined responses.
Use staged exposure.
Update after changes and incidents.
High-Stakes Capability Evaluation Case: Autonomous Cyber Operations
Develop an independent, transparent framework for distinguishing:
Cyber provides:
The pilot should map:
Open tasks and reproducible baseline.
Rotating protected tasks.
Controlled multi-step environments.
Access controls, monitoring, policy, and tool gating.
Standard, developer-supported, and evaluator-optimized configurations.
The pilot succeeds if it:
Failure: A capability score is treated as complete risk.
Safeguard: Separate capability, propensity, access, safeguards, exposure, consequence, and uncertainty.
Failure: Multiple-choice or question-answer performance is treated as end-to-end capability.
Safeguard: Tool use, simulations, integration, and reliability testing.
Failure: A cherry-picked demonstration is generalized.
Safeguard: Repeated trials and success distributions.
Failure: Weak elicitation creates a false negative.
Safeguard: Multiple elicitation tracks and external challenge.
Failure: Precise thresholds create authority without strong evidence.
Safeguard: Uncertainty, ranges, review, versioning, and explicit assumptions.
Failure: Institutions evaluate only known categories.
Safeguard: Open-domain review and early-signal monitoring.
Failure: Ordinary harms receive insufficient attention.
Safeguard: Separate but coordinated evaluation portfolios.
Failure: Too many capabilities are labeled high stakes.
Safeguard: Explicit criteria, proportionality, and review.
Failure: Emerging systemic pathways are missed.
Safeguard: precursor evaluation, trend analysis, incident feedback.
Failure: Interested party controls evidence and decision.
Safeguard: Independent review and external access.
Failure: External review lacks time, information, or system access.
Safeguard: Access-level reporting and decision limits.
Failure: Tasks are difficult but not operationally meaningful.
Safeguard: Domain experts, real workflows, outcome validation.
Failure: Testing creates harmful capability, data, or access.
Safeguard: safety review, proxies, containment, disclosure control.
Failure: Capability is measured without testing risk reduction.
Safeguard: parallel safeguard evaluation.
Failure: Model score is applied to a different deployed system.
Safeguard: system-specific evaluation and deployment envelope.
Failure: Thresholds favor incumbents or political interests.
Safeguard: transparent development, diverse participation, appeals, cost analysis.
Failure: Incompatible frameworks create duplicated burden and weak comparison.
Safeguard: shared metadata and interoperability.
Failure: Technical findings become sensationalized.
Safeguard: claims boundary, uncertainty, domain-specific explanation.
Failure: Old evidence supports new deployment.
Safeguard: expiration and re-evaluation triggers.
Failure: Complex evidence is compressed into one score.
Safeguard: multidimensional capability profiles.
The choice of what counts as severe reflects values.
Response:
Residual concern:
No classification can be entirely value-neutral.
Response:
Residual concern:
Some early-warning work will remain uncertain by design.
Response:
Residual concern:
Thresholds can still become false precision.
Response:
Residual concern:
Some evaluation research may still increase dual-use knowledge.
They have access and expertise.
Response:
Developer evaluation is indispensable.
Independent evaluation adds challenge, legitimacy, and alternative assumptions.
Residual concern:
External evaluators may remain under-resourced or under-accessed.
Response:
Residual concern:
Compliance burden can still advantage large firms.
Response:
Evaluation can still inform:
Residual concern:
Post-release control is limited.
Often true.
Response:
Include actor uplift, access, deployment, and institutional vulnerability.
Response:
Build proportionate early-warning methods and avoid claiming current severe capability without evidence.
Residual concern:
Institution building can create self-reinforcing incentives.
Correct.
Response:
Treat them as evidence and experiments, not settled standards.
Correct.
Response:
Correct.
Response:
High-stakes evaluation should support safe benefit realization, not assume prohibition.
How strongly do evaluation results predict severe real-world outcomes?
Which baselines best measure the increase in actor capability?
What success frequency makes a capability operationally material?
How should component skills and integrated performance be combined?
How close do current methods come to plausible maximum capability?
Which evaluations predict harmful or deceptive behavior in deployment?
How should adaptive adversaries and defense-in-depth be evaluated?
How can thresholds remain actionable without false precision?
How do task length, environment, and scaffold affect autonomy estimates?
How do cyber, scientific, autonomy, persuasion, and AI-R&D capabilities combine?
Which risks emerge only through interaction?
What evaluator access is necessary for different claims?
How should capability evidence translate into decisions when weights are broadly available?
What evidence should support cross-border acceptance?
Do high-stakes frameworks improve outcomes enough to justify burden and cost?
Develop domain-specific graphs connecting component skills to end-to-end outcomes.
Compare evaluation results with controlled real-world performance.
Study when occasional success becomes practically significant.
Create consistent baselines across actor expertise and resources.
Test prompting, scaffolding, tools, fine-tuning, and inference budgets.
Develop adaptive attack distributions and defense-in-depth metrics.
Improve long-horizon, process, autonomy, and control measurement.
Pilot alert bands, uncertainty-aware triggers, and independent review.
Study combinations that create greater capability than individual scores imply.
Evaluate coordination, collusion, cascading failure, and oversight.
Define minimum access for credible claims.
Develop methods for sensitive domains that reduce evaluation-induced risk.
Connect pre-deployment evidence to incidents and operational behavior.
Create common metadata, evidence categories, and result status.
Study whether capability frameworks create capture, concentration, or perverse incentives.
Compare question-answer performance with end-to-end tool-using tasks in one domain.
Measure capability across repeated attempts and resource budgets.
Compare lay, trained, and expert users with and without AI assistance.
Run default, standardized, developer-supported, and externally optimized configurations.
Test an uncertainty-aware alert band rather than a single cutoff.
Allow red teams to adapt attacks across multiple rounds.
Test the same model with different tools, permissions, monitoring, and user populations.
Construct and validate a directed graph for an autonomous cyber pathway.
Test whether moderate capabilities combine into unexpected end-to-end performance.
Compare evaluator findings under black-box, grey-box, and richer-access conditions.
Determine whether prior evaluations would have predicted known failures.
Compare single-agent and multi-agent performance under shared objectives and competition.
A future high-stakes capability evaluation standard could require:
Specify the risk domain and harm pathway.
Define component and end-to-end capabilities.
Document model, scaffold, tools, safeguards, and deployment.
Separate early warning, operational capability, and critical capability.
Document methods and resources used to reveal capability.
Use dynamic, held-out, expert, and realistic tasks.
Include relevant human and system comparisons.
Measure repeated success and uncertainty.
Test controls against representative and adaptive threats.
Assess access, scale, tools, monitoring, and vulnerability.
Require appropriate external scrutiny.
Define triggers, authority, review, and appeal.
Publish evidence, limitations, configuration, confidence, and expiration.
Define update and incident triggers.
Control evaluation-induced risk and sensitive disclosure.
Such a standard should be developed through the future STANDARDS_DEVELOPMENT_PROCESS.md.
High-stakes tests must evolve as capability, threats, and deployment change.
Protected tasks reduce leakage and targeted optimization.
Consequential judgments require qualified external scrutiny.
Scaled evaluation requires competent independent organizations.
Capability evidence can trigger increasingly formal safeguards and institutional responses.
Organizations should receive recognition for rigorous evaluation and transparent risk reduction.
Shared evidence should support cross-border understanding without requiring identical policy.
Standards Body adopts the following working positions.
Not every AI capability requires the same evaluation burden.
Evaluation rigor should increase with the potential consequence of error.
High-stakes capability is not synonymous with frontier model, legal high-risk use, or prohibited technology.
Capability is necessary evidence for many risk judgments, but capability alone is not risk.
High-stakes assessment should consider capability, propensity, access, exposure, vulnerability, safeguards, consequence, and uncertainty.
A single aggregate score is generally insufficient.
Knowledge tests should not be treated as proof of operational capability.
Component evaluations should be paired with end-to-end evaluation where feasible.
Reliability, autonomy, resource requirements, and human uplift are core dimensions.
Evaluations should distinguish typical, standardized, developer-elicited, externally elicited, and plausible maximum capability.
High-stakes protocols should use dynamic and held-out components.
Domain experts should participate meaningfully.
Capability thresholds should trigger defined processes, not function as unexplained labels.
Alert thresholds should precede critical thresholds where early preparation is valuable.
Threshold uncertainty should be explicit.
False positives and false negatives both create serious costs.
Capability and safeguard evaluations should be reported separately.
The deployed system, not only the base model, should be evaluated.
External evaluator access should be reported as part of evidentiary confidence.
Developer evaluation is essential but should not be the sole basis for the most consequential claims.
Independent evaluators should remain accountable and appealable.
High-stakes evaluation should not unnecessarily suppress beneficial dual-use capability.
Present harms and severe frontier risks require separate but coordinated evaluation portfolios.
Sensitive evaluations require proportionate security.
Passing an evaluation is not proof of safety.
Failure to elicit a capability is not proof of inability without strong methods.
Evaluation evidence should expire or trigger re-evaluation after material changes.
Incidents should update capability models and protocols.
International interoperability is preferable to one universal threshold.
The evaluation regime itself should be evaluated for capture, burden, and effectiveness.
A capability should enter enhanced evaluation when:
A capability should be classified as operationally high stakes only when evidence supports:
A capability should not be classified as operationally high stakes merely because:
A threshold result should be suspended when:
A system should be re-evaluated when:
Claim:
Domain:
System:
Protocol version:
Date:
Domain:
Current threshold:
Proposed threshold:
Proposer:
Date:
| Dimension | Core Question |
|---|---|
| Decision | Is the evaluation linked to a defined decision? |
| Domain | Is the risk domain specific and defensible? |
| Harm pathway | Is the route from capability to consequence explicit? |
| Capability graph | Are component and end-to-end abilities mapped? |
| Evaluated system | Are model, tools, scaffold, and safeguards specified? |
| Task validity | Do tasks represent the capability? |
| Dynamic quality | Can the protocol evolve with capability? |
| Holdout integrity | Is targeted optimization controlled? |
| Elicitation | Was performance seriously elicited? |
| Reliability | Is success operationally consistent? |
| Baselines | Are human and system comparisons appropriate? |
| Uplift | Is AI-enabled improvement measured? |
| Autonomy | Is independent action measured? |
| Generalization | Does capability transfer across tasks and contexts? |
| Safeguards | Are controls evaluated against realistic attacks? |
| Deployment | Are access, scale, tools, and monitoring included? |
| Consequence | Are severity, scale, speed, and reversibility considered? |
| Uncertainty | Are evidence gaps and error risks explicit? |
| Independence | Is there qualified external review? |
| Access | Did evaluators receive enough access for the claim? |
| Security | Is sensitive evaluation conducted safely? |
| Threshold | Is the trigger justified and governed? |
| Appeals | Can material errors be challenged? |
| Freshness | Is re-evaluation or expiration defined? |
| Interoperability | Can others understand and compare the evidence? |
| Burden | Is the evaluation proportionate? |
| Decision utility | Does the result improve an actual decision? |
The central problem of high-stakes AI evaluation is not identifying everything a model can do.
No institution can test every possible task, actor, environment, tool, deployment, or failure.
The problem is deciding where uncertainty is no longer acceptable.
When an AI system can act in domains involving cyber operations, biological research, critical infrastructure, autonomous replication, large-scale manipulation, or accelerated AI development, ordinary benchmark practice may no longer provide enough evidence.
The evaluation must become more realistic.
The elicitation must become more serious.
The safeguards must become part of the test.
The deployment context must become visible.
The uncertainty must become explicit.
The reviewers must become more independent.
The result must connect to a decision.
This does not require assuming that advanced AI will cause catastrophe.
It requires recognizing that consequence changes the standard of proof.
A weak evaluation can create harm in two directions.
It can miss a capability and enable reckless exposure.
It can exaggerate a capability and enable fear, concentration, and unnecessary restriction.
The goal is neither alarm nor reassurance.
The goal is justified confidence.
High-stakes capability evaluation should help society distinguish:
The third foundation of Standards Body is therefore proportional scrutiny.
Where the consequences of error are greatest, the evidence should be strongest.
[^nist-rmf]: National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
[^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-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
[^eu-ai-act]: European Union, Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence, Official Journal of the European Union, 2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
[^openai-pf2]: OpenAI, Preparedness Framework, Version 2, April 15, 2025. https://cdn.openai.com/pdf/18a02b5d-6b67-4cec-ab64-68cdfbddebcd/preparedness-framework-v2.pdf
[^openai-frontier]: OpenAI, Frontier Governance Framework, May 28, 2026. https://openai.com/index/openai-frontier-governance-framework/
[^openai-bio]: OpenAI, Preparing for Future AI Capabilities in Biology, June 18, 2025. https://openai.com/index/preparing-for-future-ai-capabilities-in-biology/
[^deepmind-fsf3]: Google DeepMind, Frontier Safety Framework, Version 3.0, September 2025. https://storage.googleapis.com/deepmind-media/DeepMind.com/Blog/strengthening-our-frontier-safety-framework/frontier-safety-framework_3.pdf
[^anthropic-rsp3]: Anthropic, Responsible Scaling Policy, Version 3.0, February 24, 2026. https://www.anthropic.com/responsible-scaling-policy/rsp-v3-0
[^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-agenda]: UK AI Security Institute, Research Agenda. https://www.aisi.gov.uk/research-agenda
[^aisi-elicitation]: UK AI Security Institute, A Structured Protocol for Elicitation Experiments, July 16, 2025. https://www.aisi.gov.uk/blog/our-approach-to-ai-capability-elicitation
[^aisi-safeguards]: UK AI Security Institute, Principles for Evaluating Misuse Safeguards of Frontier AI Systems, 2025. https://www.aisi.gov.uk/research/principles-for-evaluating-misuse-safeguards-of-frontier-ai-systems
[^aisi-actionable]: UK AI Security Institute, Making Safeguard Evaluations Actionable, May 29, 2025. https://www.aisi.gov.uk/blog/making-safeguard-evaluations-actionable
[^aisi-trends]: UK AI Security Institute, Frontier AI Trends Report, 2025. https://www.aisi.gov.uk/frontier-ai-trends-report
[^aisi-cyber-eval]: UK AI Security Institute, Our Evaluation of OpenAI's GPT-5.5 Cyber Capabilities, April 30, 2026. https://www.aisi.gov.uk/blog/our-evaluation-of-openais-gpt-5-5-cyber-capabilities
[^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
[^dangerous-repository]: Google DeepMind, Dangerous Capability Evaluations Repository. https://github.com/google-deepmind/dangerous-capability-evaluations
[^stealth]: Mary Phuong et al., Evaluating Frontier Models for Stealth and Situational Awareness, 2025. https://arxiv.org/abs/2505.01420
[^external-access]: Jacob Charnock et al., Expanding External Access to Frontier AI Models for Dangerous Capability Evaluations, 2026. https://arxiv.org/abs/2601.11916
[^deepmind-cyber]: Google DeepMind, Evaluating Potential Cybersecurity Threats of Advanced AI, April 2, 2025. https://deepmind.google/blog/evaluating-potential-cybersecurity-threats-of-advanced-ai/
[^deepmind-multiagent]: Google DeepMind, Investing in Multi-Agent AI Safety Research, June 11, 2026. https://deepmind.google/blog/investing-in-multi-agent-ai-safety-research/
[^aisi-safety-cases]: UK AI Security Institute, Safety Cases at AISI, 2024. https://www.aisi.gov.uk/blog/safety-cases-at-aisi
[^frontier-model-forum]: Frontier Model Forum, Issue Brief: Components of Frontier AI Safety Frameworks, 2024. https://www.frontiermodelforum.org/updates/issue-brief-components-of-frontier-ai-safety-frameworks/
[^amazon-framework]: Amazon, Frontier Model Safety Framework, February 2025. https://www.amazon.science/publications/amazons-frontier-model-safety-framework
Date: July 16, 2026
Change type: Complete replacement
Summary: Replaces the earlier outline edition with a fully developed canonical working white paper. Adds a complete risk model, high-stakes classification framework, domain-specific evaluation chapters, capability decomposition, elicitation methodology, threshold theory, evidence standards, false-positive and false-negative analysis, safeguard evaluation, deployment-context analysis, lifecycle governance, security, international interoperability, maturity model, implementation pathway, a Standards Body autonomous-cyber pilot, metrics, failure analysis, objections, evidence gaps, research agenda, standards implications, templates, scorecard, and current primary-source research basis.
Status: Ready for internal review and future expert critique.