Standards Body · Foundation paper, public edition · Released July 17, 2026
Canonical record: https://standardsbody.ai/library/foundation-paper/progressive-standards-and-requirements/
Standards Body is an independent research and institutional-design project. It is not currently a regulator, accreditation body, certification body, or governmental authority. This document is research; it is not an adopted standard.
Series: Foundations for Frontier AI Evaluation Infrastructure
Version: 1.0
Status: Canonical working white paper
Project: Standards Body
Primary domain: standardsbody.ai
Core line: Foundations for Frontier AI
Research basis reviewed through: July 16, 2026
Document owner: Standards Body
Review cycle: Annual review, with event-triggered revision after material changes in frontier capabilities, evaluation maturity, standards, market practice, or law
This paper defines the Standards Body position on how frontier AI evaluation practices may responsibly develop from research and voluntary commitments into progressively more formal standards, assurance expectations, contractual duties, procurement requirements, and legal obligations.
It is intended to serve as:
This paper is not legislation.
It does not propose that every voluntary practice should become mandatory.
It does not establish a universal regulatory threshold or enforcement authority.
It defines the conditions under which progressively stronger requirements may become justified, workable, and legitimate.
Frontier AI institutions face two opposite risks.
The first is acting too late.
A consequential capability may emerge before evaluation methods, independent reviewers, standards, safeguards, procurement rules, or public institutions are ready. In that case, society may rely on improvised decisions after deployment or after harm becomes visible.
The second is formalizing too early.
Immature methods can become rigid requirements. Poor benchmarks can become legal thresholds. Large incumbents can shape standards around their existing systems. Compliance can become a substitute for genuine safety. Small developers and open communities can be excluded. Regulation can freeze assumptions that the underlying science no longer supports.
Progressive standards and requirements exist to navigate between these risks.
The central idea is not that every voluntary practice should move inevitably toward regulation.
The central idea is that institutional form should strengthen as four conditions strengthen:
A new evaluation method may begin as a research prototype.
If it proves useful, it may become:
This sequence is not automatic.
Different practices may stop at different levels.
Some should remain voluntary because:
Other practices may warrant formal requirements because:
Standards Body adopts the following core position:
Frontier AI requirements should mature through evidence-based stages. Formality, assurance, and enforcement should increase only when the underlying practice is sufficiently valid, implementable, decision-relevant, proportionate, and legitimate for the consequences at issue.
A progressive regime should separate several dimensions that are often compressed into the word "mandatory":
Substantive strength
How demanding is the technical or organizational requirement?
Coverage
Which systems, organizations, deployments, or capabilities are included?
Assurance depth
Is compliance self-attested, independently reviewed, audited, certified, or continuously monitored?
Transparency
What must be disclosed publicly or to an authority?
Enforcement
What happens when requirements are not met?
Decision consequence
Does nonconformity trigger remediation, restricted access, delayed deployment, financial penalty, or prohibition?
Geographic reach
Is the requirement organizational, sectoral, national, or international?
These dimensions can progress separately.
For example:
The strongest pathway from voluntary practice to formal requirement should include:
Existing institutions illustrate different parts of this progression.
The NIST AI Risk Management Framework was designed as a voluntary and adaptable resource for managing AI risk.[^nist-rmf] ISO/IEC 42001 provides certifiable requirements for an AI management system, while ISO/IEC 42006 adds requirements for bodies auditing and certifying those systems.[^iso-42001][^iso-42006] The Hiroshima AI Process Code of Conduct and reporting framework provide a voluntary international structure for advanced AI governance disclosures.[^haip-code][^haip-reporting] The European Union AI Act establishes binding, risk-based legal obligations and includes roles for standards, codes, conformity assessment, and oversight.[^eu-ai-act] Frontier developers have also published voluntary capability-linked frameworks that connect rising capability evidence to stronger internal safeguards.[^openai-pf][^anthropic-rsp][^deepmind-fsf]
These examples should not be flattened into one model.
They show a broader institutional pattern:
The purpose of this foundation is to define how that progression can occur without confusing speed with legitimacy, formality with effectiveness, or compliance with safety.
Requirements should become more formal only as their evidence, implementation capacity, consequence, and legitimacy justify greater institutional force.
Voluntary practice is not merely a temporary stage before regulation. Some practices should remain voluntary, experimental, contextual, or professional rather than mandatory.
A requirement should not become stronger merely because concern becomes stronger. The evidence supporting the requirement must also improve.
A technically sound requirement can fail when the institutions responsible for implementation, assurance, enforcement, or appeal are not ready.
The burden of a requirement should be proportionate to the capability, deployment, scale, access, consequence, and uncertainty involved.
Every formal requirement should possess a mechanism for interpretation, revision, suspension, and retirement.
Standards gain legitimacy through competent process, evidence, participation, transparency, accountability, and correction, not through the word "standard" alone.
Good requirements should channel innovation toward better evidence, safeguards, and public benefit rather than freeze one technical approach.
This paper covers progressive institutional expectations concerning:
This paper does not fully specify:
Those subjects require legal and jurisdiction-specific expertise.
A standard may be voluntary.
A requirement may refer to a standard.
A standard can become influential through:
Technical requirements govern matters such as:
Institutional requirements govern matters such as:
Both are necessary.
Some requirements apply across AI systems.
Others should apply only to:
A document established through a recognized process that provides rules, guidelines, characteristics, or common practices for repeated use.
A document defining technical requirements, methods, interfaces, measurements, or performance characteristics.
Nonbinding guidance describing a preferred method based on available evidence and professional judgment.
A structured set of concepts, outcomes, functions, or practices that helps organizations manage a problem while allowing adaptation.
A set of commitments or expected behaviors adopted voluntarily or recognized by an institution.
A more operational body of guidance or rules describing how requirements may be met in practice.
Explanatory or advisory material supporting interpretation and implementation.
A condition that must be fulfilled within a defined context.
A requirement accepted by choice through a framework, contract, certification scheme, membership, or internal policy.
A requirement imposed by an authority or binding legal arrangement.
A public or private obligation adopted by an organization and enforced through internal governance.
Governance created through contracts, procurement, insurance, platforms, professional rules, or market relationships rather than direct legislation.
A condition that must be met to sell to or contract with a purchaser.
A condition evaluated through a defined certification scheme.
Demonstration that specified requirements are fulfilled.
A legal or institutional provision that offers defined protection or reduced liability when specified practices are followed.
A controlled environment in which organizations test innovations under oversight and defined conditions.
A requirement defining an outcome to be achieved without mandating the exact method.
A requirement specifying the method, control, or process to be used.
A requirement whose applicability or rigor varies according to risk.
A requirement triggered by demonstrated or reasonably anticipated AI capability.
A requirement triggered by use context, access, scale, or integration.
A requirement triggered by characteristics of the provider or deployer, such as role, scale, or control.
A requirement organized into levels of increasing rigor.
Staged introduction of a requirement over time or across categories.
Allowing existing systems or practices to continue under earlier rules.
A provision causing a requirement to expire unless renewed.
A requirement that the rule be reassessed at a defined time or after specified events.
Use of an external standard or document as part of a binding requirement.
A legal or institutional presumption that compliance with recognized standards provides evidence of compliance with specified requirements.
A sequence of progressively stronger responses to nonconformity.
A pattern in which requirements become progressively stronger but are difficult to reduce after evidence changes.
Formal conformity without meaningful achievement of the underlying safety, reliability, or accountability objective.
Acceptance of different methods that achieve an adequately comparable outcome.
A defined test that must be passed before a practice moves to a more formal institutional stage.
Technical systems can change faster than formal legislation.
Research and voluntary standards can respond earlier.
A legal requirement needs:
Research frameworks can develop these foundations.
Organizations can test:
before a requirement becomes universal.
Standards can convert broad principles into:
Independent assessment makes claims more credible.
Procurement, insurers, investors, platforms, and professional bodies can reward mature practice.
Law can address:
A mature requirement must continue to evolve.
The same progression can become:
Progression must be conditional.
Standards Body proposes a fourteen-stage ladder.
The ladder is descriptive and design-oriented, not inevitable.
Characteristics:
Outputs:
Characteristics:
Outputs:
Characteristics:
Outputs:
Characteristics:
NIST describes the AI RMF as a voluntary, rights-preserving, non-sector-specific resource intended to support AI risk management.[^nist-rmf][^nist-airc]
Characteristics:
The Hiroshima AI Process reporting framework provides a common voluntary structure for organizations to report on advanced AI governance and risk-management practices.[^haip-reporting]
Characteristics:
Frontier safety frameworks published by developers illustrate this stage.[^openai-pf][^anthropic-rsp][^deepmind-fsf]
Characteristics:
Characteristics:
ISO/IEC 42001 specifies requirements for establishing, implementing, maintaining, and continually improving an AI management system.[^iso-42001]
Characteristics:
ISO/IEC 42006 sets additional requirements for bodies auditing and certifying AI management systems against ISO/IEC 42001.[^iso-42006]
Characteristics:
Characteristics:
Characteristics:
Characteristics:
Characteristics:
Characteristics:
The European Union AI Act demonstrates a binding risk-based legal framework using differentiated obligations, conformity mechanisms, governance, and enforcement.[^eu-ai-act]
A practice may appropriately stop at:
Some requirements may move from research directly to procurement.
Others may move from law to standards through delegated implementation.
Others may remain internal.
A requirement may move downward when:
A broad practice may split into:
Mandatory is not automatically better than voluntary.
A voluntary practice can be rigorous.
A legal obligation can be ineffective.
A requirement may be:
Assessment should be multidimensional.
A practice should pass readiness gates before moving to a more formal stage.
Questions:
Questions:
Questions:
Questions:
Questions:
Questions:
Questions:
Questions:
Questions:
Questions:
Questions:
Questions:
Do not strengthen institutional force faster than evidentiary support.
Focus strongest requirements where consequence is greatest.
Prefer performance or outcome requirements when multiple methods can achieve the objective.
Prescriptive controls may be justified when:
Use different requirements for:
State why and when stronger requirements apply.
Do not require full certification for every practice.
Early stages should include:
Allow alternative methods, evidence, appeals, and review.
Avoid mandating one implementation unnecessarily.
Do not use neutrality to avoid specifying necessary safety outcomes.
Include diverse expertise, transparent conflicts, and review of market effects.
Use scaled requirements, common infrastructure, and reasonable timelines.
Standards incorporated into requirements should be version-governed.
Conformity should not support claims broader than the requirement.
Automation of compliance should not remove accountable decision-makers.
Design metadata and evidence for cross-border understanding.
Every significant requirement should be reviewable and retireable.
Requirement applies when evaluation shows a defined capability level.
Advantages:
Risks:
Requirement applies based on training or inference compute.
Advantages:
Risks:
Applies based on:
Applies to defined high-risk uses.
Applies when:
Applies based on:
Risk:
Organization-based rules can entrench incumbents or create arbitrary distinctions.
Applies after:
Applies when capability approaches a threshold rapidly.
Combines capability, access, deployment, and consequence.
Standards Body position:
High-stakes requirements should usually use hybrid triggers rather than one proxy alone.
Applies broadly.
Examples:
Assurance:
Triggers:
Requirements:
Triggers:
Requirements:
Triggers:
Requirements:
Applies only when ordinary controls are inadequate for exceptionally consequential activities.
Requirements may include:
Voluntary frameworks can:
A voluntary framework should include:
The NIST AI RMF illustrates a voluntary, risk-management-oriented framework organized around Govern, Map, Measure, and Manage functions.[^nist-rmf][^nist-airc]
Its flexibility is a strength.
The same flexibility means implementation depth can vary.
Voluntary frameworks are appropriate when:
Before progression, study:
Reporting can create:
Narrative disclosure.
Structured questions.
Comparable metrics.
Evidence-backed reporting.
Independently assured reporting.
The Hiroshima AI Process Code of Conduct provides voluntary guidance for organizations developing advanced AI systems, and the OECD reporting framework supports structured disclosure against its actions.[^haip-code][^haip-reporting][^haip-insights]
Reporting may become mandatory when:
Some information may be submitted to:
without full public release.
Define:
Internal or public commitments can connect:
OpenAI's Preparedness Framework, Anthropic's Responsible Scaling Policy, and Google DeepMind's Frontier Safety Framework connect capability or risk evidence to stronger safeguards and governance actions through different structures.[^openai-pf][^anthropic-rsp][^deepmind-fsf]
Assess:
Common elements may become candidates for:
Shared standards should not weaken stronger practice merely to achieve consensus.
Standards can make good practice:
A credible process should include:
ISO/IEC 42001 provides requirements for an AI management system and continual improvement.[^iso-42001]
Management-system standards can improve organizational discipline.
They do not establish that every AI system is safe.
May cover:
Define outcomes.
Define organizational or procedural controls.
Support interoperability.
A standard should normally define a minimum or common basis, not prohibit superior practice.
Use nonbinding or rapidly updateable annexes for immature methods.
A requirement without credible evidence of implementation may remain symbolic.
ISO/IEC 42006 sets additional requirements for bodies auditing and certifying AI management systems against ISO/IEC 42001.[^iso-42006]
This illustrates the institutional progression from management requirements to requirements for the bodies assessing them.
A practice is ready for certification only when:
Certification should not imply:
Frequently updated systems may require:
The third-party ecosystem supplies the competence and recognition needed for assurance.
Contracts can require:
Public and private purchasers can require standards or assurance.
Platforms can impose:
Insurers can condition:
on controls and evidence.
Investors and lenders may request risk-governance evidence.
Professional bodies may define acceptable AI use in:
Private ordering can:
Shared standards can reduce fragmentation.
Private ordering is insufficient when:
Law may reference standards as:
Law should identify:
Codes may provide a practical route to compliance while allowing alternatives.
Useful when:
Can encourage adoption.
Risks:
Can test requirements under supervision before broad application.
The EU AI Act establishes a phased, binding risk-based regime and uses standards, codes, conformity mechanisms, and public oversight as implementation tools.[^eu-ai-act][^eu-summary]
Its complexity also illustrates why legal progression requires implementation capacity, guidance, standards, codes, and institutional coordination.
Examples:
Define:
Should distinguish:
May be required for:
Authorities should use the evidence collected.
Use performance requirements when outcomes are measurable.
Use prescriptive minimums when:
A mandatory requirement should be no broader than needed to address the defined problem.
Allow equivalent methods when:
Exemptions should be:
May be necessary after severe incidents.
They should include:
A requirement without enforceable evidence can create false confidence.
Authorization may be justified only where:
Conditional approval can support learning.
Use narrow restrictions where possible:
Should require an exceptionally strong justification, clear scope, due process, and review.
A progressive system should use proportionate responses.
Reserved for severe and immediate cases.
Organizations need time to:
Use a pilot to test:
Can identify leaders and implementation problems.
May protect good-faith pilot participants.
Use cautiously.
A legacy system can still create current risk.
Provide:
Do not activate a requirement if:
unless consequence demands emergency action.
Formal requirements can disproportionately affect:
Scale obligations according to:
A small organization should not need the same bureaucracy as a large frontier laboratory if it can demonstrate equivalent outcomes.
Support:
Requirements should address:
Open projects may use:
Review whether each requirement:
A requirement is less legitimate when compliance is impossible for qualified good-faith actors.
Sandboxes can test:
under oversight.
A sandbox should produce:
Standards Body could support nonregulatory protocol sandboxes for:
Safe harbors can reward:
A safe harbor should require:
The broader incentive architecture is developed in Foundation 7.
Include:
No one stakeholder category should control the outcome.
Publish material interests.
Arguments should be tied to evidence and decision consequences.
Preserve unresolved disagreement.
Allow review where security permits.
Rotate leadership and committee membership.
Avoid dependence on one sector.
Assess whether requirements create concentration.
Study who benefited, who was excluded, and whether outcomes improved.
Align on:
Jurisdictions may differ in:
International standards can support common implementation.
Voluntary international codes can generate shared practice before binding coordination.
Recognize:
when base requirements are compatible.
Use:
Interoperability should not require weakening high-stakes controls.
Large markets can shape global practice through access conditions.
This can improve coordination or export one jurisdiction's assumptions without adequate participation.
The Council of Europe Framework Convention on Artificial Intelligence provides a treaty-level human-rights, democracy, and rule-of-law framework, illustrating a distinct international pathway from voluntary practice to binding commitments for parties.[^coe-convention]
Global interoperability is developed fully in Foundation 8.
A requirement may reference a standard that later changes.
The rule references a specific version.
Strength:
Risk:
The rule automatically follows later versions.
Strength:
Risk:
A designated authority reviews each new version before recognition.
Specify:
Allow rapid correction for:
with retrospective review.
Every change should state:
Prevent permanent rules based on temporary evidence.
Include:
Strengthening should not be easier than reducing when evidence supports reduction.
Requirements themselves should be evaluated.
Did the requirement reduce the defined risk or improve evidence?
Who complied?
Was compliance substantive or formal?
What did implementation cost?
Did the requirement increase concentration?
Did it support or suppress beneficial methods?
Who gained and who bore cost?
Was nonconformity detected and corrected?
Did it reduce or increase fragmentation?
Examples:
What would have happened without the requirement?
Use the scorecard in Section 49.
A progressive standards regime may include:
Separate:
where concentration creates conflicts.
At its present stage, Standards Body should:
A future institution might:
Only after competence and legitimacy are earned.
Government retains responsibility for legal obligations and coercive enforcement.
Affected parties need a path to challenge:
Should be narrow, time-limited, and reviewable.
Identify:
Select practices with:
Assess:
Run with diverse organizations.
Report:
Create repeatable requirements.
Test methods and institutional design.
Develop evaluators, proficiency, and security.
Use procurement or contracts.
Assess nonadoption, externalities, systemic risk, and market failure.
Include:
Evaluate outcomes continuously.
Progressive Frontier Evaluation Assurance Pathway
Test how one mature evaluation practice can move responsibly from voluntary protocol to independently assured procurement requirement.
Use the autonomous cyber evaluation protocol developed under Foundations 1 through 5.
Publish guidance for:
Participating organizations disclose:
Multiple evaluators complete proficiency testing.
Define:
A willing purchaser requires the assured evaluation for specified high-autonomy cyber deployments.
Assess:
Choose:
The pilot succeeds if it demonstrates:
Failure: Immature practice becomes binding.
Safeguard: Readiness gates, pilots, sunset, independent evidence.
Failure: Severe externalities persist because no formal minimum emerges.
Safeguard: Nonadoption and harm triggers for escalation review.
Failure: Requirements strengthen but never weaken.
Safeguard: symmetric review and retirement mechanisms.
Failure: Documentation substitutes for real outcomes.
Safeguard: performance evidence, testing, incidents, independent review.
Failure: A narrow benchmark becomes a legal capability threshold.
Safeguard: evidence portfolio, dynamic protocols, uncertainty, alternatives.
Failure: Requirements favor large laboratories.
Safeguard: competition analysis, small-actor pathways, public participation.
Failure: A committee codifies member interests.
Safeguard: balance, conflict disclosure, minority reports, public review.
Failure: Requirement activates before assurance capacity exists.
Safeguard: capacity gate, phase-in, shared facilities.
Failure: Narrow conformity becomes broad safety marketing.
Safeguard: claim controls, scope, version, expiry.
Failure: Incompatible requirements multiply.
Safeguard: metadata, crosswalks, mutual recognition.
Failure: International agreement weakens necessary controls.
Safeguard: baseline plus advanced tiers.
Failure: One method becomes mandatory after better methods emerge.
Safeguard: outcome equivalence, alternative compliance, review.
Failure: Actors cannot comply in practice.
Safeguard: support, realistic timeline, cost analysis.
Failure: Requirements assume centralized corporate control.
Safeguard: decentralized pathways and functional equivalence.
Failure: Actors move activity to weak jurisdictions.
Safeguard: international cooperation and market-access rules.
Failure: Private standard setters gain public power without accountability.
Safeguard: transparent recognition and version control.
Failure: Minimum compliance blocks accountability.
Safeguard: narrow scope, good-faith condition, review, no immunity for concealment.
Failure: Temporary rules become permanent.
Safeguard: automatic expiry and independent renewal.
Failure: Organizations produce low-value disclosure.
Safeguard: decision-linked reporting and harmonization.
Failure: Rule remains after technical conditions change.
Safeguard: event triggers and periodic review.
Voluntary systems can suffer weak adoption and enforcement.
Response:
Residual concern:
Some actors will not adopt costly practices without formal requirements.
Public law has unique democratic and enforcement authority.
Response:
Standards, research, assurance, and private ordering can develop technical capacity and evidence that law needs.
They should not replace public authority where coercive power is required.
They can.
Response:
Residual concern:
Institutions may use "more study" to avoid action.
Response:
The framework explicitly allows practices to remain voluntary or be retired.
Response:
Residual concern:
Compliance ecosystems naturally create inertia.
Response:
Response:
Use thresholds to trigger review and safeguards rather than automatic prohibition.
This risk is substantial.
Response:
Full uniformity is unrealistic.
Interoperable evidence and mutual recognition are more achievable.
Correct when claims are broad.
Response:
Narrow scope, explicit limitations, system identity, surveillance, and expiry.
It can be opaque and coercive.
Response:
Use transparency, interoperability, appeal, competition review, and public law where rights or externalities require it.
Response:
Use stable outcome duties with updateable standards, controlled incorporation, and emergency guidance.
Residual concern:
Delegated updating can weaken accountability.
Which voluntary practices persist and improve outcomes?
What evidence should move a practice from voluntary to mandatory?
Do AI standards improve system behavior or mainly documentation?
Which claims are mature enough for meaningful certification?
How do procurement requirements affect safety, cost, and competition?
Can insurers evaluate AI controls reliably?
How should uncertain thresholds connect to formal obligations?
Which support mechanisms preserve participation?
How should progressive duties apply across decentralized ecosystems?
Which requirements can be recognized across jurisdictions?
How can standards update without improper delegation?
Which sanctions improve compliance without suppressing disclosure?
When do they encourage good practice versus excuse weak practice?
Do they produce transferable evidence?
How often are obsolete requirements actually retired?
Develop a repeatable method for classifying requirement readiness.
Validate gates for evidence, operations, assurance, legitimacy, and cost.
Compare implementation depth and outcomes.
Develop evidence-backed, comparable reporting.
Study whether ISO and other AI standards change practice.
Identify which requirements can support audit or certification.
Test private and public purchasing requirements.
Compare grants, shared infrastructure, tiering, and equivalence.
Develop uncertainty-aware trigger models.
Study proportionate responses and restoration paths.
Test disclosure and evaluation incentives.
Create evidence requirements and exit criteria.
Map voluntary, standards, and legal regimes.
Develop models for standards incorporated into law.
Evaluate real-world outcomes, burden, concentration, and unintended effects.
Apply the readiness gates to three candidate evaluation practices.
Test structured disclosure with independent evidence review.
Pilot a bounded evaluation requirement in a voluntary purchasing contract.
Compare full and scaled implementation for large and small organizations.
Test two different safeguard methods against the same requirement.
Estimate wait times and cost before formal requirement activation.
Model incentives for voluntary incident disclosure.
Pilot a new dynamic evaluation method under supervised conditions.
Test whether users understand narrow versus broad claims.
Simulate incorporation of a revised standard into contracts and regulation.
Apply a retrospective review to an existing AI requirement or commitment.
Compare evidence packages under two jurisdictions.
A future standard governing progressive AI requirements could require:
The risk or coordination problem.
Guidance, framework, standard, assurance, procurement, or mandatory duty.
Actors, systems, capabilities, deployments, exclusions.
Capability, deployment, access, use, incident, or hybrid.
Research, pilots, validation, counterevidence, uncertainty.
Construct, method, assurance, operations, economics, legitimacy.
Burden and consequence analysis.
Self-assessment, review, audit, certification, continuous monitoring.
Tools, guidance, training, infrastructure, phase-in.
Scaled requirements and support.
Detection, correction, sanction, restoration, appeal.
Standards mapping, evidence portability, mutual recognition.
Review, update, transition, emergency change.
Expiry, renewal, narrowing, and retirement.
Effectiveness, burden, competition, innovation, distribution.
Such a standard should be developed through STANDARDS_DEVELOPMENT_PROCESS.md.
Requirements referencing evaluations must update as protocols change.
Formal requirements may need protected evidence and secure administration.
Capability and consequence help determine when stronger obligations are justified.
Progressive requirements need credible challenge and decision review.
Assurance cannot scale without qualified evaluators and accreditation.
Voluntary stages rely heavily on incentives, recognition, and market reward.
Standards and requirements should support cross-border evidence and recognition.
Standards Body adopts the following working positions.
Frontier AI requirements should mature through evidence-based stages.
Voluntary practice is not automatically inferior to mandatory law.
Not every voluntary practice should become mandatory.
Formality should increase with consequence, evidence, implementation capacity, and legitimacy.
A requirement should not become binding before its construct and methods are sufficiently valid for the decision.
High-stakes uncertainty can justify interim safeguards before full scientific maturity.
Progressive requirements should separate substantive strength, coverage, assurance, transparency, enforcement, and decision consequence.
Hybrid triggers are generally preferable to a single model-size or compute proxy for high-stakes obligations.
Capability thresholds should often trigger additional review before automatic restriction.
Performance-based requirements should be preferred when equivalent methods can be verified.
Prescriptive minimums may be justified for essential controls.
Standards should normally function as common floors rather than ceilings on stronger practice.
Certification should be used only when requirements and assurance methods are mature enough.
Broad "safe AI" certification claims should be avoided.
Procurement, contracts, insurance, and professional rules can accelerate adoption but do not replace public law.
Public authority remains responsible for coercive requirements and legal accountability.
Standards incorporated into binding rules require transparent version governance.
Legal recognition of private standards should preserve public oversight and alternative compliance where appropriate.
Phase-in should reflect evaluator capacity and implementation reality.
Support for smaller actors is part of legitimate requirement design.
Open-source and decentralized systems require functional, not merely corporate, compliance pathways.
Requirements should be evaluated for market concentration and incumbent advantage.
Safe harbors should reward good-faith evidence and correction, not excuse concealment or harm.
Emergency requirements should expire unless affirmatively renewed.
Every significant requirement should have review, appeal, correction, and retirement mechanisms.
Compliance evidence should be tied to system version, configuration, and time.
Passing a requirement does not prove universal safety.
Voluntary nonadoption, repeated incidents, and severe externalities are valid reasons to consider stronger requirements.
International interoperability is preferable to unnecessary duplication.
Progressive standards should optimize for better outcomes, not the appearance of institutional maturity.
A practice is ready to move from research to recommended practice when:
A practice is ready to move from recommendation to voluntary framework when:
A practice is ready to move toward a standard when:
A practice is ready for assurance when:
A practice is ready for procurement or contractual requirement when:
A practice should be considered for mandatory status when:
A requirement should not be strengthened merely because:
A requirement should be narrowed, suspended, or retired when:
Practice:
Current stage:
Proposed stage:
Decision date:
Decision body:
Covered system:
Covered deployment:
Required protocol or standard:
Version:
The supplier shall:
Requirement:
Version:
Review period:
| Dimension | Core Question |
|---|---|
| Problem | Is the problem specific and materially evidenced? |
| Objective | Is the desired outcome clear? |
| Construct | Can the requirement be interpreted consistently? |
| Evidence | Does evidence support the practice? |
| Method | Can implementation be repeated? |
| Dynamic quality | Can the requirement evolve with frontier systems? |
| Scope | Are covered actors and systems defined? |
| Trigger | Is application based on defensible evidence? |
| Proportionality | Does burden match consequence? |
| Assurance | Can conformity be assessed credibly? |
| Evaluator capacity | Are qualified assessors available? |
| Operational readiness | Can organizations implement the rule? |
| Security | Can sensitive evidence be handled safely? |
| Transparency | Are reasons, evidence, and status legible? |
| Competition | Does the requirement avoid unjustified concentration? |
| Small-actor access | Are realistic pathways available? |
| Open-source fit | Can decentralized actors demonstrate outcomes? |
| Innovation | Are alternative methods and improvement possible? |
| Private ordering | Can contracts and procurement use the requirement coherently? |
| Legal recognition | Is incorporation accountable and version-controlled? |
| Enforcement | Can nonconformity be detected and corrected? |
| Appeals | Can parties challenge error or overreach? |
| Phase-in | Is timing realistic and risk-based? |
| International | Is evidence interoperable across jurisdictions? |
| Review | Are periodic and event-triggered reviews defined? |
| Sunset | Can obsolete requirements expire? |
| Impact | Are effectiveness and unintended effects measured? |
| Legitimacy | Was the process competent, inclusive, and accountable? |
| Decision utility | Does the requirement improve a real decision or outcome? |
Standards become dangerous when they are treated as self-justifying.
A standard can coordinate good practice.
It can also freeze bad measurement.
A voluntary framework can enable experimentation.
It can also allow persistent nonadoption.
A certification can create confidence.
It can also create a misleading badge.
A legal requirement can protect people who cannot protect themselves.
It can also entrench incumbents, suppress beneficial innovation, and preserve assumptions long after the evidence changes.
The answer is not to choose voluntarism or regulation as an ideology.
The answer is to design an evidence-based progression.
That progression should ask:
The future of frontier AI governance will likely include all of the following:
The question is not which single mechanism should govern everything.
The question is which mechanism is justified at which stage, for which system, under which evidence, and with which safeguards against institutional failure.
Progressive standards should preserve the ability to act before harm is obvious.
They should also preserve the ability to learn before law hardens.
They should create stronger expectations where consequences rise.
They should resist turning early assumptions into permanent authority.
The sixth foundation of Standards Body is therefore disciplined institutional progression.
Standards should become stronger when the evidence and the stakes justify strength.
They should remain revisable because the systems they govern will not stand still.
[^nist-rmf]: National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023. https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
[^nist-airc]: National Institute of Standards and Technology, NIST AI Resource Center. https://airc.nist.gov/
[^nist-playbook]: National Institute of Standards and Technology, AI RMF Playbook. https://airc.nist.gov/airmf-resources/playbook/
[^nist-tevv]: National Institute of Standards and Technology, AI Test, Evaluation, Validation and Verification. https://www.nist.gov/ai-test-evaluation-validation-and-verification-tevv
[^nist-global]: National Institute of Standards and Technology, A Plan for Global Engagement on AI Standards, 2024. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-5.pdf
[^nist-zero-draft]: National Institute of Standards and Technology, Outline: Proposed Zero Draft for a Standard on AI Testing, Evaluation, Verification, and Validation, 2025. https://www.nist.gov/document/outline-proposed-zero-draft-standard-ai-testing-evaluation-verification-and-validation
[^iso-42001]: International Organization for Standardization, ISO/IEC 42001:2023, Artificial intelligence management systems. https://www.iso.org/standard/42001
[^iso-42006]: International Organization for Standardization, ISO/IEC 42006:2025, Requirements for bodies providing audit and certification of artificial intelligence management systems. https://www.iso.org/standard/42006
[^iso-23894]: International Organization for Standardization, ISO/IEC 23894:2023, Artificial intelligence, Guidance on risk management. https://www.iso.org/standard/77304.html
[^iso-standards]: International Organization for Standardization, Standards. https://www.iso.org/standards.html
[^haip-code]: G7 Hiroshima AI Process, International Code of Conduct for Organizations Developing Advanced AI Systems, 2023. https://digital-strategy.ec.europa.eu/en/library/hiroshima-process-international-code-conduct-advanced-ai-systems
[^haip-reporting]: OECD, Hiroshima AI Process Reporting Framework. https://oecd.ai/en/hiroshima
[^haip-about]: OECD, About the Hiroshima AI Process Reporting Framework. https://oecd.ai/en/transparency/about
[^haip-insights]: OECD, Early Insights from the Hiroshima AI Process Reporting Framework, 2025. https://oecd.ai/en/wonk/haip-reporting-insights
[^eu-ai-act]: European Union, Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence, 2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
[^eu-summary]: EUR-Lex, Rules for Trustworthy Artificial Intelligence in the European Union. https://eur-lex.europa.eu/EN/legal-content/summary/rules-for-trustworthy-artificial-intelligence-in-the-eu.html
[^coe-convention]: Council of Europe, Framework Convention on Artificial Intelligence and Human Rights, Democracy and the Rule of Law, 2024. https://www.coe.int/en/web/artificial-intelligence/the-framework-convention-on-artificial-intelligence
[^openai-pf]: OpenAI, Preparedness Framework, Version 2, April 15, 2025. https://cdn.openai.com/pdf/18a02b5d-6b67-4cec-ab64-68cdfbddebcd/preparedness-framework-v2.pdf
[^anthropic-rsp]: Anthropic, Responsible Scaling Policy, 2026. https://www.anthropic.com/responsible-scaling-policy
[^deepmind-fsf]: Google DeepMind, Frontier Safety Framework, updated 2025. https://deepmind.google/blog/strengthening-our-frontier-safety-framework/
[^frontier-forum]: Frontier Model Forum, Issue Brief: Components of Frontier AI Safety Frameworks, 2024. https://www.frontiermodelforum.org/updates/issue-brief-components-of-frontier-ai-safety-frameworks/
Date: July 16, 2026
Change type: Complete foundational edition
Summary: Establishes the fully developed canonical working white paper for Foundation 6. Defines the rationale for progressive institutionalization, a fourteen-stage standards ladder, readiness gates, design principles, trigger models, risk tiers, voluntary frameworks, reporting, frontier safety frameworks, consensus standards, assurance, private ordering, legal recognition, mandatory requirements, authorization, enforcement, phase-in, small-actor and open-source pathways, sandboxes, safe harbors, anti-capture, international interoperability, version governance, sunset, requirement evaluation, governance, implementation, a Standards Body pilot, metrics, failure analysis, objections, evidence gaps, research agenda, operational templates, scorecard, and primary-source research basis.
Status: Ready for internal review and future expert critique.