Standards Body · Foundational source, public edition · Released July 17, 2026
Canonical record: https://standardsbody.ai/library/foundational-source/evaluation-philosophy/
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.
Project: Standards Body
Primary domain: standardsbody.ai
Core line: Foundations for Frontier AI
Document type: Canonical philosophy of evaluation, measurement, interpretation, and decision use
Version: 1.0
Status: Approved foundational source
Document owner: Standards Body
Applies to: All Standards Body evaluations, protocols, benchmarks, task suites, evidence cases, review processes, standards proposals, assurance activities, public claims, registries, pilots, research programs, and institutional decisions
Related canonical sources: PROJECT_IDENTITY.md, TERMINOLOGY.md, FOUNDATIONS.md, FOUNDATIONS_APPENDIX.md, EVIDENCE_STANDARDS.md, RESEARCH_METHODOLOGY.md, TAXONOMY.md, and the eight foundation papers
Research basis reviewed through: July 16, 2026
Review cycle: Annual review, with event-triggered revision following material advances in frontier AI capability, evaluation science, measurement theory, model behavior, assurance practice, or institutional use
This document states the evaluation worldview of Standards Body.
It does not:
Where a law, regulation, contract, recognized standard, ethics requirement, or domain-specific professional obligation imposes a stronger requirement, the stronger requirement governs.
This document explains what evaluation is for, what makes it meaningful, how it should be interpreted, and where its authority ends.
It is the canonical source for Standards Body positions on:
This document exists because the word evaluation is often used to describe very different activities.
A one-page benchmark leaderboard, a controlled red-team exercise, a year-long field study, a system card, a management-system audit, a held-out capability test, and an accredited laboratory assessment may all be described as evaluation.
They are not equivalent.
Their evidence differs in:
A credible institution must preserve those distinctions.
The governing philosophical position is:
Evaluation is the structured production and interpretation of evidence for a bounded claim or decision under uncertainty.
Evaluation is not a score.
Evaluation is not proof of safety.
Evaluation is not a substitute for judgment.
Evaluation is not valid merely because it is quantitative, hidden, difficult, expensive, official, or conducted by a prestigious institution.
Evaluation earns authority when the inference from observed evidence to the intended claim is justified.
Frontier AI evaluation is often treated as a contest.
Models are ranked.
Scores are announced.
A result is compressed into one number.
The number is then used to support claims about intelligence, safety, risk, progress, deployment readiness, or social consequence.
This is understandable.
Numbers are portable.
Leaderboards are legible.
Benchmarks create a shared reference point.
They can reveal real capability differences.
They can also produce false confidence.
A benchmark may be saturated, contaminated, narrow, poorly scored, unrepresentative, under-elicited, overfit, or disconnected from the decision it is used to support.
A model may perform well on short, clean tasks and poorly on long, ambiguous work.
A system may perform better than its base model because of tools, memory, scaffolding, or human support.
A system may perform worse in deployment because of latency, cost, user behavior, changing environments, or unreliable integration.
A hidden test may reduce direct gaming while remaining invalid.
A public test may support reproducibility while becoming less informative over time.
A red team may identify important failures without estimating their frequency.
A mechanism-based finding may reveal internal structure without proving operational behavior.
An operational incident may reveal a real failure pathway without establishing general prevalence.
Evaluation therefore requires a philosophy of inference.
The Standards Body position can be summarized through twelve propositions.
An evaluation should answer:
A test without an intended interpretation may produce data, but it does not yet produce a justified institutional conclusion.
The object may be:
A model name alone is rarely enough for a consequential result.
The central validity question is:
Does the evidence support the intended interpretation and use?
A benchmark is not valid in the abstract.
It may be useful for one claim and invalid for another.
A consistently wrong or narrow measure can be reliable.
A valid evaluation should normally be sufficiently reliable for its intended decision, but reliability alone does not establish construct validity, generalization, fairness, or practical relevance.
Prompts, tools, retries, scaffolds, fine-tuning, time, compute, human assistance, and environment affect measured capability.
A result without these conditions is incomplete.
Capability evidence may inform risk.
Risk also depends on:
Consequential decisions should normally combine:
Frontier systems, tasks, threats, and methods change.
Protocols need:
Protected tasks can preserve validity.
Transparent governance preserves legitimacy.
Exact content may be confidential while purpose, construct, method class, evaluator role, uncertainty, limitations, and result status remain visible.
Failure to demonstrate a capability may result from:
The preferred default conclusion is:
The capability was not demonstrated under the assessed conditions.
Evaluators select:
These choices require governance, not only technical execution.
Evaluation cannot prove:
The deepest Standards Body position is:
Evaluation is structured evidence for bounded decisions under uncertainty, not a machine for converting complex systems into certainty.
Evaluation authority comes from a justified inference between:
No consequential evaluation is interpretable without a sufficiently precise identity for the evaluated object.
The protocol, not the task set alone, is the proper unit of evaluation governance.
Evaluation conditions are constitutive of the result.
They are not incidental metadata.
No single evaluation method should be expected to answer every material question about capability, risk, safeguards, reliability, or deployment.
Evaluation rigor, independence, security, and evidence burden should increase with the consequence of error.
Evaluation results decay as systems, environments, threats, and methods change.
Evaluation content should remain protected when exposure would materially weaken measurement or increase harm.
Protection of content should not eliminate transparency about governance, purpose, scope, status, and limitations.
An observed failure may reflect a failure to elicit, not a lack of underlying capability.
A model-level result should not be assumed to represent every system or deployment built from that model.
Capability, propensity, access, safeguards, and consequence are distinct elements.
Evaluation does not remove judgment.
It disciplines judgment through explicit methods, evidence, uncertainty, and review.
A credible evaluation system must support correction, supersession, withdrawal, and retirement.
The evaluator, protocol, scoring system, threshold, and institution should themselves be evaluated.
This philosophy applies to evaluation of:
This document does not claim that:
Specialized evaluation may require additional methods.
Examples:
Definitions in TERMINOLOGY.md govern.
A structured process for producing and interpreting evidence about a model, system, method, process, control, organization, or claim.
A defined procedure used to observe or measure one or more characteristics.
A standardized set of tasks, procedures, and metrics used for comparison.
The complete versioned specification governing purpose, construct, scope, tasks, administration, configuration, elicitation, scoring, analysis, security, reporting, and change control.
The underlying concept or attribute an evaluation intends to measure.
The degree to which evidence and theory support the intended interpretation and use of evaluation results.
The consistency of measurement across repetitions, tasks, raters, environments, or conditions.
The degree to which findings apply beyond the specific evaluated examples or conditions.
The process of configuring prompts, tools, examples, scaffolds, resources, or procedures to reveal available capability.
The degree to which design, administration, security, scoring, evidence, and reporting preserve the intended meaning of a result.
A system's ability to recognize or infer that it is being evaluated.
Deliberate or strategically selective underperformance intended to conceal capability.
Evidence arising from use or realistic operation rather than isolated test tasks alone.
Evidence concerning internal representations, processes, circuits, causal mechanisms, or computational structure.
The explicit relationship between an evaluation result and a decision, claim, threshold, or action.
The point or trigger after which a result should no longer be treated as current without review.
Evaluation serves several distinct functions.
They should not be collapsed.
Evaluation can describe observed behavior or performance.
Example:
The system completed 42 percent of tasks under the stated protocol.
Evaluation can compare:
Comparison requires comparability.
Evaluation can identify:
Evaluation can estimate future or out-of-sample behavior.
Predictive interpretation requires validation against future or operational outcomes.
Evaluation can reduce uncertainty for:
Evaluation can allow others to assess whether claims and obligations are justified.
Evaluation can improve:
Evaluation can detect movement toward a consequential capability before a critical threshold is reached.
Evaluation can contribute evidence to an assurance conclusion.
It is not identical to assurance.
Evaluation can inform the public.
Public communication requires stricter claim discipline because simplified scores are easily overinterpreted.
Every evaluation should declare its primary and secondary functions.
A diagnostic test should not be marketed as a certification.
A research benchmark should not be presented as deployment authorization.
A capability screen should not be presented as a complete risk assessment.
Evaluation has three simultaneous identities.
It assigns observations, scores, categories, or judgments to an object according to a method.
It investigates an uncertain question.
It may generate:
It distributes:
A benchmark can shape research priorities.
A threshold can shape deployment.
A certification scheme can shape markets.
A regulator can incorporate an evaluation into law.
The institutional effect can exceed the technical strength of the measurement.
As the institutional consequence of an evaluation grows, requirements should increase for:
Frontier AI results are often attached to names that do not uniquely identify the evaluated object.
A name may conceal:
The learned model or checkpoint.
The model plus prompts, tools, scaffolds, interfaces, safeguards, and infrastructure.
The system under actual access, user, scale, sector, and governance conditions.
The combined performance of people and AI systems.
The institution's processes, controls, and practices.
A consequential evaluation should record:
Evidence should not be inherited automatically across:
A change is material when it could alter:
Where exact identity is unavailable, the result should state the uncertainty and narrow the claim.
A construct should answer:
What underlying attribute is the evaluation intended to measure?
Examples:
The construct may not be directly observable.
Evaluation observes:
and infers the construct.
An evaluation underrepresents the construct when it covers too little of the relevant domain.
A result may vary because of irrelevant factors.
Examples:
A proxy can be useful.
It becomes dangerous when treated as the construct itself.
The meaning of a construct may change as:
A score should identify:
A ranking does not imply equal distance.
A ten-point difference may not have the same meaning across the scale.
A threshold is an institutional decision boundary.
It is not necessarily a natural discontinuity in capability or risk.
A high-consequence evaluation should maintain an explicit validity argument containing:
Validity is the central philosophical problem of evaluation.
The question is not:
Is this benchmark valid?
The better question is:
For which interpretation and use does this evidence provide sufficient support?
Modern measurement theory treats validity as an integrated evaluative judgment about the degree to which evidence and theory support interpretations of scores for intended uses.[^standards-testing][^messick]
Does the evaluation adequately represent the relevant domain?
Questions:
Does the evaluation measure the intended capability or property?
Evidence may include:
Does the evaluation relate to an external criterion?
Examples:
Do the tasks and conditions resemble relevant operational environments?
Ecological validity is not always required.
A controlled test may isolate an important component.
The claim should reflect the level of realism.
Does the design support the claimed comparison or causal conclusion?
Can the result generalize to:
How does the use of the evaluation affect:
The consequences of score use can reveal weaknesses in the evaluation system.
Validity should be supported by an accumulating evidence case.
One correlation, expert endorsement, or leaderboard result is rarely enough for consequential use.
A short-answer benchmark may be useful for:
It may be invalid for:
Review validity after:
Reliability concerns consistency.
Sources of inconsistency include:
Would repeated evaluation under materially equivalent conditions produce similar results?
Do qualified judges apply the scoring criteria consistently?
High agreement can coexist with systematic bias.
Do items intended to measure a common construct produce coherent evidence?
High internal consistency does not prove that the construct is correct.
Do alternate task forms support comparable conclusions?
This is important for dynamic and held-out evaluation.
Do different organizations implementing the same protocol produce comparable results?
Differences may arise from:
Robustness asks whether the result remains meaningful under relevant variation.
Variation may include:
Increasing standardization may increase reliability while reducing realism.
Open-world evaluation may increase realism while increasing measurement noise.
The correct balance depends on the decision.
Reliability should be sufficient for the claim.
A research screen may tolerate more noise than a binding threshold.
Repeated-run performance should be reported as a distribution where feasible.
Avoid presenting one favorable run as representative.
Does performance extend beyond the exact task items?
Does performance extend across related professional or technical domains?
Does capability persist under different tools, interfaces, and constraints?
Does a result remain applicable after time passes or the system changes?
Does the construct remain valid across language, cultural, and institutional contexts?
Does controlled performance predict actual use?
Deployment introduces:
Useful evidence includes:
A result should state the population and conditions to which it is intended to generalize.
Benchmarks can provide:
Benchmarks may suffer from:
Interdisciplinary reviews of AI benchmarking have documented recurring concerns concerning construct validity, contamination, comparability, reporting, and institutional effects.[^benchmark-review]
A protocol includes more than a benchmark.
It should specify:
A benchmark may be one component in a portfolio.
It should not automatically define the entire evaluation conclusion.
Leaderboards should be limited when:
A harder benchmark may:
Difficulty should serve the construct.
A benchmark can become influential as a public signal even after its scientific value declines.
Institutions should monitor both roles.
Public tasks support:
They also permit:
Held-out evaluation protects content or administration details before testing when exposure would weaken evidence.
Protection may apply to:
A secret task can be:
Protection preserves only the value the instrument already has.
Evaluated parties should ordinarily understand:
Fair notice does not require disclosure of exact active items.
A credible held-out system requires:
A strong program often combines:
Static instruments lose meaning as:
A dynamic protocol should preserve a stable core:
while allowing controlled changes to:
Triggers may include:
Dynamic protocols should use:
Do not preserve a historical trend line when the meaning of the measurement changed materially.
Every consequential result should have:
A protocol should be retired when:
NIST frames TEVV as a lifecycle activity rather than a one-time endpoint, and its AI RMF Measure function emphasizes documented test sets, metrics, tools, and ongoing assessment.[^nist-rmf][^nist-measure]
Observed performance is a function of:
A capability ceiling estimate asks:
What performance is plausibly available under defined, sufficiently strong elicitation?
It is not a claim about unlimited hypothetical optimization.
An evaluation may measure:
Ordinary use without specialized optimization.
Performance under a common protocol.
Performance after documented, bounded optimization.
Performance under practical product conditions.
Performance when evaluators actively seek hidden or difficult-to-obtain capability.
Record:
Developers may improve elicitation by providing:
Developer input should not give the developer unilateral control of the conclusion.
Independent evaluators may discover performance not demonstrated internally.
Under-elicitation creates false negatives.
An elaborate, task-specific system may demonstrate potential capability that is unavailable to ordinary users.
This can still matter for security or future capability.
The result should state the access and resources required.
AISI has published a structured approach to capability elicitation experiments, reflecting the need to treat elicitation as a research object rather than an informal prompt-tuning step.[^aisi-elicitation]
Tools may transform capability.
Examples:
Report separately where possible:
Scaffold performance can depend on:
Do not attribute the full system result to the model alone.
The protocol should identify which components are inside the evaluated system.
Human assistance may include:
Record frequency and function.
Practical capability should account for:
Many consequential tasks require:
Short tasks may miss these properties.
Task horizon may be represented by:
METR's time-horizon research estimates the length of tasks that AI agents can complete at specified success probabilities, offering one useful operational lens on long-horizon capability while retaining domain and task-sampling limitations.[^metr-time]
Success or failure should be supplemented by trajectory analysis.
Long tasks may require decomposition into:
A 50 percent success probability may be informative for capability tracking.
It may be insufficient for operational use.
Open-world evaluations use less standardized, messier, longer, and more realistic tasks.
They can reveal capabilities missed by benchmark-scale testing, but they require strong qualitative judgment and careful small-sample interpretation.[^open-world-evals]
Long-horizon environments should be:
Adversarial evaluation attempts to find failure, bypass, or harmful behavior under challenging conditions.
Red teaming may involve:
Red teaming can identify:
Red teaming generally does not establish:
Adversarial evaluation should identify:
Safeguards should be tested against attackers who respond to defenses.
A red team should have sufficient freedom to select attack methods.
Record:
Preferred conclusion:
The exercise identified the following failure pathways under the assessed threat model.
Avoid:
The system passed red teaming and is safe.
A system may detect cues that distinguish evaluation from deployment.
Cues may include:
If behavior changes in recognized evaluation contexts, the validity of deployment claims may weaken.
Sandbagging is one possible explanation for selective underperformance.
Other explanations include:
Possible methods:
Failure to detect sandbagging does not prove that strategic concealment is impossible.
Anthropic's sabotage-evaluation work includes explicit tests of sandbagging, oversight undermining, and agent behavior in complex environments, illustrating that evaluator deception can itself become an evaluation target.[^anthropic-sabotage]
Evaluation-awareness risk should influence:
No single evidence type should dominate every evaluation question.
Behavioral evidence concerns observable outputs and actions.
Strengths:
Limits:
Mechanistic evidence concerns internal processes or representations.
Possible methods:
Strengths:
Limits:
Operational evidence arises from realistic or actual use.
Examples:
Strengths:
Limits:
Organizational evidence concerns:
Documents show intended process.
Operational records show whether the process functions.
A high-stakes conclusion should combine evidence types where feasible.
Example:
A cyber-capability claim may use:
If behavioral, mechanistic, and operational evidence conflict:
Mechanistic evidence is not automatically deeper truth.
Operational evidence is not automatically representative.
Behavioral evidence is not automatically superficial.
Weight depends on the claim.
Human baselines can support:
Define:
Human and AI comparisons should consider:
A system should be called superhuman only relative to a defined human group and conditions.
Many deployments involve teams rather than replacement.
Evaluate:
Uplift may concern:
AI can reduce human performance through:
METR's study of experienced open-source developers found a gap between perceived and measured productivity in one defined setting, illustrating why human-AI outcomes should be measured rather than inferred from user belief alone.[^metr-developer-study]
Uplift may differ by:
Average uplift can hide harm to a subgroup.
Capability concerns what the system can do under defined conditions.
Propensity concerns the likelihood that the system will display or pursue a behavior under relevant conditions.
Access concerns who can use the capability and with what permissions.
Exposure concerns which people, institutions, or systems are subject to the hazard.
Safeguards modify practical risk.
Consequence concerns the magnitude and distribution of harm.
A useful risk evaluation should distinguish at least:
A system may have:
Report each component.
Safeguard evidence should include:
A capability threshold may trigger a risk-management process.
It should not substitute for that process.
Frontier safety frameworks used by developers increasingly connect capability levels to additional evaluations and safeguards, but these frameworks remain institution-specific and should not be treated as universal proof of risk or safety.[^openai-pf][^deepmind-fsf]
Thresholds can trigger:
A score boundary.
A required level of support.
An early-warning point.
A capability level associated with severe-risk concern.
A deployment or control trigger.
A boundary defined by law or regulation.
A threshold should consider:
Avoid false precision.
A threshold may be represented as:
A crossing should trigger:
Near-threshold results require caution because measurement noise can change classification.
Thresholds should be versioned and reviewed after:
Record:
Some research evaluations are exploratory.
They should still state likely and invalid uses.
For consequential evaluation, identify:
A statistically significant difference may be irrelevant to the decision.
A small qualitative finding may be decisive if it reveals a severe failure pathway.
A false positive may:
A false negative may:
Under high uncertainty, prefer decisions that preserve learning and correction where possible.
Evaluation can estimate:
It cannot independently decide:
An evaluation should produce an uncertainty account, not only a point estimate.
Use when supported:
Use structured language when quantification would mislead.
Distinguish uncertainty due to:
when useful.
State:
Diverse review, stress testing, incident monitoring, and humility help address unknown failure modes.
They do not eliminate them.
Public summaries should not remove uncertainty merely for simplicity.
A scoring rule should be:
Exact match is efficient but may penalize equivalent answers or reward superficial form.
Human judges offer nuance but introduce:
Model judges offer scale.
They require validation for:
Objective environment outcomes can improve directness.
They may still encode narrow success definitions.
Partial credit can reveal capability structure.
It can also introduce judgment complexity.
Aggregation can support communication.
It can hide:
Weights should be justified by:
Some critical failures should not be offset by strengths elsewhere.
Report uncertainty around:
Do not compare scores when:
An evaluation may be unfair if irrelevant barriers alter results.
Examples:
Removing irrelevant barriers does not require lowering the construct standard.
For high-consequence evaluation, provide:
Evaluation should also consider people affected by system use.
A process can be fair to a developer while ignoring public harm.
Localization may require:
Literal translation may change:
Evaluation requirements can privilege actors with:
Standards should support:
Frontier evaluation increasingly reaches areas where plausible-looking tasks can be technically wrong.
Domain experts support:
A domain expert may lack:
A strong team combines expertise.
Disagreement may concern:
Preserve material dissent.
High-quality evaluation can depend on scarce expert labor.
This affects:
Where experts estimate probabilities or levels, use structured judgment and calibration where feasible.
Evaluators choose:
Strengths:
Limits:
Strengths:
Limits:
Independence requires more than organizational separation.
Apply FOUNDATION_04_INDEPENDENT_EXPERT_REVIEW.md.
Competence should be scoped by:
Commercial incentives can produce:
Government or public evaluators may have:
They may also face:
Community evaluation can reveal:
It requires provenance, ethics, and security.
A plural evaluation ecosystem reduces dependence on one institution's assumptions.
Evaluation may examine:
Evaluation may track:
Evaluation may assess the candidate model and system.
Evaluation should connect capability, safeguards, access, and deployment.
Monitor:
Continuous evaluation may combine:
OpenAI's Preparedness Framework emphasizes scalable recurring evaluation complemented by expert-led deeper assessment, illustrating one institutional response to faster model-update cadence.[^openai-pf-update]
Triggers include:
Results should display:
Older systems may remain deployed after the evaluation framework changes.
Create:
A result claim should identify:
Preferred:
Demonstrated the defined capability under the assessed conditions.
Avoid:
Possesses the capability in all contexts.
Preferred:
Did not demonstrate the capability under the assessed conditions.
Avoid:
Cannot perform the task.
Preferred:
Met the specified safeguard criteria under the assessed threat model.
Avoid:
Certified safe.
State whether differences are:
A public summary should preserve:
Report multidimensional profiles rather than one score where consequence is high.
A result should be corrected or withdrawn after:
Evaluation is powerful because it makes claims testable.
Evaluation is dangerous when it creates an illusion that every important question has been resolved.
A result is bounded by:
Frontier systems may face:
Failure to observe a behavior can reflect:
Deployment can differ from evaluation in:
Measurement cannot determine by itself:
Testing may reveal vulnerabilities.
Security also requires:
Evidence needs institutions to:
Models and systems change.
Users adapt.
Attackers learn.
The evaluator may be:
Millions of task results do not solve a wrong measurement target.
Confidential evidence needs independent governance.
A result with three decimal places may still be conceptually weak.
A credible system plans for incidents and revision.
Different methods reveal different properties.
A portfolio reduces dependence on one instrument.
Useful for:
Useful for:
Useful for:
Useful for:
Useful for:
Useful for:
Useful for:
Useful for:
Useful for:
A portfolio should be designed against:
Overlapping methods can provide corroboration.
Methods should fail differently.
Several benchmarks using the same task format may not provide real diversity.
Weight methods by:
Conflicting results should remain visible.
Add, revise, or remove components after:
Safeguards work against defined threats and contexts.
Evaluate:
Do not assume independent protection where controls share:
Record:
Safeguards can create:
Controls may weaken as:
A safeguard result should never be generalized beyond the assessed threat model without additional evidence.
Written policy is evidence of formal intention.
It is not sufficient evidence of effective implementation.
Evaluate both:
Was the required procedure followed?
Did the process improve the relevant result?
Possible indicators:
An audit or certification may establish conformity with criteria.
It does not establish that every organizational outcome is effective.
Organizations may optimize:
without improving the underlying objective.
Where appropriate, institutional evaluation may include:
The same requirement may produce different outcomes under different:
Meta-evaluation is evaluation of evaluation.
Possible metrics:
A judge should be evaluated for:
An evaluator should be evaluated for:
The final question is not only:
Did the evaluation run correctly?
It is also:
Did the evaluation system improve decisions and reduce error?
Characteristics:
Characteristics:
Characteristics:
Characteristics:
Characteristics:
Characteristics:
A large number of benchmarks does not establish mature evaluation.
Maturity depends on the quality of inference, governance, integrity, and use.
Identify:
State the exact proposition.
Create the model or system manifest.
Describe:
Choose a portfolio appropriate to the claim.
Define:
Set:
Use:
Apply:
Preserve:
Report:
Use qualified and independent challenge.
Connect the result to:
Apply appropriate transparency and security.
Track:
Change status visibly.
Evaluation ID:
Title:
Version:
Owner:
Date:
Status:
Evaluation:
Protocol version:
Claim:
Intended use:
How are observations converted into scores or findings?
Why should the task sample represent the relevant domain?
Why should controlled results apply to the intended setting?
Why is the result relevant to the decision?
Result ID:
System ID and version:
Protocol ID and version:
Evaluator:
Date:
Lifecycle stage:
Decision:
Consequence level:
Portfolio owner:
| Component | Purpose | Strength | Limitation | Independence | Integrity | Status |
|---|---|---|---|---|---|---|
| Public benchmark | ||||||
| Held-out test | ||||||
| Dynamic task suite | ||||||
| Adversarial evaluation | ||||||
| Open-world evaluation | ||||||
| Mechanistic evidence | ||||||
| Human-uplift study | ||||||
| Operational monitoring | ||||||
| Independent review |
| Dimension | Core question |
|---|---|
| Decision | Is the intended use explicit? |
| Claim | Is the claim bounded? |
| Object | Is the exact model, system, deployment, or institution identified? |
| Construct | Is the intended property defined? |
| Content validity | Does the task sample represent the domain? |
| Construct validity | Does evidence support the intended interpretation? |
| Criterion validity | Is the result linked to an external outcome where needed? |
| Reliability | Is measurement sufficiently consistent? |
| Generalization | Is extrapolation beyond the sample justified? |
| Protocol | Is the complete method versioned? |
| Integrity | Is contamination and gaming controlled? |
| Elicitation | Are capability-relevant conditions documented? |
| System boundary | Are tools, scaffolds, humans, and safeguards included correctly? |
| Long horizon | Are multi-step and reliability effects addressed where relevant? |
| Adversarial testing | Were realistic failure-seeking methods used? |
| Evaluation awareness | Was context-sensitive behavior considered? |
| Evidence portfolio | Are complementary methods combined? |
| Human baseline | Is the comparison population defined? |
| Capability-risk separation | Are capability, propensity, access, safeguards, and consequence distinct? |
| Thresholds | Are thresholds evidence-based and governed? |
| Scoring | Is scoring valid, reviewable, and uncertainty-aware? |
| Aggregation | Are critical failures hidden by averages? |
| Fairness | Are irrelevant barriers and affected-party concerns addressed? |
| Expertise | Are domain and evaluation competencies present? |
| Independence | Is evaluator independence sufficient? |
| Timing | Is lifecycle stage and recency clear? |
| Expiration | Are re-evaluation triggers defined? |
| Reporting | Does the claim remain within evidence? |
| Limits | Are invalid interpretations explicit? |
| Correction | Can the result be corrected, suspended, or withdrawn? |
| Meta-evaluation | Will the evaluation itself be tested? |
The following normally prevent a consequential evaluation from supporting a decision-grade conclusion:
Do not average the scorecard into one master rating.
A critical validity failure cannot be offset by strong documentation elsewhere.
Failure:
Evaluation becomes synonymous with rank.
Effect:
Control:
Use multidimensional profiles, protocol disclosure, and claim limits.
Failure:
An easy-to-measure proxy replaces the intended construct.
Control:
Maintain a validity argument and criterion evidence.
Failure:
A model result is presented as a system or deployment result.
Control:
Use exact object identity and system manifests.
Failure:
Known tasks become the sole evidence for current capability.
Control:
Combine public, held-out, dynamic, and operational methods.
Failure:
Confidentiality is mistaken for scientific quality.
Control:
Review construct, task quality, scoring, governance, and public limitations.
Failure:
Weak prompting or integration produces a false negative.
Control:
Specify an elicitation budget and use qualified best-effort methods.
Failure:
Highly task-specific engineering is presented as ordinary practical capability.
Control:
Report default, standardized, best-effort, and deployment regimes separately.
Failure:
One favorable or unfavorable stochastic outcome is treated as representative.
Control:
Use repeated runs and distributions.
Failure:
Averages conceal catastrophic failures or domain weakness.
Control:
Use decomposable and noncompensatory criteria.
Failure:
A closely related model judges outputs and reproduces shared biases.
Control:
Validate against independent human or environment-based outcomes.
Failure:
High scores compress differences and weaken discrimination.
Control:
Renew tasks, redesign the construct, or retire the instrument.
Failure:
Evaluation content enters training or preparation.
Control:
Use provenance, holdouts, rotation, compromise status, and re-evaluation.
Failure:
The system behaves differently because it recognizes the test.
Control:
Vary contexts, use deployment-like settings, and narrow claims.
Failure:
Any poor result is labeled strategic concealment.
Control:
Test alternative explanations and require evidence.
Failure:
No discovered bypass is presented as proof of safety.
Control:
Report the tested threat model and search effort.
Failure:
Humans and systems receive different tools, time, incentives, or scoring.
Control:
Define comparable conditions and remaining asymmetry.
Failure:
Real-world evidence is treated as automatically superior.
Control:
Address confounding, selection, logging, privacy, and changing systems.
Failure:
An internal feature is treated as definitive proof of future behavior.
Control:
Triangulate with behavior and causal interventions.
Failure:
A precise boundary lacks a valid construct or consequence model.
Control:
Use uncertainty, evidence cases, review, and triggers.
Failure:
The developer, client, evaluator, or regulator controls questions and conclusions.
Control:
Use independent governance, conflict disclosure, and publication rights.
Failure:
Old results remain attached to changed systems.
Control:
Use expiration, status, and event-triggered review.
Failure:
Passing a process test replaces evidence of effective outcomes.
Control:
Evaluate both process and performance.
Failure:
A narrow test is used to market broad safety.
Control:
Apply controlled public-claim vocabulary and independent review.
Failure:
One evaluator or framework becomes the sole source of legitimacy.
Control:
Support plural evaluators, crosswalks, replication, and appeals.
Failure:
Requirements become so costly that only dominant actors can comply.
Control:
Use proportionality, shared infrastructure, and functional access pathways.
This objection is partly correct.
Static evaluation cannot keep pace.
The response is not to abandon evaluation.
It is to use:
Evaluation may still lag.
The lag should be measured and disclosed.
Public instruments can be optimized against.
They still support:
A portfolio with protected and dynamic components reduces dependence on public tasks.
They can be unaccountable.
They need not be.
Accountability can operate through:
Context dependence is real.
Standardization should focus on:
rather than forcing one universal task set.
Thresholds may become stale.
They can still serve as provisional process triggers if they are:
Access is a major constraint.
Responses include:
Some evaluation work can increase risk.
The response is graded publication, safe proxies, secure review, and deliberate disclosure governance.
Evaluation can exercise de facto power.
This is why technical evidence, standards, certification, procurement, and legal authority must remain distinct.
Expert judgment can be biased.
Automated metrics also encode judgment.
Structured expert methods, conflict controls, dissent, and calibration improve accountability.
Deployment evidence is essential.
Uncontrolled deployment cannot ethically or efficiently answer every high-stakes question.
Controlled and proxy methods remain necessary.
Mechanistic evidence is promising but incomplete.
Behavior, mechanism, operations, and institutions answer different questions.
Capture is a serious structural risk.
Countermeasures include:
No governance model eliminates capture risk.
Research:
Research:
Research:
Research:
Research:
Research:
Research:
Research:
Research:
Research:
Research:
Research:
Research how audiences interpret:
Research:
Research whether evaluation changes:
Develop a common minimum structure for evaluation protocols.
Develop a machine-readable system manifest.
Develop a result schema carrying:
Apply the validity template to three existing frontier evaluations.
Define minimum reporting for tools, prompts, retries, fine-tuning, and human effort.
Define security and governance metadata for protected evaluation.
Develop requirements for comparable human reference groups.
Compare model judges, human judges, and environment-based scoring.
Evaluate an agent on bounded, realistic, multi-hour tasks.
Track current, expired, superseded, and compromised results.
Review model and system evaluation claims for scope and validity.
Test whether one evaluation result actually predicted a later operational outcome.
Standards Body adopts the following working positions.
Evaluation is structured evidence for bounded claims and decisions under uncertainty.
A score is not an evaluation by itself.
A benchmark is a component, not the complete protocol.
The protocol is the proper unit of evaluation governance.
The exact evaluated object should be identified.
Model, system, deployment, and human-AI team results are distinct.
Evaluation conditions are part of the result.
Tools, scaffolds, retrieval, memory, and human assistance should be reported.
Validity concerns the intended interpretation and use.
Reliability is necessary for many uses but does not establish validity.
A measure can be reliable and wrong.
A harder benchmark is not automatically a better benchmark.
Public benchmarks remain useful but should not be the sole basis of consequential claims.
Held-out evaluation can protect integrity but does not guarantee validity.
Protected content and transparent governance should coexist.
Dynamic protocols are necessary for changing frontier systems.
Historical comparison should be abandoned when continuity cannot be defended.
Consequential results should expire.
Failure to demonstrate capability is not proof of incapability.
Elicitation quality should be treated as a first-order methodological issue.
Best-effort capability and practical deployment capability should be distinguished.
Base-model capability and system capability should be distinguished.
Long-horizon evaluation should examine trajectories, recovery, and reliability.
A 50 percent task-success horizon is not an operational reliability standard.
Red teaming is failure-seeking evidence, not proof of absence after no finding.
Evaluation awareness can weaken the validity of deployment claims.
Sandbagging should be tested rather than presumed.
Behavioral, mechanistic, operational, and organizational evidence are complementary.
Mechanistic evidence should not automatically override observed behavior.
Operational evidence should not automatically be treated as representative.
Human baselines should define population, tools, time, and incentives.
Human-AI uplift should be measured rather than assumed.
Capability and risk are distinct.
Capability thresholds should trigger processes, not replace risk analysis.
Safeguards should be evaluated against explicit threat models.
Safeguard success does not prove universal safety.
Thresholds should be uncertainty-aware, governed, and revisable.
Evaluation cannot determine acceptable risk by itself.
Technical findings and normative decisions should remain distinguishable.
Consequential evaluation should use an evidence portfolio.
Methods in a portfolio should fail differently.
Aggregate scores should not conceal critical failures.
Model-based judges require validation and version control.
Fair evaluation includes both evaluated-party procedure and affected-party consequence.
Domain expertise and evaluation expertise are distinct and jointly necessary.
First-party evidence is valuable but insufficient for the most consequential claims.
External does not automatically mean independent.
Evaluator competence should be scope-specific.
Evaluation should occur across the lifecycle, not only before release.
Evaluation systems, evaluators, thresholds, and standards should themselves be evaluated.
PROJECT_IDENTITY.mdDefines the project's present role and prevents evaluation outputs from implying unsupported authority.
TERMINOLOGY.mdDefines the controlled meaning of evaluation, test, benchmark, capability, risk, safety, audit, certification, and accreditation.
FOUNDATIONS.mdProvides the overview of the eight-foundation evaluation infrastructure.
FOUNDATIONS_APPENDIX.mdConnects this philosophy to the complete institutional lifecycle.
EVIDENCE_STANDARDS.mdDefines evidence quality, evidence levels, confidence, sourcing, and claim limits.
RESEARCH_METHODOLOGY.mdDefines how evaluation research should be planned, executed, reviewed, and corrected.
TAXONOMY.mdClassifies evaluation objects, methods, evidence, actors, risks, safeguards, and statuses.
Operationalizes dynamic and versioned evaluation protocols.
Operationalizes held-out evaluation integrity and protected evidence.
Operationalizes high-stakes capability evaluation and decision-linked rigor.
Operationalizes independent expert review.
Operationalizes third-party evaluator and assurance ecosystems.
Connects mature evaluation practices to progressive standards and requirements.
Examines incentives created by scores, rankings, thresholds, and recognition.
Makes evaluation evidence interpretable across institutions and jurisdictions.
Evaluation is one of the central institutions through which societies will understand frontier AI.
That gives evaluation unusual power.
It can determine:
That power makes shallow evaluation dangerous.
A leaderboard can shape investment before its construct is validated.
A hidden test can shape deployment before its governance is legitimate.
A threshold can shape law before its uncertainty is understood.
A certificate can shape public trust before its scope is read.
A model can pass a test while failing in deployment.
A model can fail a test because the evaluator did not know how to elicit it.
An institution can perform every required process while missing the real hazard.
The response is not to reject evaluation.
It is to treat evaluation as a disciplined institutional practice.
A credible evaluation should make clear:
Evaluation should narrow uncertainty without pretending to abolish it.
It should support judgment without hiding judgment.
It should create comparability without manufacturing sameness.
It should support accountability without becoming theater.
It should protect evidence without becoming unreviewable.
It should evolve without rewriting history.
The defining philosophy of Standards Body is:
Evaluation is not proof of safety. It is structured, reviewable, and revisable evidence for bounded decisions under uncertainty.
[^standards-testing]: American Educational Research Association, American Psychological Association, and National Council on Measurement in Education, Standards for Educational and Psychological Testing, 2014. https://www.testingstandards.net/
[^messick]: Samuel Messick, Validity, in Educational Measurement, 3rd edition, 1989.
[^benchmark-review]: Anna-Katharina Reuel and collaborators, Can We Trust AI Benchmarks? An Interdisciplinary Review of Current Issues in AI Evaluation, 2025. https://arxiv.org/abs/2502.06559
[^nist-rmf]: National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, 2023. https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
[^nist-measure]: National Institute of Standards and Technology, AI RMF Playbook, Measure Function, NIST AI Resource Center. https://airc.nist.gov/airmf-resources/playbook/measure/
[^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
[^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-qa]: UK AI Security Institute, Early Insights from Developing Question-Answer Evaluations for Frontier AI, September 23, 2024. https://www.aisi.gov.uk/blog/early-insights-from-developing-question-answer-evaluations-for-frontier-ai
[^aisi-agenda]: UK AI Security Institute, Research Agenda, including the Science of Evaluations research area. https://www.aisi.gov.uk/research-agenda
[^openai-pf]: OpenAI, Preparedness Framework, Version 2, April 15, 2025. https://cdn.openai.com/pdf/18a02b5d-6b67-4cec-ab64-68cdfbddebcd/preparedness-framework-v2.pdf
[^openai-pf-update]: OpenAI, Our Updated Preparedness Framework, April 15, 2025. https://openai.com/index/updating-our-preparedness-framework/
[^openai-external]: OpenAI, Strengthening Our Safety Ecosystem with External Testing, November 19, 2025. https://openai.com/index/strengthening-safety-with-external-testing/
[^deepmind-fsf]: Google DeepMind, Strengthening Our Frontier Safety Framework, updated through Framework 3.1 in April 2026. https://deepmind.google/blog/strengthening-our-frontier-safety-framework/
[^anthropic-sabotage]: Anthropic, Sabotage Evaluations for Frontier Models, 2024. https://www.anthropic.com/research/sabotage-evaluations
[^anthropic-shade]: Anthropic, Evaluating Sabotage and Monitoring in LLM Agents, 2025. https://www-cdn.anthropic.com/f4a31075d4763a01db68760733bb7b059e528781.pdf
[^metr-time]: METR, Task-Completion Time Horizons of Frontier AI Models, current methodology and results through 2026. https://metr.org/time-horizons/
[^metr-developer-study]: METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, July 10, 2025. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
[^open-world-evals]: Beth Barnes and collaborators, Open-World Evaluations for Measuring Frontier AI Capabilities, 2026. https://arxiv.org/abs/2605.20520
[^inspect]: UK AI Security Institute, Inspect AI, an open-source framework for large language model evaluations. https://inspect.aisi.org.uk/
[^jcgm-vim]: Joint Committee for Guides in Metrology, International Vocabulary of Metrology, Basic and General Concepts and Associated Terms, JCGM 200. https://www.bipm.org/en/committees/jc/jcgm/publications
[^jcgm-gum]: Joint Committee for Guides in Metrology, Evaluation of Measurement Data, Guide to the Expression of Uncertainty in Measurement, JCGM 100. https://www.bipm.org/documents/20126/2071204/JCGM_100_2008_E.pdf
Date: July 16, 2026
Change type: Complete foundational edition
Summary: Establishes the canonical Standards Body evaluation philosophy. Defines the purpose and limits of evaluation, evaluated-object identity, construct and validity theory, reliability, generalization, benchmarks, held-out and dynamic evaluation, elicitation, tools and scaffolds, long-horizon agents, adversarial evaluation, evaluation awareness and sandbagging, behavioral, mechanistic and operational evidence, human baselines, capability and risk, safeguards, thresholds, decision linkage, uncertainty, scoring, fairness, expertise, evaluator institutions, lifecycle evaluation, public claims, evaluation limits, portfolios, meta-evaluation, maturity, design lifecycle, templates, scorecard, failure modes, objections, research agenda, near-term program, canonical positions, and research basis.
Status: Approved foundational source.