Standards Body · Foundational source, public edition · Released July 17, 2026

Canonical record: https://standardsbody.ai/library/foundational-source/foundations-appendix/

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.

FOUNDATIONS_APPENDIX.md

Foundations Appendix

Project: Standards Body
Primary domain: standardsbody.ai
Core line: Foundations for Frontier AI
Document type: Canonical cross-foundation integration, dependency, and implementation appendix
Version: 1.0
Status: Approved foundational source
Document owner: Standards Body
Applies to: The eight-foundation series, future standards development, institutional design, evaluation programs, research agendas, templates, scorecards, website summaries, contributor work, partnerships, and document-control decisions
Source documents: FOUNDATION_01_DYNAMIC_EVALUATION_PROTOCOLS.md through FOUNDATION_08_GLOBAL_INTEROPERABILITY.md
Related canonical sources: PROJECT_IDENTITY.md, TERMINOLOGY.md, FOUNDATIONS.md
Review cycle: Annual review, with event-triggered revision after any material change to a foundation, project identity, terminology, evidence standard, governance framework, standards-development process, or institutional role

Document Purpose

This appendix integrates the eight Standards Body foundations into one coherent system.

The individual foundation papers are intentionally deep and specialized. Each addresses a distinct institutional problem:

  1. Keeping evaluation valid as AI systems change
  2. Preserving evidentiary value through held-out testing
  3. Matching evaluation rigor to high-consequence capability
  4. Establishing credible independent expert review
  5. Building a competent third-party assurance ecosystem
  6. Progressing from research to stronger standards and requirements
  7. Aligning incentives and prestige with integrity
  8. Making evidence portable across institutions and borders

This appendix explains how those parts depend on one another.

It is the authoritative source for:

This document is not a replacement for the individual foundation papers.

It does not shorten or override their specialized requirements.

It provides the system-level view needed to use them together.

Executive Summary

The eight foundations form one institutional chain.

A frontier AI evaluation system begins with a question:

What consequential claim or decision requires evidence?

Foundation 1 turns that question into a dynamic, versioned evaluation protocol.

Foundation 2 determines which tasks, methods, or evidence must remain held out to preserve measurement integrity.

Foundation 3 determines whether the capability or decision is high stakes and therefore requires stronger rigor, domain expertise, uncertainty analysis, thresholds, and safeguards.

Foundation 4 determines when independent expert review is required and what access, competence, mandate, conflicts, dissent, and publication rights are necessary.

Foundation 5 turns isolated reviews into a scalable ecosystem by defining evaluator competence, quality systems, proficiency testing, accreditation concepts, surveillance, registries, and mutual recognition.

Foundation 6 determines how a validated practice may progress from research into guidance, voluntary frameworks, standards, assurance schemes, procurement requirements, recognized codes, and binding obligations.

Foundation 7 examines the incentives surrounding every stage so that organizations are rewarded for valid evidence, disclosure, correction, maintenance, and public contribution rather than gaming, superficial compliance, or prestige accumulation.

Foundation 8 makes the resulting evidence, protocols, qualifications, incidents, and recognition decisions understandable across institutions, languages, sectors, and jurisdictions.

The foundations therefore form a loop rather than a linear sequence.

Evidence from evaluations, independent reviews, audits, incidents, deployments, and international use should feed back into:

The system rests on several common positions.

1. The evaluated object must be identified precisely

A model name is not enough.

Every consequential result should identify the relevant model, system configuration, tools, prompts, retrieval, safeguards, access conditions, deployment context, protocol, evaluator, and date.

2. Evaluation is decision-linked

Evaluation is not an abstract score-producing activity.

A protocol should state:

3. Capability is not risk

Capability evidence is one input to risk judgment.

Risk also depends on:

4. Passing is not proof of safety

A result can support a bounded claim.

It cannot establish that an AI system is universally safe, secure, harmless, aligned, compliant, or incapable of untested behavior.

5. Protected content and transparent governance can coexist

Exact tasks, solutions, attack libraries, or sensitive methods may remain confidential.

The purpose, construct, governance, evaluator role, uncertainty, limitations, and result status should remain legible.

6. External is not the same as independent

Independent review depends on:

7. Assurance is an ecosystem

Testing, evaluation, inspection, audit, certification, and accreditation are distinct functions.

They should be connected without being collapsed into one vague service.

8. Standards should mature through evidence

A research method should not become a binding requirement merely because the issue is important.

Formality should increase as evidence, consequence, implementation capacity, assurance readiness, and legitimacy increase.

9. Incentives are part of technical design

Metrics, rankings, access, awards, procurement, funding, certification, and penalties change behavior.

Every major protocol or standard should examine the incentives it creates.

10. Interoperability does not require uniformity

Institutions can share terminology, metadata, protocols, result structures, and evaluator evidence while retaining different legal systems, thresholds, and public-policy judgments.

The combined architecture is designed to produce evidence that is:

The foundations are strongest when implemented together.

A dynamic protocol without protected tasks may become easy to game.

A held-out test without transparent governance may become unaccountable.

A high-stakes threshold without independent review may become self-serving.

Independent review without evaluator infrastructure may remain scarce and inconsistent.

A certification scheme without mature standards may create false assurance.

A standard without incentive analysis may reward paperwork rather than outcomes.

A national system without interoperability may create duplication and fragmentation.

Interoperability without local authority and capacity may export one institution's assumptions globally.

The purpose of this appendix is to prevent those failures by treating the eight foundations as one integrated institutional system.

1. Role of the Foundations Appendix

1.1 Integration

This appendix combines the foundations at the level of:

1.2 Dependency Control

It identifies which foundation supplies prerequisites for another.

Example:

A third-party evaluator cannot be meaningfully accredited without:

1.3 Contradiction Control

It establishes cross-foundation rules that should remain consistent.

1.4 Implementation Control

It provides a sequence for moving from theory to pilots, standards, assurance, and recognition.

1.5 Document Navigation

It directs users to the correct foundation, template, or scorecard for a given task.

1.6 Change Impact

It identifies which other files should be reviewed when one foundation changes.

1.7 Authority Boundary

It preserves the distinction between:

2. Foundation Library Inventory

2.1 Foundation 1

File: FOUNDATION_01_DYNAMIC_EVALUATION_PROTOCOLS.md
Subject: Maintaining valid, decision-relevant evaluation as models, systems, tasks, threats, and evidence change
Primary output: A versioned evaluation protocol with defined stable and dynamic layers
Central question: How can evaluation remain meaningful over time?

2.2 Foundation 2

File: FOUNDATION_02_HELD_OUT_EVALUATIONS.md
Subject: Protecting tasks, methods, environments, scoring, and other materials when exposure would reduce validity or create harm
Primary output: A governed held-out evaluation plan and custody system
Central question: What should remain protected, from whom, for how long, and under which controls?

2.3 Foundation 3

File: FOUNDATION_03_HIGH_STAKES_CAPABILITY_EVALUATION.md
Subject: Evaluating capabilities relevant to severe, strategic, systemic, or difficult-to-reverse consequences
Primary output: A multidimensional capability evidence case linked to defined thresholds and decisions
Central question: When should evaluation become more rigorous, and what evidence is required?

2.4 Foundation 4

File: FOUNDATION_04_INDEPENDENT_EXPERT_REVIEW.md
Subject: Establishing review that combines expertise, access, independence, accountability, security, and dissent
Primary output: A documented independent review mandate and findings process
Central question: Who should challenge consequential evidence, with what access and authority?

2.5 Foundation 5

File: FOUNDATION_05_THIRD_PARTY_AUDITOR_ECOSYSTEM.md
Subject: Scaling competent and impartial testing, evaluation, inspection, audit, certification, and accreditation
Primary output: A quality-controlled evaluator and assurance ecosystem
Central question: How can independent assurance become repeatable, credible, and available beyond isolated reviews?

2.6 Foundation 6

File: FOUNDATION_06_PROGRESSIVE_STANDARDS_AND_REQUIREMENTS.md
Subject: Progressing practices from research and voluntary use toward standards, procurement, recognition, and binding requirements
Primary output: A maturity and transition-gate system
Central question: When should an emerging practice become more formal or enforceable?

2.7 Foundation 7

File: FOUNDATION_07_INCENTIVES_AND_PRESTIGE.md
Subject: Aligning financial, professional, access-based, reputational, governance, and enforcement incentives
Primary output: Incentive programs that reward integrity, public goods, correction, and contribution
Central question: What behavior does the evaluation and standards system actually reward?

2.8 Foundation 8

File: FOUNDATION_08_GLOBAL_INTEROPERABILITY.md
Subject: Making evidence, protocols, evaluator competence, incidents, standards, and recognition portable across institutions and borders
Primary output: Shared terminology, metadata, profiles, crosswalks, and recognition records
Central question: How can plural institutions understand and use one another's evidence without forced uniformity?

3. Combined System Proposition

The eight foundations support one combined proposition:

Consequential frontier AI claims should be evaluated through current and protected protocols, interpreted through proportionate high-stakes analysis, challenged through competent independent review, supported by accountable third-party assurance, formalized only as evidence and institutions mature, reinforced by aligned incentives, and made portable through global interoperability.

This proposition contains eight requirements.

3.1 Current

Evidence must remain connected to changing systems, tasks, threats, and decisions.

3.2 Protected

Evaluation integrity must be preserved against contamination, leakage, gaming, and harmful disclosure.

3.3 Proportionate

The rigor of evaluation should rise with consequence and uncertainty.

3.4 Independently Challengeable

Consequential claims should not depend solely on the organization making them.

3.5 Institutionally Scalable

Evaluation should be supported by competent organizations, quality systems, surveillance, and accountability.

3.6 Progressively Formalized

Practices should become standards or requirements only when readiness is demonstrated.

3.7 Incentive-Compatible

The system should make accurate evidence and responsible correction more rewarding than manipulation or superficial conformity.

3.8 Interoperable

Evidence should be understandable and reusable across relevant institutional boundaries.

4. The Integrated Architecture

The architecture contains nine connected layers.

Layer 1: Decision and Claim

Define:

Primary foundations:

Layer 2: Evaluated Object

Identify:

Primary foundations:

Layer 3: Protocol

Define:

Primary foundation:

Layer 4: Integrity and Protection

Define:

Primary foundation:

Layer 5: High-Stakes Interpretation

Define:

Primary foundation:

Layer 6: Independent Challenge

Define:

Primary foundation:

Layer 7: Assurance Ecosystem

Define:

Primary foundation:

Layer 8: Institutional Progression and Incentives

Define:

Primary foundations:

Layer 9: Cross-Border Use and Feedback

Define:

Primary foundation:

Every layer feeds the next.

Every later layer may also reveal defects in earlier layers.

5. End-to-End Institutional Flow

Stage 1: Need Identification

A credible concern, opportunity, claim, incident, policy question, procurement decision, or standards gap is identified.

Required questions:

Primary foundations:

Stage 2: Construct and Scope

Define:

Primary foundations:

Stage 3: Protocol Design

Create a complete evaluation protocol.

Primary requirements:

Primary foundation:

Stage 4: Holdout and Security Design

Determine which components should remain protected.

Primary requirements:

Primary foundation:

Stage 5: High-Stakes Classification

Determine whether the capability or decision warrants enhanced rigor.

Primary considerations:

Primary foundation:

Stage 6: Validation and Pilot

Test:

Primary foundations:

Stage 7: Independent Review

Appoint qualified reviewers under a documented mandate.

Primary requirements:

Primary foundation:

Stage 8: Evaluator Qualification and Assurance

Where repeated third-party work is expected, establish:

Primary foundation:

Stage 9: Operational Use

Apply evidence to:

Primary foundations:

Stage 10: Progression Decision

Determine whether the practice should remain:

Primary foundation:

Stage 11: Incentive Integration

Examine:

Primary foundation:

Stage 12: Interoperability and Recognition

Create:

Primary foundation:

Stage 13: Monitoring and Feedback

Use:

to update the system.

All eight foundations apply.

Stage 14: Revision, Suspension, or Retirement

A protocol, result, evaluator scope, certificate, requirement, incentive program, crosswalk, or recognition may be:

The reason and transition should be documented.

6. Foundation Profiles and Interfaces

6.1 Foundation 1: Dynamic Evaluation Protocols

Core Thesis

The protocol, not the dataset alone, is the appropriate unit of evaluation governance.

Institutional Role

Foundation 1 establishes how evidence remains meaningful as:

Required Inputs

Primary Outputs

Interfaces

Foundation 1 supplies:

Failure if Absent

Without Foundation 1:

6.2 Foundation 2: Held-Out Evaluations

Core Thesis

Some evaluation material should remain unavailable before testing when exposure would materially reduce validity or create harm.

Institutional Role

Foundation 2 establishes the integrity boundary around protected tasks, environments, scoring, methods, and evidence.

Required Inputs

Primary Outputs

Interfaces

Foundation 2 supplies:

Failure if Absent

Without Foundation 2:

6.3 Foundation 3: High-Stakes Capability Evaluation

Core Thesis

Evaluation rigor should increase with the potential consequence of error, but capability should not be confused with risk.

Institutional Role

Foundation 3 links evaluation evidence to high-consequence decisions.

Required Inputs

Primary Outputs

Interfaces

Foundation 3 supplies:

Failure if Absent

Without Foundation 3:

6.4 Foundation 4: Independent Expert Review

Core Thesis

No organization should be the sole authority over the evaluation of its own most consequential systems.

Institutional Role

Foundation 4 creates credible challenge without confusing externality, independence, and competence.

Required Inputs

Primary Outputs

Interfaces

Foundation 4 supplies:

Failure if Absent

Without Foundation 4:

6.5 Foundation 5: Third-Party Auditor Ecosystem

Core Thesis

Third-party assurance is an ecosystem of distinct activities, roles, competence systems, and recognition arrangements.

Institutional Role

Foundation 5 scales independent work beyond one-off expert panels.

Required Inputs

Primary Outputs

Interfaces

Foundation 5 supplies:

Failure if Absent

Without Foundation 5:

6.6 Foundation 6: Progressive Standards and Requirements

Core Thesis

Institutional force should increase only as consequence, evidence, implementation capacity, assurance readiness, and legitimacy justify it.

Institutional Role

Foundation 6 governs the path from emerging practice to stronger institutional expectation.

Required Inputs

Primary Outputs

Interfaces

Foundation 6 uses all earlier foundations.

It supplies:

Failure if Absent

Without Foundation 6:

6.7 Foundation 7: Incentives and Prestige

Core Thesis

Evaluation infrastructure will be no stronger than the incentives surrounding it.

Institutional Role

Foundation 7 examines what the ecosystem rewards, discourages, hides, and neglects.

Required Inputs

Primary Outputs

Interfaces

Foundation 7 affects every foundation.

It determines whether:

Failure if Absent

Without Foundation 7:

6.8 Foundation 8: Global Interoperability

Core Thesis

Frontier AI evidence should be portable across boundaries without requiring identical laws, protocols, thresholds, or policy judgments.

Institutional Role

Foundation 8 creates shared meaning and recognition across plural institutions.

Required Inputs

Primary Outputs

Interfaces

Foundation 8 makes outputs from Foundations 1 through 7 usable across:

Failure if Absent

Without Foundation 8:

7. Cross-Foundation Dependency Matrix

The following matrix identifies the primary dependency relationships.

Foundation Depends most directly on Supplies most directly to
1. Dynamic Evaluation Protocols Decision question, terminology, construct definition, system identity Held-out design, high-stakes evidence, review object, evaluator scope, interoperability metadata
2. Held-Out Evaluations Protocol design, security threat model, task provenance Protected evidence, integrity status, access conditions, compromise records
3. High-Stakes Capability Evaluation Dynamic protocol, held-out evidence, system identity, domain expertise Rigor level, threshold logic, decision implications, reviewer requirements
4. Independent Expert Review Evidence package, review mandate, access, competence, conflicts Independent findings, dissent, validation evidence, public limitations
5. Third-Party Auditor Ecosystem Mature methods, defined criteria, review principles, quality requirements Scalable assurance, competence recognition, surveillance, registries
6. Progressive Standards and Requirements Evidence maturity, independent validation, assurance capacity, public-interest need Standards pathway, procurement conditions, recognized codes, legal proposals
7. Incentives and Prestige Actor behavior, evidence measures, market and professional context Adoption, maintenance, disclosure, correction, public-goods support
8. Global Interoperability Shared terminology, identity, metadata, protocol and evaluator evidence Cross-border comparability, recognition, incident exchange, capacity coordination

7.1 Hard Dependencies

A hard dependency is a condition without which a later function should not proceed.

Examples:

7.2 Soft Dependencies

A soft dependency improves quality but may not be required in every low-consequence case.

Examples:

7.3 Bidirectional Dependencies

Several relationships are reciprocal.

Protocol and Holdout

Protocol design determines what may be protected.

Compromise evidence determines when the protocol must change.

Capability and Safeguards

Capability evidence informs safeguard requirements.

Safeguard evidence changes practical risk and deployment conditions.

Review and Evaluator Ecosystem

Review principles define evaluator expectations.

Evaluator experience reveals where review principles need revision.

Standards and Incentives

Standards create incentives.

Incentive analysis determines whether standards produce meaningful behavior.

Interoperability and Local Practice

Shared structures enable cross-border use.

Local implementation reveals translation, capacity, and equivalence problems.

8. Cross-Foundation Invariants

The following positions should remain stable across all eight foundations unless formally revised.

8.1 Exact Object Identity

Every consequential result should identify the evaluated object precisely.

At minimum:

8.2 Decision Relevance

Every major evaluation, review, audit, certification, or standard should identify the decision or claim it supports.

8.3 Scope Limitation

No result should be interpreted beyond:

8.4 Versioning

Protocols, task banks, models, systems, standards, evaluator scopes, certificates, recognition decisions, and registries should be versioned.

8.5 Expiration

High-consequence evidence should not remain valid indefinitely.

8.6 Correction

Material errors should produce visible correction, withdrawal, or supersession.

8.7 Independence

Consequential claims should receive scrutiny beyond the organization making them.

8.8 Competence

Independence does not compensate for lack of expertise.

8.9 Access

Competence and independence do not support broad conclusions without sufficient access.

8.10 Uncertainty

Uncertainty should be reported rather than hidden by a single score or categorical label.

8.11 Security

Sensitive information should be protected proportionately.

8.12 Transparency

Protected content should not become an excuse for opaque governance.

8.13 Dissent

Reasoned disagreement should be preserved when material.

8.14 Appeals and Complaints

Consequential decisions should have correction and challenge pathways.

8.15 Anti-Capture

Financial, organizational, ideological, professional, political, and geopolitical conflicts should be identified and managed.

8.16 Small-Actor Access

Requirements should include realistic pathways for smaller evaluators, researchers, developers, and open communities.

8.17 Public-Interest Purpose

The system should improve real decisions rather than produce institutional appearance.

8.18 Interoperability

Shared evidence structures are preferable to unnecessary duplication or forced uniformity.

8.19 No Universal Safety Claim

Passing a protocol, review, audit, or certification is not proof of universal safety.

8.20 Evaluate the Evaluator and the Evaluation

The protocol, reviewer, evaluator organization, standard, incentive program, and recognition arrangement should themselves be evaluated.

9. Shared Evaluated-Object Architecture

The foundations rely on a common representation of what is being assessed.

9.1 Model Layer

Record:

9.2 System Layer

Record:

9.3 Access Layer

Record:

9.4 Deployment Layer

Record:

9.5 Evaluation Layer

Record:

9.6 Assurance Layer

Record:

9.7 Change Layer

Record:

9.8 Identity Rule

A result should not be inherited by a materially different system without a documented inheritance analysis.

10. Shared Evidence Architecture

10.1 Evidence Classes

The combined foundations recognize several evidence classes.

Direct Technical Evidence

Examples:

Process Evidence

Examples:

Organizational Evidence

Examples:

Operational Evidence

Examples:

Expert Evidence

Examples:

Comparative Evidence

Examples:

Institutional Evidence

Examples:

10.2 Evidence Quality Dimensions

Every material evidence package should be evaluated for:

10.3 Evidence Portfolio

High-stakes decisions should normally use a portfolio rather than one test.

A portfolio may combine:

10.4 Evidence Case

A consequential claim should be represented as an evidence case containing:

10.5 Evidence Inheritance

Evidence may be reused only when:

10.6 Evidence Conflict

When credible evidence conflicts:

10.7 Negative Evidence

Failure to demonstrate a capability is weaker than evidence that the capability is absent.

The distinction should remain visible.

10.8 Confidential Evidence

Confidential evidence may support a public conclusion only when:

11. Shared Governance Architecture

11.1 Core Governance Functions

The foundations collectively require governance for:

11.2 Core Roles

Sponsor or Requesting Authority

Defines the decision need and funds or authorizes work.

Protocol Owner

Maintains the evaluation protocol.

Task or Evidence Custodian

Protects held-out material and chain of custody.

Evaluation Administrator

Executes the protocol.

Scorer or Judge

Applies scoring criteria.

Domain Expert

Provides subject-matter competence.

Independent Reviewer

Challenges evidence and conclusions.

Evaluator Organization

Operates quality-controlled evaluation activities.

Scheme Owner

Maintains certification or assurance scheme rules.

Accreditation Body

Recognizes conformity-assessment competence within scope.

Standards Development Body

Maintains the process for standards creation and revision.

Security Officer

Oversees information protection and incident response.

Appeals or Complaints Body

Reviews procedural or substantive challenges.

Registry Operator

Maintains current status records.

Public-Interest Participant

Contributes affected-party and public-consequence knowledge.

Legal or Regulatory Authority

Makes binding legal decisions where authorized.

11.3 Separation of Roles

Incompatible roles should not be combined without safeguards.

Examples:

11.4 Decision Records

Material decisions should record:

11.5 Public and Protected Records

Governance should distinguish:

11.6 Emergency Decisions

Emergency processes should be:

11.7 Governance Review

The governance system should be reviewed for:

12. Shared Independence and Competence Architecture

12.1 Independence Dimensions

The foundations recognize:

12.2 Competence Dimensions

Competence should be scoped by:

12.3 Access Dimensions

Access may include:

12.4 Independence Profile

Every consequential review should state:

12.5 Competence Evidence

Competence may be shown through:

12.6 No Prestige Substitution

Institutional name, celebrity, government affiliation, or model access should not substitute for demonstrated scope-specific competence.

12.7 No Access Substitution

Access does not compensate for weak methods or conflicts.

12.8 Review of Reviewers

Reviewers and evaluators should be subject to:

13. Shared Security and Transparency Architecture

13.1 Core Principle

Transparent governance and protected content should coexist.

13.2 Information Classes

The combined system should support at least:

13.3 Public Minimum

Even when technical content is protected, the public record should normally identify:

13.4 Protected Components

Protection may apply to:

13.5 Protection Requirements

Protected information should have:

13.6 Security Is Not Validity

A secure evaluation can still be invalid.

13.7 Transparency Is Not Validity

A fully open evaluation can still be invalid.

13.8 Compromise Response

A material compromise should trigger consideration of:

13.9 Responsible Disclosure

Disclosure processes should support:

14. Shared Status and Version Architecture

14.1 Objects Requiring Status

Status should be maintained for:

14.2 Common Status Vocabulary

Use:

14.3 Change Triggers

Common triggers include:

14.4 Materiality

A change is material when it could alter:

14.5 Version Inheritance

A new version should not automatically inherit status from a prior version.

14.6 Public Change Record

Material changes should identify:

15. Shared Decision Architecture

15.1 Decision Types

The foundations support decisions concerning:

15.2 Decision Inputs

A consequential decision should consider:

15.3 Decision Outputs

The output may be:

15.4 Thresholds as Process Triggers

A threshold should normally trigger a defined process.

It should not operate as an unexplained label.

15.5 False-Positive and False-Negative Costs

Both should be considered.

A false positive may:

A false negative may:

15.6 Reversibility

Where evidence is uncertain, prefer decisions that preserve correction and re-evaluation.

15.7 Binding Authority

Technical evidence may inform binding decisions.

Binding authority must come from the institution legally or contractually authorized to decide.

16. Shared Maturity Model

The eight foundation-specific maturity models can be integrated into six system levels.

Level 0: Fragmented and Informal

Characteristics:

Primary risk:

False confidence from visible activity without institutional integrity.

Level 1: Defined and Documented

Characteristics:

Primary achievement:

The work becomes legible and reviewable.

Level 2: Validated and Independently Challenged

Characteristics:

Primary achievement:

The evidence becomes more credible.

Level 3: Quality-Controlled and Scalable

Characteristics:

Primary achievement:

The work becomes institutionally repeatable.

Level 4: Formally Assured and Interoperable

Characteristics:

Primary achievement:

Evidence and assurance can travel across organizations.

Level 5: Adaptive and Accountable Institutional Regime

Characteristics:

Primary achievement:

The entire regime learns and corrects itself.

Maturity Rule

No organization should claim a higher system maturity level because it possesses one advanced component.

Maturity depends on the weakest material layer relevant to the claim.

17. Consolidated Failure Register

The foundation library identifies recurring failure modes across technical, institutional, market, and international layers.

17.1 Measurement Failure

Static Benchmark Dependence

A fixed public benchmark becomes the primary evidence for changing frontier systems.

Controls:

Construct Failure

The evaluation measures a proxy rather than the claimed capability, safeguard, or risk.

Controls:

Artificial Difficulty

Tasks become harder without becoming more valid or decision-relevant.

Controls:

Score Collapse

A single aggregate score hides reliability, autonomy, cost, task family, or safeguard tradeoffs.

Controls:

Historical Comparability Failure

Protocol versions are ranked together without demonstrated equivalence.

Controls:

17.2 Integrity Failure

Training Contamination

Evaluation material or close derivatives enter training or development data.

Controls:

Leakage

Protected content is disclosed intentionally or accidentally.

Controls:

Evaluator Preparation Leakage

The evaluated party receives enough information to optimize narrowly against the active task set.

Controls:

Hidden Compromise

A compromised task bank continues to support public claims.

Controls:

17.3 Elicitation Failure

Under-Elicitation

The system appears incapable because prompts, tools, time, retries, or integration are weak.

Controls:

Overfitted Elicitation

Extensive task-specific optimization produces performance unavailable in practical use.

Controls:

Scaffold Confusion

Performance is attributed to the model when it depends materially on tools or orchestration.

Controls:

17.4 High-Stakes Interpretation Failure

Capability-Risk Collapse

Capability is treated as sufficient proof of risk.

Controls:

Knowledge-Action Confusion

Correct answers are treated as proof of reliable operational performance.

Controls:

Threshold Theater

A threshold appears precise but lacks a valid construct or consequence model.

Controls:

High-Stakes Inflation

Too many capabilities receive the highest evaluation burden.

Controls:

High-Stakes Minimization

Severe capability is treated as ordinary because evidence is uncertain.

Controls:

17.5 Review Failure

Externality Without Independence

An outside organization is treated as independent despite client dependence or restricted judgment.

Controls:

Prestige Without Competence

High-status reviewers are appointed outside their actual domain.

Controls:

Competence Without Access

Reviewers cannot inspect the evidence needed for the public claim.

Controls:

Developer Veto

The reviewed party controls methods, reviewers, findings, timing, or publication.

Controls:

Consensus Theater

Material dissent is removed to create a unified public message.

Controls:

17.6 Evaluator-Ecosystem Failure

Scope Inflation

An evaluator claims broad competence from limited experience.

Controls:

Evaluator Shopping

A client seeks the most favorable evaluator or conclusion.

Controls:

Client Capture

Repeat business weakens evaluator independence.

Controls:

Certificate Inflation

Certificates proliferate without clear requirements or assurance.

Controls:

Accreditation Monopoly

One body controls evaluator legitimacy without accountability.

Controls:

Auditor Bottleneck

Formal requirements activate before competent evaluators exist.

Controls:

17.7 Standards Failure

Premature Formalization

Immature methods become binding.

Controls:

Permanent Voluntarism

Severe externalities persist because no minimum requirement emerges.

Controls:

Prescriptive Lock-In

One method becomes mandatory and blocks superior alternatives.

Controls:

Standards Capture

Dominant organizations shape requirements around their own systems.

Controls:

Regulatory Ratchet

Requirements strengthen but cannot be reduced after evidence changes.

Controls:

Compliance Theater

Documents and checklists replace outcome evidence.

Controls:

17.8 Incentive Failure

Goodhart Effects

Participants optimize the metric rather than the intended objective.

Controls:

Prestige Capture

Existing status determines awards, access, funding, and authority.

Controls:

Corrective Credit Abuse

Organizations create or repeat preventable failures while seeking praise for correction.

Controls:

Bounty Distortion

Programs reward finding quantity, duplication, or unsafe disclosure.

Controls:

Crowding Out

External rewards weaken intrinsic motivation, cooperation, or public service.

Controls:

17.9 Interoperability Failure

False Equivalence

Different protocols or certificates are accepted as interchangeable without evidence.

Controls:

Uniformity Disguised as Interoperability

One institution's framework becomes the global default.

Controls:

Lowest Common Denominator

International alignment weakens high-stakes requirements.

Controls:

Registry Monopoly

One registry controls global legitimacy.

Controls:

Capacity Exclusion

Institutions are expected to implement systems they lack the resources to use.

Controls:

Translation Error

Literal translation changes construct meaning.

Controls:

17.10 Meta-Institutional Failure

Authority Inflation

A research project appears to exercise certification, regulatory, or official standards authority.

Controls:

Institutional Theater

The appearance of maturity outruns competence, governance, and evidence.

Controls:

Founder or Leadership Capture

One person becomes the unchallengeable source of institutional identity and decisions.

Controls:

Mission Drift

The project expands into unrelated commentary, promotion, or consulting.

Controls:

18. Cross-Foundation Tensions

The foundations contain deliberate tensions that should be managed rather than erased.

18.1 Transparency Versus Security

Foundation 2 protects active evaluation material.

Foundations 4, 6, and 8 require accountability and public legibility.

Resolution:

18.2 Stability Versus Adaptation

Foundation 1 requires change.

Measurement and interoperability require comparability.

Resolution:

18.3 Developer Cooperation Versus Independent Judgment

Developers possess essential system knowledge.

Reviewers must remain free to disagree.

Resolution:

18.4 Speed Versus Legitimacy

Frontier systems change quickly.

Standards and public institutions require review and participation.

Resolution:

18.5 Precaution Versus False Positives

Severe risks can justify early action.

Weak evidence can restrict beneficial work.

Resolution:

18.6 Standardization Versus Innovation

Standards improve consistency.

Prescriptive rules can freeze immature methods.

Resolution:

18.7 Market Scale Versus Independence

Commercial evaluator markets can increase capacity.

Client funding can weaken judgment.

Resolution:

18.8 International Alignment Versus Sovereignty

Shared evidence improves coordination.

Legal and cultural decisions remain local.

Resolution:

18.9 Open Participation Versus Security

Open communities improve scrutiny and access.

Some evidence is sensitive.

Resolution:

18.10 Prestige Versus Accountability

Recognition can motivate contribution.

Prestige can shield error.

Resolution:

19. Consolidated Evidence Gaps

The following evidence gaps recur across the foundation series.

19.1 Protocol Validity Over Time

How quickly do evaluation protocols lose predictive or decision value?

19.2 Comparability Across Versions

Which bridge-study methods work for dynamic, agentic, and held-out evaluations?

19.3 Contamination Detection

How reliably can direct, indirect, synthetic, and derivative exposure be detected?

19.4 Elicitation Sufficiency

How should evaluators estimate plausible maximum capability without unlimited resources?

19.5 Agent Evaluation

How should long-horizon reliability, environmental change, and trajectory quality be measured?

19.6 High-Stakes Predictive Validity

Which evaluation results predict real-world capability, misuse, incidents, or safeguard failure?

19.7 Threshold Governance

How should uncertain capability evidence connect to alert, critical, or policy thresholds?

19.8 Independent Reviewer Access

Which access arrangements support credible review while protecting security and intellectual property?

19.9 Reviewer Independence

How do funding, repeat clients, model access, and publication rights affect conclusions?

19.10 Evaluator Proficiency

Which proficiency-testing systems predict actual evaluation quality?

19.11 Accreditation Adaptation

How should existing accreditation concepts adapt to fast-changing AI methods?

19.12 Certification Validity

Which claims are mature enough for certification, and how do users interpret certificates?

19.13 Standards Impact

Do AI standards improve system behavior, or mainly organizational documentation?

19.14 Procurement Effects

Do evaluation and assurance requirements improve safety without entrenching incumbents?

19.15 Incentive Effects

Which rewards increase disclosure, maintenance, replication, and correction?

19.16 Crowding Out

When do external rewards reduce intrinsic safety and public-interest motivation?

19.17 Incident Reporting

Which classification and protection systems improve cross-organizational learning?

19.18 International Recognition

Which forms of evaluator and result recognition preserve rigor across jurisdictions?

19.19 Translation Validity

How can capability and risk constructs remain valid across languages and cultures?

19.20 Capacity Building

Which models create durable local evaluation institutions rather than dependency?

19.21 Registry Governance

How can status records remain current, distributed, secure, and legitimate?

19.22 Open-Weight Systems

How should evidence, responsibility, and assurance travel across model forks and decentralized deployments?

19.23 Institutional Outcomes

How should the effectiveness of the full evaluation and standards regime be measured?

20. Consolidated Research Agenda

Standards Body should organize cross-foundation research into the following programs.

Program 1: Dynamic Measurement

Develop:

Program 2: Evaluation Integrity

Develop:

Program 3: Capability Elicitation

Develop:

Program 4: High-Stakes Evidence

Develop:

Program 5: Independent Review

Develop:

Program 6: Evaluator Quality

Develop:

Program 7: Assurance and Accreditation

Develop:

Program 8: Progressive Standards

Develop:

Program 9: Incentive Alignment

Develop:

Program 10: Incident Learning

Develop:

Program 11: Global Interoperability

Develop:

Program 12: Multilingual and Regional Evaluation

Develop:

Program 13: Open Ecosystems

Develop:

Program 14: Institutional Evaluation

Develop methods for evaluating:

Program 15: Public Claims and Comprehension

Study how developers, purchasers, governments, journalists, and the public interpret:

21. Consolidated Role Map

Role Primary responsibilities Primary foundation
Decision owner Defines the consequential decision and evidence need 3 and 6
Protocol owner Maintains construct, method, version, and retirement 1
Task author Creates valid task material 1 and 2
Task custodian Protects held-out content and custody 2
Evaluation administrator Executes the protocol under controlled conditions 1 and 2
Elicitation specialist Configures prompts, tools, scaffolds, and resources 1 and 3
Scorer or judge Applies scoring and records uncertainty 1
Domain expert Assesses content and real-world validity 3 and 4
Security specialist Protects models, tasks, evidence, and exchange 2, 4, 5, and 8
Independent reviewer Challenges evidence and conclusions 4
Review chair Preserves mandate, process, dissent, and records 4
Evaluator organization Operates quality-controlled evaluation services 5
Auditor Conducts criteria-based audits within scope 5
Certification body Issues certification under a defined scheme 5
Accreditation body Recognizes conformity-assessment competence 5
Scheme owner Maintains assurance or certification rules 5 and 6
Standards committee Develops and maintains standards 6
Purchaser Uses evidence and requirements in procurement 6 and 7
Insurer Uses evidence in underwriting and loss prevention 7
Incentive-program owner Designs grants, prizes, recognition, or bounties 7
Registry operator Maintains current public or controlled records 5 and 8
Recognition authority Accepts evidence, competence, or process for a purpose 8
Legal authority Makes binding legal decisions within jurisdiction 6 and 8
Public-interest participant Contributes affected-party and social-context knowledge 4, 6, 7, and 8
Contributor Provides documented research, review, infrastructure, or implementation work All

22. Consolidated Metrics

The combined system should be evaluated across seven dimensions.

22.1 Measurement Quality

22.2 Integrity

22.3 Independence and Competence

22.4 Operational Performance

22.5 Institutional Quality

22.6 Decision Utility

22.7 Adaptation and Interoperability

23. Consolidated Template Index

The eight foundations contain an integrated operational library.

Foundation 1 Templates

Protocol Template

Use to define a complete evaluation protocol.

Change Request Template

Use to propose and review a protocol change.

Protocol Scorecard

Use to evaluate protocol quality, integrity, governance, and decision value.

Foundation 2 Templates

Held-Out Evaluation Plan Template

Use to define protected content, access, custody, administration, rotation, and disclosure.

Access Request Template

Use to authorize and record access to protected material.

Compromise Incident Template

Use after suspected or confirmed leakage, contamination, or security failure.

Holdout Scorecard

Use to evaluate validity, protection, fairness, governance, and lifecycle.

Foundation 3 Templates

High-Stakes Evaluation Plan Template

Use to define domain, capability, consequence, protocol, experts, safeguards, and decisions.

Capability Evidence Case Template

Use to assemble multidimensional evidence for a high-stakes capability claim.

Threshold Change Request Template

Use to propose a new or revised alert or critical threshold.

High-Stakes Evaluation Scorecard

Use to evaluate consequence linkage, capability evidence, uncertainty, safeguards, and governance.

Foundation 4 Templates

Independent Review Mandate Template

Use to define review question, authority, access, methods, outputs, and publication.

Independence Profile Template

Use to disclose organizational, financial, methodological, and publication independence.

Reviewer Conflict Disclosure Template

Use to identify and manage reviewer conflicts.

Review Finding Template

Use to present evidence, findings, confidence, limitations, and required action.

Minority Report Template

Use to preserve material dissent.

Independent Review Scorecard

Use to evaluate competence, independence, access, security, accountability, and utility.

Foundation 5 Templates

Evaluator Organizational Profile Template

Use to document evaluator governance, personnel, methods, quality, security, and client structure.

Accreditation Scope Template

Use to define the exact activities and limits proposed for competence recognition.

Evaluator Engagement Template

Use to govern client, scope, payment, evidence, access, reporting, and conflicts.

Surveillance Report Template

Use for ongoing review of evaluator status and performance.

Evaluator Complaint Template

Use to submit and resolve complaints.

Ecosystem Scorecard

Use to evaluate evaluator-market competence, impartiality, capacity, recognition, and concentration.

Foundation 6 Templates

Requirement Maturity Assessment Template

Use to determine whether a practice is ready for a more formal stage.

Transition-Gate Decision Template

Use to approve, defer, condition, or reject institutional progression.

Progressive Requirement Specification Template

Use to define scope, trigger, evidence, assurance, implementation, enforcement, and sunset.

Procurement Clause Template

Use to incorporate evaluation and assurance into purchasing.

Requirement Impact Review Template

Use to assess effectiveness, burden, competition, and unintended effects.

Progressive Standards Scorecard

Use to evaluate readiness and legitimacy of a standard or requirement.

Foundation 7 Templates

Incentive Program Design Template

Use to define actor, behavior, mechanism, reward, gaming, distribution, and evaluation.

Contribution Recognition Template

Use to recognize evidence, infrastructure, safety, institutional, or public-interest contribution.

Responsible Disclosure Reward Template

Use to handle bounty or disclosure recognition.

Corrective Credit Template

Use to evaluate whether an organization should receive credit for disclosure and remediation.

Recognition and Prestige Scorecard

Use to test whether status and rewards track genuine contribution.

Foundation 8 Templates

Interoperability Profile Template

Use to describe supported terminology, protocols, metadata, security, localization, and recognition.

Protocol Crosswalk Template

Use to compare two protocols and determine compatibility.

Recognition Decision Template

Use to accept, conditionally accept, or decline external evidence or competence.

International Incident Exchange Template

Use to share incident evidence across institutions under controlled conditions.

Translation and Localization Validation Template

Use to validate language and regional adaptations.

Registry Record Template

Use to publish current status, scope, evidence, and recognition.

Global Interoperability Scorecard

Use to assess semantic, protocol, measurement, assurance, legal, security, and capacity interoperability.

24. Scorecard Coordination

The eight scorecards should be used in sequence.

24.1 Protocol Scorecard

Question:

Is the evaluation method valid, current, versioned, and decision-relevant?

24.2 Holdout Scorecard

Question:

Is protected evidence governed, secure, proportionate, fair, and maintainable?

24.3 High-Stakes Evaluation Scorecard

Question:

Does the evidence support the high-consequence capability interpretation and decision?

24.4 Independent Review Scorecard

Question:

Was the evidence challenged by competent reviewers with sufficient independence and access?

24.5 Ecosystem Scorecard

Question:

Can third-party assurance be delivered consistently and accountably at scale?

24.6 Progressive Standards Scorecard

Question:

Is the practice mature and legitimate enough for a stronger institutional stage?

24.7 Recognition and Prestige Scorecard

Question:

Do the incentives reward the underlying objective rather than superficial measures?

24.8 Global Interoperability Scorecard

Question:

Can the evidence and assurance be understood and used across boundaries?

24.9 No Averaged Master Score

Standards Body should not combine all eight scorecards into one universal numerical rating.

A failed critical dimension should remain visible rather than being offset by unrelated strengths.

25. Unified Implementation Pathway

The foundations should be implemented as a staged program rather than eight disconnected projects.

Phase 1: Canonical Control Layer

Complete and approve:

Purpose:

Exit criteria:

Phase 2: Institutional Design Layer

Complete and approve:

Purpose:

Exit criteria:

Phase 3: Living Knowledge Infrastructure

Complete and maintain:

Purpose:

Exit criteria:

Phase 4: Pilot Protocol

Select one bounded domain.

Recommended characteristics:

The foundations repeatedly identify autonomous cyber capability as a strong candidate.

Build:

Exit criteria:

Phase 5: Multi-Evaluator Replication

Add independent evaluator organizations.

Test:

Exit criteria:

Phase 6: Voluntary Framework

Convert pilot learning into a voluntary framework.

Include:

Exit criteria:

Phase 7: Standards Development

Use STANDARDS_DEVELOPMENT_PROCESS.md.

Develop:

Exit criteria:

Phase 8: Assurance Scheme Pilot

Where justified, define:

Exit criteria:

Phase 9: Procurement and Market Use

Pilot:

Measure:

Phase 10: International Interoperability

Develop:

Exit criteria:

Phase 11: Formality Review

Determine whether the practice should:

This decision belongs to the authorized institution, not automatically to Standards Body.

26. Integrated Standards Body Pilot

26.1 Pilot Name

Frontier Evaluation Integrity and Assurance Pilot

26.2 Purpose

Demonstrate the complete eight-foundation architecture in one bounded evaluation domain.

26.3 Candidate Domain

Autonomous cyber capability within controlled environments.

26.4 Pilot Claim

The pilot should not ask:

Is this AI system safe?

It should ask a bounded question such as:

Under the identified system configuration and protocol, what level of autonomous cyber task capability was demonstrated, how reliable was that performance, which safeguards affected practical access, and how much confidence should a defined decision-maker place in the evidence?

26.5 Foundation 1 Workstream

Create:

26.6 Foundation 2 Workstream

Create:

26.7 Foundation 3 Workstream

Create:

26.8 Foundation 4 Workstream

Create:

26.9 Foundation 5 Workstream

Create:

26.10 Foundation 6 Workstream

Create:

26.11 Foundation 7 Workstream

Create:

26.12 Foundation 8 Workstream

Create:

26.13 Required Participants

The pilot should include:

26.14 Public Outputs

Publish:

26.15 Protected Outputs

Protect as necessary:

26.16 Success Criteria

The pilot succeeds if:

26.17 Failure Is Informative

The pilot may still succeed institutionally if it reveals that:

A credible decision not to formalize is a valid output.

27. Source-of-Truth and Document Hierarchy

The foundation library should operate within the following hierarchy.

27.1 Identity and Mission

  1. PROJECT_IDENTITY.md
  2. PROJECT_MANIFESTO.md
  3. BRAND_POSITIONING.md

27.2 Foundational System

  1. FOUNDATIONS.md
  2. FOUNDATIONS_APPENDIX.md
  3. The eight foundation papers

27.3 Terminology and Evidence

  1. TERMINOLOGY.md
  2. EVIDENCE_STANDARDS.md
  3. RESEARCH_METHODOLOGY.md
  4. TAXONOMY.md
  5. EVALUATION_PHILOSOPHY.md

27.4 Institutional Process

  1. INSTITUTION_DESIGN.md
  2. GOVERNANCE_FRAMEWORK.md
  3. STANDARDS_DEVELOPMENT_PROCESS.md
  4. EVALUATOR_ACCREDITATION_FRAMEWORK.md
  5. TRANSPARENCY_FRAMEWORK.md
  6. CONTRIBUTOR_FRAMEWORK.md
  7. PARTNERSHIP_PRINCIPLES.md

27.5 Public and Living Records

  1. WEBSITE_SOURCE_OF_TRUTH.md
  2. SOURCES.md
  3. VERSION_HISTORY.md
  4. Other living knowledge-base files

27.6 Conflict Rule

When two files conflict:

28. Cross-Foundation Change Control

28.1 Material Foundation Change

A material change includes:

28.2 Impact Review

A material change to one foundation should trigger review of all connected foundations.

Foundation 1 Change

Review:

Foundation 2 Change

Review:

Foundation 3 Change

Review:

Foundation 4 Change

Review:

Foundation 5 Change

Review:

Foundation 6 Change

Review:

Foundation 7 Change

Review all foundations because incentives affect every component.

Foundation 8 Change

Review:

28.3 Required Change Record

Record:

28.4 Emergency Change

Emergency corrections may be issued for:

Full review should follow.

29. How to Use the Foundation Library

29.1 Designing an Evaluation

Begin with:

  1. Foundation 1
  2. Foundation 2
  3. Foundation 3

Then use Foundation 4 if the claim is consequential.

29.2 Commissioning Independent Review

Begin with:

  1. Foundation 4
  2. Foundation 3
  3. Foundation 1
  4. Foundation 2

Use Foundation 5 for repeated or formal third-party work.

29.3 Building an Evaluator Organization

Begin with:

  1. Foundation 5
  2. Foundation 4
  3. Foundation 1
  4. Foundation 2
  5. Foundation 3

29.4 Developing a Standard

Begin with:

  1. Foundation 6
  2. Foundation 1
  3. Foundation 3
  4. Foundation 4
  5. Foundation 5

Use Foundation 7 for adoption and gaming.

Use Foundation 8 for international use.

29.5 Designing a Certification Scheme

Begin with:

  1. Foundation 5
  2. Foundation 6
  3. Foundation 4
  4. Foundation 1
  5. Foundation 3

Do not proceed without defined requirements and claim boundaries.

29.6 Creating a Reporting Framework

Use:

29.7 Designing an International Partnership

Use:

29.8 Responding to an Incident

Use:

30. Integrated Decision Rules

30.1 Protocol Rule

Do not rely on a benchmark alone when:

30.2 Holdout Rule

Protect evaluation content only when:

30.3 High-Stakes Rule

Increase evaluation rigor when:

30.4 Independent Review Rule

Require independent review when evidence influences:

30.5 Evaluator-Ecosystem Rule

Do not create a formal assurance scheme until:

30.6 Progression Rule

Do not move a practice to a stronger institutional stage merely because:

30.7 Incentive Rule

Do not attach a high-value reward to a metric without:

30.8 Interoperability Rule

Do not declare two protocols, evaluators, certificates, or legal requirements equivalent without:

30.9 Public-Claim Rule

A public claim should state:

30.10 Retirement Rule

Retire or suspend a protocol, result, evaluator scope, certificate, standard, incentive program, or recognition when its authority exceeds its current evidence.

31. Canonical Cross-Foundation Positions

Standards Body adopts the following consolidated positions.

  1. Frontier AI evaluation should be governed at the protocol level, not the dataset level alone.

  2. Evaluation protocols should be dynamic, versioned, traceable, and retireable.

  3. Some evaluation material should remain held out when exposure would reduce validity or increase harm.

  4. Protected content does not justify opaque governance.

  5. Capability and risk are distinct.

  6. High-stakes evaluation should be multidimensional.

  7. Knowledge tests are not sufficient proof of operational capability.

  8. The deployed system should be evaluated, not only the base model.

  9. Elicitation conditions are part of the result.

  10. Failure to demonstrate a capability is not proof of inability.

  11. Passing an evaluation is not proof of safety.

  12. Results should identify the exact system, protocol, evaluator, date, and limitations.

  13. Results should expire after material change or defined time.

  14. Developer evaluation is necessary but insufficient for the most consequential claims.

  15. External review is not automatically independent.

  16. Independence, competence, and access are jointly necessary.

  17. Reviewed parties may correct facts but should not control conclusions.

  18. Material dissent should remain visible.

  19. Testing, evaluation, inspection, audit, certification, and accreditation are distinct.

  20. Accreditation recognizes competence within scope, not universal reliability.

  21. Certification applies to defined requirements, systems, scopes, and periods.

  22. Broad safe-AI certification claims should be avoided.

  23. Evaluator competence should be scope-specific.

  24. Evaluators should face proficiency testing, surveillance, complaints, and correction.

  25. Result-dependent evaluator compensation should be prohibited.

  26. Standards should mature through evidence-based stages.

  27. Not every voluntary practice should become mandatory.

  28. Severe externalities and persistent nonadoption may justify stronger requirements.

  29. Standards should normally be common floors rather than ceilings.

  30. Requirements should include review, appeal, correction, and retirement.

  31. Formality should not outrun evaluator and implementation capacity.

  32. Small-actor and open-community participation is part of legitimacy.

  33. Incentive design is part of technical and institutional design.

  34. Public goods such as maintenance, replication, and incident databases require deliberate support.

  35. Recognition should follow evidence and contribution rather than existing prestige.

  36. Responsible disclosure and correction should receive protection and credit.

  37. Corrective credit should not excuse negligence or concealment.

  38. Rankings should not be used when construct validity and comparability are weak.

  39. Interoperability should preserve legitimate difference.

  40. Shared evidence structure should generally precede shared policy outcomes.

  41. Numeric scores should not travel without measurement context.

  42. Noncomparability is a legitimate conclusion.

  43. Recognition of evidence, competence, process, and legal effect should remain distinct.

  44. International cooperation should preserve local and national decision authority.

  45. Capacity building is part of interoperability.

  46. English-language evaluation should not define global capability by default.

  47. Open-weight model lineage and configuration should be recorded precisely.

  48. Registries should be current, portable, signed where appropriate, and independently governable.

  49. Every component of the regime should be subject to correction and retirement.

  50. The complete evaluation and standards system should itself be continuously evaluated.

32. Completeness Criteria for the Foundation Series

The foundation series is complete enough for early institutional use when:

The series is not complete enough for formal certification, accreditation, regulatory recognition, or binding standards merely because the documents exist.

Those roles require:

33. Final Perspective

The eight foundations are not eight separate ideas.

They are eight controls on the same institutional problem.

Frontier AI systems can change faster than the evidence used to judge them.

Evaluation content can lose value through exposure.

Capability can be misinterpreted as risk.

Developers can become the sole judges of their own claims.

Independent reviewers can lack access or competence.

Auditor markets can create certificates before standards are mature.

Voluntary frameworks can remain weak, while premature regulation can freeze poor methods.

Metrics and prestige can reward the appearance of safety instead of valid evidence.

National systems can produce incompatible conclusions about the same technology.

The foundation architecture answers these problems through a connected design.

Dynamic protocols keep evidence current.

Held-out evaluations protect integrity.

High-stakes evaluation matches rigor to consequence.

Independent review creates challenge.

Third-party assurance creates scale.

Progressive standards connect learning to institutional force.

Incentive design aligns behavior with integrity.

Global interoperability makes evidence portable without erasing plural authority.

None of these elements is sufficient alone.

Together they create a path from a technical question to a credible institutional decision.

The governing idea of the foundation library is:

Evidence should be current, protected, proportionate, independently challengeable, institutionally scalable, progressively formalized, incentive-compatible, and internationally interpretable.

That is the combined foundation for Standards Body.

Revision Record

Version 1.0

Date: July 16, 2026

Change type: Complete foundational edition

Summary: Establishes the canonical integration of the eight Standards Body foundations. Defines the combined architecture, foundation inventory, dependency matrix, cross-foundation invariants, evaluated-object and evidence architecture, governance, independence, security, transparency, status, decision systems, shared maturity model, consolidated failure register, tensions, evidence gaps, research agenda, role map, metrics, complete template and scorecard indexes, unified implementation pathway, integrated pilot, document hierarchy, change control, usage guidance, decision rules, canonical positions, and completeness criteria.

Status: Approved foundational source.