Institutional-design proposal · Public edition

Standards Body Standards Development Process

Version 1.0 · Released July 17, 2026 · Current

Research basis reviewed through July 16, 2026

Document status: Approved foundational source

This is the public edition of a canonical Standards Body institutional-design document. It is research and a design proposal for a possible future institution. It governs Standards Body’s own conduct where applicable, but it is not a description of a current operating standards, assurance, accreditation, certification, partnership, or contributor program, and Standards Body does not currently operate one.

Document record and authority notice

Project: Standards Body
Primary domain: standardsbody.ai
Core line: Foundations for Frontier AI
Document type: Canonical standards-development constitution, lifecycle, consensus process, drafting system, approval architecture, maintenance framework, and procedural due-process code
Version: 1.0
Status: Approved foundational source
Document owner: Standards Body
Present institutional stage: Foundational research and institutional design
Applies to: Proposed Standards Body standards, technical specifications, terminology standards, test methods, evaluation protocols, reporting specifications, interoperability profiles, management-system requirements, competence standards, implementation guidance, amendments, corrections, interpretations, withdrawals, and future standards programs
Related canonical sources: PROJECT_IDENTITY.md, PROJECT_MANIFESTO.md, INSTITUTION_DESIGN.md, GOVERNANCE_FRAMEWORK.md, FOUNDATIONS.md, FOUNDATIONS_APPENDIX.md, TERMINOLOGY.md, EVIDENCE_STANDARDS.md, RESEARCH_METHODOLOGY.md, TAXONOMY.md, EVALUATION_PHILOSOPHY.md, and the eight foundation papers
Research basis reviewed through: July 16, 2026
Review cycle: Annual procedural review, with event-triggered revision following a material process failure, appeal, legal change, standards-system change, urgent AI-development change, or institutional-stage transition

Authority Note

This document defines the internal process Standards Body should use to develop standards and the process required before Standards Body may accurately describe itself as operating a formal standards-development program.

It does not establish that Standards Body is currently:

A formally recognized standards-development organization
An ANSI-Accredited Standards Developer
An ISO or IEC member body
A CEN, CENELEC, ETSI, IEEE, IETF, W3C, OASIS, or other recognized standards organization
A regulator
A government agency
A certification body
An accreditation body
A conformity-assessment body
An international organization
A source of legally binding requirements

Until the institutional readiness requirements in this document are met, Standards Body outputs should be labeled accurately as:

Research framework
working paper
proposed specification
pilot specification
draft standard
public-review draft
implementation profile

An approved Standards Body standard would remain voluntary unless made binding through a separate lawful, contractual, procurement, certification, or regulatory mechanism.

Standards Body should never imply that internal approval alone creates:

Legal compliance
regulatory approval
certification
accreditation
presumption of conformity
international consensus
market authorization
proof of safety

Document Purpose

This document establishes the complete standards-development process for Standards Body.

It defines:

Which outputs qualify as standards and which do not
The principles governing standards development
The constitutional relationship among the Governing Board, Standards Council, Scientific and Evaluation Council, Public Interest and Rights Council, International Coordination Forum, Security and Confidentiality Committee, Appeals and Review Panel, Secretariat, working groups, contributors, participants, members, funders, and external institutions
The standards work program
New-work proposals
scope and charter development
stakeholder mapping and balanced participation
working-group formation
evidence review
drafting and editing
prototype and pilot requirements
public review and comment disposition
consensus
voting
substantial objections
dissent
appeals
approval
publication
implementation
adoption
interpretations
corrections
amendments
systematic review
confirmation
revision
supersession
withdrawal
retirement
urgent and provisional standards
intellectual property
patents
licensing
accessibility
translations
international coordination
regulatory relationships
conformity-assessment readiness
process audit
performance metrics
failure recovery

The process is designed for frontier AI, a domain in which:

Technical capabilities change rapidly
evaluation methods can become stale
some evidence must remain confidential
standards may affect severe-risk decisions
public law may incorporate private standards
access to expertise and systems is uneven
dominant firms possess disproportionate resources
model behavior is probabilistic and context-dependent
international compatibility matters
poorly designed standards can create false assurance

The governing procedural rule is:

A Standards Body standard should emerge from a documented public-interest need, credible evidence, balanced and competent participation, genuine consideration of objections, validated implementation, independent process controls, and a maintained lifecycle.

Executive Summary

Standards convert knowledge into repeatable expectations.

They can define:

Terminology
measurement methods
system identity
evaluation protocols
evidence formats
reporting requirements
organizational processes
competency requirements
interoperability mechanisms
assurance criteria

Standards can make complex systems easier to compare, audit, procure, regulate, and improve.

They can also create serious institutional failures.

A premature standard can freeze a weak method.

A vague standard can create compliance theater.

A prescriptive standard can entrench one technical architecture.

A proprietary standard can exclude smaller actors.

A hidden drafting process can give private interests de facto regulatory power.

A standard designed by evaluators may create demand for the evaluators' own services.

A standard built around current frontier laboratories may become inaccessible to open-source communities, startups, public institutions, and lower-resource regions.

A standard that becomes law may acquire consequences far beyond the process that produced it.

A standard that is never maintained can remain influential after its technical foundation has failed.

The central process proposition is:

Standards authority should arise from the quality of the problem definition, evidence, participation, consensus process, implementation, maintenance, and accountability, not from the prestige of the issuing institution.

Standards Body Process Model

The complete process contains fifteen stages.

Need identification
preliminary research
new-work proposal
authorization and classification
charter and scope
working-group formation
evidence and requirements development
working draft
pilot or reference implementation
committee draft
public review
comment resolution and consensus
approval
publication and implementation
maintenance, revision, and retirement

The process is not a conveyor belt.

A project may be:

Re-scoped
returned to research
split
paused
discontinued
published as guidance rather than a standard
withdrawn after public review
retired after implementation failure

Process Principles

The process is governed by:

Transparency
openness
impartiality
balance
lack of dominance
due process
consensus
effectiveness
relevance
coherence
accessibility
development and capacity considerations
evidence maturity
technical competence
public-interest review
security proportionality
maintenance
appeal
correction

These principles draw from established standards practice, including ISO and IEC procedures, ANSI due-process requirements, WTO principles for international standards, CEN and CENELEC principles, and open technical standards processes such as IETF, W3C, and OASIS.[^iso-directives][^ansi-essential][^wto-principles][^cen-standards][^ietf-process][^w3c-process][^oasis-process]

Standards Categories

Standards Body may eventually develop:

Terminology standards
taxonomy standards
technical specifications
evaluation test methods
protocol standards
evidence and provenance standards
reporting standards
system-identity specifications
evaluator-competence standards
interoperability profiles
incident-reporting standards
management-system requirements
implementation guidance

A document should not be called a standard merely because it is authoritative inside the project.

Research papers, opinion essays, roadmaps, case studies, and early frameworks remain distinct.

Evidence Maturity

A standards project should be classified by evidence maturity.

S0: Research Question

The problem and methods remain uncertain.

S1: Research Method

A method exists but lacks broad implementation evidence.

S2: Recommended Practice

Evidence supports guidance but not formal conformity.

S3: Pilot Specification

A defined specification is ready for controlled implementation.

S4: Consensus Standard

Evidence, implementation, participation, and process support formal approval.

S5: Assurance-Ready Standard

Requirements are sufficiently precise and validated for conformity assessment.

S6: Public-Law or Formal Recognition Candidate

The standard may be suitable for external legal, procurement, regulatory, or international recognition, subject to the relevant authority.

A standard should not advance merely because time has passed.

Governance

The Standards Council owns the standards work program and process integrity.

The Scientific and Evaluation Council reviews technical and evidentiary sufficiency.

The Public Interest and Rights Council reviews rights, accessibility, distribution, competition, and affected-party concerns.

The International Coordination Forum reviews international duplication, interoperability, translation, and capacity.

The Security and Confidentiality Committee governs protected material.

The Appeals and Review Panel hears eligible procedural appeals.

The Governing Board authorizes the institution's standards role and reserves constitutional decisions.

The Executive Secretariat administers the process.

Working groups develop the technical content.

Consensus

Consensus means broad agreement after serious efforts to resolve substantial objections.

Consensus does not require unanimity.

Consensus is not:

Silence
simple majority
absence of visible objection after exclusion
agreement among only dominant participants
acceptance produced by time pressure
chair declaration without evidence

A substantial objection must be:

Recorded
considered
answered
resolved, partly resolved, preserved as dissent, or rejected with reasons

Public Review

A mature standard should ordinarily receive at least one public-review period.

Recommended minimum:

45 days for the first public review
30 days for subsequent substantive review
15 days for narrowly bounded correction or urgent provisional review

Longer periods should be used when:

The standard is complex
participation is international
translation is required
small actors need time
the standard may support law or conformity assessment

Approval

Approval requires more than a positive vote.

The approval package should show:

Need
scope
evidence
balance
participation
pilot evidence
comment disposition
consensus assessment
public-interest review
security review
implementation and maintenance plan
unresolved dissent
appeals status

Maintenance

Every standard should have:

Owner
identifier
version
publication date
effective date
review date
issue tracker
interpretation process
correction process
amendment process
incident triggers
supersession rules
withdrawal rules
retirement plan

Frontier AI standards should ordinarily receive review more frequently than traditional five-year cycles when technology and threats move rapidly.

Process Outcome

The objective is not to publish the greatest number of standards.

The objective is to publish standards that:

Solve a real coordination or assurance problem
remain within evidence
can be implemented
can be evaluated
do not create misleading claims
preserve competition
support international use
remain current
can be corrected or withdrawn

The final process rule is:

Do not standardize uncertainty merely to create institutional certainty. Standardize only what is sufficiently understood, useful, implementable, reviewable, and maintainable for the consequence at issue.

1. Foundational Standards-Development Propositions

1.1 Need Before Document

A standards project should begin with a demonstrated coordination, measurement, safety, assurance, interoperability, or public-interest need.

1.2 Evidence Before Obligation

The stronger the requirement, the stronger the evidence and implementation basis should be.

1.3 Function Before Form

Choose a standard, specification, guidance document, test method, profile, or research report according to the need.

1.4 Openness With Protected Evidence

Participation and governance should be open.

Protected technical details may remain controlled when necessary.

1.5 Consensus With Dissent

Consensus should seek broad agreement without erasing material disagreement.

1.6 Balance Without Artificial Equality

Participation should prevent dominance.

It need not assign identical numbers to every possible interest.

1.7 Competence and Interest Are Distinct

Stakeholders bring interests.

Experts bring competence.

A credible process needs both.

1.8 Public Interest Is Substantive

Public-interest review should affect scope, requirements, claims, and implementation.

1.9 Implementation Validates Drafting

A standard should be tested through implementations, pilots, simulations, or field evidence before high-consequence approval.

1.10 Performance Over Prescription

Use performance-based requirements when different technical approaches can achieve the objective credibly.

1.11 Precision for Conformity

A requirement intended for conformity assessment should be sufficiently precise to support consistent evidence and decisions.

1.12 No Standard by Reputation

Prestigious participants do not eliminate the need for due process.

1.13 Maintenance Is Part of Development

A standard without a maintenance system is incomplete.

1.14 Coherence

Standards Body should avoid conflicting with or duplicating suitable external standards without reason.

1.15 Accessibility

Participation and access should not be limited unnecessarily by fees, language, location, or organizational size.

1.16 Legal Effect Must Be Externalized

The legal effect of a standard arises from an external lawful mechanism, not from the document's internal label.

1.17 Assurance Readiness Is Separate

A technically useful standard may not yet be suitable for certification, audit, or accreditation.

1.18 Correctability

Standards should support interpretation, correction, revision, suspension, supersession, and withdrawal.

2. Scope and Non-Claims

2.1 Documents Covered

This process applies to:

Standards
specifications
test methods
protocol standards
reporting standards
terminology standards
interoperability profiles
competence standards
management-system standards
implementation guidance
amendments
corrections
interpretations

2.2 Documents Not Automatically Covered

The following do not automatically enter the standards process:

Research papers
blog posts
policy commentary
educational material
case studies
internal procedures
project roadmaps
experimental code
draft task banks
public statements

2.3 Legal Non-Claim

Approval does not establish legal compliance unless the relevant legal authority gives it that effect.

2.4 Safety Non-Claim

Conformity with a standard does not establish universal safety.

2.5 Consensus Non-Claim

Standards Body consensus does not establish worldwide consensus.

2.6 International Non-Claim

International participants do not transform Standards Body into an international organization.

2.7 Certification Non-Claim

A standard is not a certificate.

2.8 Accreditation Non-Claim

A standards-development process is not accreditation.

3. Canonical Definitions

Definitions in TERMINOLOGY.md govern.

3.1 Standard

A document established through a defined process that provides requirements, specifications, guidelines, characteristics, or common practices for repeated use.

3.2 Technical Specification

A detailed description of technical requirements, interfaces, methods, structures, or performance.

3.3 Test Method

A specified procedure for measuring or evaluating one or more properties.

3.4 Protocol Standard

A standard defining a complete evaluation or operational protocol.

3.5 Profile

A selected and constrained implementation of broader standards for a defined use, domain, or jurisdiction.

3.6 Requirement

A condition that must be fulfilled within the document's stated scope.

3.7 Recommendation

A provision expressing a preferred course of action.

3.8 Permission

A provision identifying an allowed course of action.

3.9 Consensus

Broad agreement after serious effort to address substantial objections.

3.10 Substantial Objection

A reasoned material concern concerning technical validity, safety, rights, implementation, legal effect, competition, interoperability, evidence, or process.

3.11 Public Review

A defined period during which interested persons may review and comment on a draft.

3.12 Comment Disposition

The documented treatment of a submitted comment.

3.13 Working Draft

An editor- or working-group-controlled draft without approved standards status.

3.14 Committee Draft

A draft approved by the responsible committee for a defined next stage.

3.15 Public-Review Draft

A committee draft released for public review.

3.16 Approved Standard

A document approved under the applicable Standards Body process.

3.17 Interpretation

A formal clarification concerning application of an existing provision without changing its normative requirement.

3.18 Amendment

A formally approved change to part of a standard.

3.19 Revision

A new edition or version incorporating substantive changes.

3.20 Confirmation

A decision that an existing standard remains current without substantive revision.

3.21 Supersession

Replacement of one standard or version by another.

3.22 Withdrawal

Formal termination of current Standards Body approval.

3.23 Retirement

End of active maintenance and recommended current use.

3.24 Normative Provision

A provision containing a requirement, recommendation, permission, definition, or rule necessary for implementation.

3.25 Informative Material

Explanatory or supporting material that does not create a normative obligation.

4. Standards-Development Principles

4.1 Transparency

Publish:

Work program
project status
participation routes
drafts
public comments or summaries
decisions
standards
corrections
maintenance status

4.2 Openness

Persons with a direct and material interest should have meaningful opportunities to participate.

ANSI describes due process as the right of an interested party to express a position and its basis, have that position considered, and have access to appeal.[^ansi-essential]

4.3 Impartiality

The process should not privilege a supplier, country, region, evaluator, funder, or technical architecture improperly.

4.4 Balance

No interest category should dominate.

4.5 Lack of Dominance

Dominance can exist without numerical majority through:

Funding
chair control
technical access
drafting control
time resources
voting blocs
model access
legal expertise
language

4.6 Consensus

The process should attempt to reconcile conflicting views and document unresolved objections.

4.7 Due Process

Participants should receive:

Notice
opportunity
consideration
reasons
appeal

4.8 Effectiveness and Relevance

A standard should respond to a real need and remain current.

4.9 Coherence

Avoid conflicting or duplicative standards.

4.10 Development Dimension

Consider the ability of developing economies, lower-resource institutions, and small actors to participate and implement.

The WTO identifies the development dimension as one of its six principles for international standards.[^wto-principles]

4.11 Evidence

Requirements should be supported by evidence appropriate to consequence.

4.12 Implementability

A standard should be usable in real systems.

4.13 Verifiability

Requirements intended for conformity assessment should support consistent evidence.

4.14 Security

Protect sensitive information proportionately.

4.15 Accessibility

Support:

Public access
understandable language
disability access
remote participation
translation
affordable implementation

4.16 Maintenance

Update or withdraw obsolete standards.

4.17 Accountability

Process actors should be conflict-screened and decisions reviewable.

5. Standards Document Architecture

5.1 Document Classes

Standards Body should distinguish the following document classes.

Research Report

Purpose:

Explore
synthesize
test
identify gaps

Normative status:

None unless a separate policy incorporates it

Recommended Practice

Purpose:

Describe an evidence-supported preferred approach

Normative status:

Advisory

Technical Specification

Purpose:

Define technical requirements, interfaces, formats, or procedures

Normative status:

May be normative within its scope

Test Method

Purpose:

Define measurement or evaluation procedure

Normative status:

Normative when referenced by a requirement or protocol

Protocol Standard

Purpose:

Define the complete architecture for administering and interpreting an evaluation or process

Reporting Standard

Purpose:

Define required metadata, disclosures, evidence, and status records

Terminology Standard

Purpose:

Define controlled terms and classifications

Competence Standard

Purpose:

Define knowledge, skills, experience, quality, and security requirements for persons or organizations

Management-System Standard

Purpose:

Define organizational processes, controls, records, review, and continual improvement

Interoperability Profile

Purpose:

Specify a compatible subset, mapping, or implementation of multiple standards

Implementation Guide

Purpose:

Explain practical use without creating new requirements

Provisional Specification

Purpose:

Support urgent implementation while evidence and consensus remain incomplete

5.2 Normative Status

Every document should state:

Whether it contains normative provisions
Who is expected to apply them
Whether application is voluntary
Which external mechanism may make them binding
Whether conformity assessment is intended
Which claims are prohibited

5.3 Standards Family

Related standards may form a family.

A family should define:

Architecture
common terminology
dependencies
optional profiles
version compatibility
maintenance coordination

5.4 Modular Standards

Frontier AI standards should be modular where possible.

Possible modules:

Common core
domain profile
deployment profile
capability profile
jurisdictional profile
assurance profile
security annex

5.5 Normative and Informative Separation

Normative text should be clearly distinguishable from:

Explanation
examples
rationale
notes
diagrams
historical context

5.6 Conformance Clause

A standard intended for implementation should define what it means to conform.

5.7 Claim Clause

The standard should specify permitted and prohibited public claims.

5.8 Version Clause

The standard should define how versions relate.

5.9 Maintenance Clause

The standard should define review and retirement.

6. Normative Language

6.1 Controlled Verbs

Standards Body should use controlled normative language.

Shall

Indicates a requirement.

Shall Not

Indicates a prohibition.

Should

Indicates a recommendation.

Should Not

Indicates a discouraged practice.

May

Indicates permission.

Can

Indicates possibility or capability, not permission.

6.2 Plain-Language Alternative

Where a document uses must rather than shall, the drafting convention should remain consistent and documented.

6.3 One Obligation Per Provision

A requirement should ordinarily contain one principal obligation.

6.4 Identifiable Subject

State who or what is responsible.

Weak:

Appropriate monitoring shall be performed.

Preferred:

The deployer shall monitor the system for the events listed in Section X.

6.5 Observable Requirement

A requirement intended for conformity assessment should identify evidence or observable outcome.

6.6 Avoid Undefined Qualifiers

Avoid unsupported terms such as:

Appropriate
adequate
sufficient
reasonable
robust
meaningful
regularly
timely

unless:

Defined
risk-based criteria are provided
professional judgment is explicitly governed
evidence expectations are stated

6.7 Technology Neutrality

Use technology-neutral language when the objective can be met through multiple valid approaches.

6.8 Prescriptive Language

Prescriptive requirements may be justified where:

Interoperability requires a common format
safety requires a specific control
performance cannot be assessed reliably
implementation variance creates unacceptable risk

6.9 Requirements Traceability

Each requirement should trace to:

Need
risk or objective
evidence
implementation
verification
related requirements

7. Standards Work Program

7.1 Purpose

The standards work program provides public visibility into planned and active work.

7.2 Work Program Contents

For each project, publish:

Project identifier
title
document class
purpose
scope
stage
responsible committee
chair and editor
participation route
relevant external standards
target dates
public-review status
maintenance owner
security classification
contact

7.3 Proposed Work

Proposed projects should be visible before authorization where practical.

7.4 Active Work

Active work should show milestone status.

7.5 Paused Work

A paused project should state:

Reason
last action
conditions for restart
review date

7.6 Discontinued Work

A discontinued project should preserve:

Reason
drafts
evidence
lessons
related successor work

7.7 Work Program Review

The Standards Council should review the work program at least twice each year.

7.8 Portfolio Balance

The work program should balance:

Foundational infrastructure
urgent safety needs
interoperability
evaluator capacity
implementation
maintenance
international coordination

7.9 No Publication Quota

The institution should not set publication quotas that incentivize weak standards.

8. Need Identification

8.1 Need Sources

A standards need may arise from:

Research
evaluation inconsistency
incidents
interoperability failure
legal or procurement needs
evaluator disagreement
public-interest concern
international coordination
technology change
implementation burden
market fragmentation
assurance demand

8.2 Need Statement

The need statement should answer:

What problem exists?
Who experiences it?
What evidence demonstrates it?
Why is a standard an appropriate response?
What alternatives exist?
What happens if no standard is developed?

8.3 Standardization Test

A standard may be appropriate when the problem requires:

Repeated common practice
comparable evidence
interoperability
shared terminology
minimum requirements
consistent reporting
competence recognition

8.4 Nonstandard Alternatives

Consider:

Research
guidance
education
open-source tool
procurement
bilateral agreement
professional practice
law
incident response
market competition

8.5 Prematurity Test

Do not begin formal standards work when:

The construct is undefined
evidence is contradictory and unresolved
implementation has not been attempted
one firm owns the only method
the problem changes too quickly for any stable core
conformity cannot be assessed
the standard would create misleading assurance

8.6 Urgency

Urgency may justify a provisional specification.

It does not eliminate the need for evidence, review, expiration, and correction.

9. Preliminary Research Stage

9.1 Purpose

The preliminary stage determines whether the topic is ready for standardization.

9.2 Research Questions

What is the technical state?
Which external standards exist?
Which laws or policies apply?
Which actors implement the practice?
Which failure cases exist?
Which evaluation methods are valid?
Which disagreements remain?
Which security issues exist?
Which groups may be excluded?

9.3 Deliverables

Landscape review
source register
terminology map
problem statement
evidence assessment
stakeholder map
standards-gap analysis
recommendation

9.4 Evidence Level

Apply EVIDENCE_STANDARDS.md.

9.5 Research Outcome

The outcome may recommend:

No standards project
further research
recommended practice
pilot specification
formal standards project
external liaison rather than new work

9.6 Public Research

Publish the preliminary research where safe.

9.7 Independent Review

High-consequence proposals should receive independent preliminary review.

10. New Work Proposal

10.1 Who May Propose

A proposal may be submitted by:

Council
working group
contributor
member
partner
public institution
evaluator
researcher
affected-party organization
Executive Secretariat

10.2 Required Fields

The proposal should include:

Identifier
proposed title
document class
problem
need
scope
non-scope
expected users
affected parties
evidence
existing standards
legal context
security
implementation
conformity-assessment intent
international relevance
resources
timeline
maintenance
conflicts
proposer

10.3 Public Notice

Publish the proposal for comment before authorization when practical.

10.4 Proposal Review

The Secretariat checks completeness.

The Standards Council assesses process and strategic fit.

The Scientific and Evaluation Council assesses technical and evidence maturity.

The Public Interest and Rights Council assesses affected-party and distributional concerns.

The International Coordination Forum assesses duplication and interoperability.

The Security Committee assesses sensitivity.

10.5 New Work Criteria

Approve only when:

The need is material
standardization is appropriate
scope is bounded
evidence maturity is sufficient for the proposed document class
relevant expertise can participate
resources exist
external work is addressed
maintenance is feasible
public-interest risks are manageable

10.6 New Work Decision

Possible outcomes:

Approve
approve as research
approve as provisional
revise proposal
combine with existing project
refer externally
defer
reject

10.7 Appeal

A new-work rejection may receive procedural review but does not create a right to compel Standards Body to undertake the project.

11. Project Classification

11.1 Standards Maturity

Classify using:

S0 research question
S1 research method
S2 recommended practice
S3 pilot specification
S4 consensus standard
S5 assurance-ready standard
S6 recognition candidate

11.2 Consequence Level

C0 minimal
C1 limited
C2 material
C3 high
C4 critical

11.3 Sensitivity

Public
controlled
confidential
restricted
highly restricted

11.4 International Scope

Internal
sectoral
national relevance
multi-jurisdictional
international candidate

11.5 Assurance Intent

No conformity assessment
self-assessment
second-party assessment
third-party assessment
certification candidate
regulatory support candidate

11.6 Classification Effect

Classification determines:

Review
participation
pilot burden
public-comment duration
approval threshold
maintenance cadence
security
appeal

12. Project Charter

12.1 Charter Purpose

The charter controls scope, authority, participation, and deliverables.

12.2 Charter Contents

Project identifier
title
purpose
problem
deliverable
scope
exclusions
intended users
affected parties
dependencies
normative intent
evidence maturity
assurance intent
parent committee
working group
chair
editor
membership categories
balance
decision method
security
intellectual property
milestones
public review
maintenance
sunset
appeal

12.3 Charter Approval

The Standards Council approves the charter.

Technical and public-interest bodies may require conditions.

12.4 Charter Change

A material scope change requires:

Proposed amendment
impact review
participant notice
approval
updated public record

12.5 Scope Creep

The chair and Secretariat should prevent requirements outside the charter.

12.6 Split Project

A project may be split when:

Different maturity levels apply
distinct communities are affected
one component delays another
security differs
consensus differs

13. Stakeholder and Interest Mapping

13.1 Purpose

Stakeholder mapping identifies who:

Implements
evaluates
bears cost
receives benefit
experiences harm
regulates
researches
depends on interoperability

13.2 Interest Categories

Possible categories:

Developers and providers
deployers and operators
users
affected non-users
evaluators
certification and accreditation bodies
researchers
public-interest organizations
workers
consumers
governments
regulators
procurers
open-source communities
smaller enterprises
international and regional institutions

13.3 Interest Versus Expertise

A participant may possess both.

Record them separately.

13.4 Missing Interests

The working group should identify interests that are absent.

13.5 Participation Plan

For each category, define:

Role
outreach
voting status
support
confidentiality
potential conflict
expected contribution

13.6 Update

Update the stakeholder map when scope changes.

14. Working-Group Formation

14.1 Working Group

A working group is the primary drafting and technical deliberation body.

14.2 Membership

Membership should be open under defined eligibility and competence conditions.

14.3 Voting Members

Voting status may require:

Participation
conflict disclosure
orientation
attendance
substantive contribution
conduct compliance

14.4 Observers

Observers may:

Attend
comment
receive public materials

They may lack voting rights or protected access.

14.5 Liaisons

Liaisons represent formal relationships with external institutions.

14.6 Chair

The chair manages process.

The chair should not unilaterally determine content.

14.7 Vice Chair

Supports continuity and acts during conflicts or absence.

14.8 Editor

The editor maintains the document and issue log.

14.9 Secretariat

The Secretariat supports:

Meetings
records
ballots
comments
publication
process compliance

14.10 Balance Review

Before substantive drafting, review composition for:

Dominance
missing categories
geographic concentration
resource imbalance
language
conflicts

14.11 Participation Support

Provide:

Remote meetings
stipends where possible
translation
accessible formats
orientation
technical assistance

14.12 Removal

A participant may be removed for:

Misconduct
confidentiality breach
repeated bad-faith obstruction
undisclosed conflict
inactivity where voting status requires participation

Use due process.

15. Participation, Balance, and Lack of Dominance

15.1 Balance Objective

Balance means that the process includes materially affected interests without allowing one category to control the outcome improperly.

15.2 Numerical Balance

Numerical balance can be useful.

It is not sufficient.

Five nominally independent participants funded by one actor may still constitute dominance.

15.3 Dominance Indicators

Majority of voting members
chair and editor control
agenda control
disproportionate attendance
model or data access control
funding dependence
coordinated voting
language advantage
ability to assign full-time staff
control of reference implementations
patent or intellectual-property leverage
threat of withdrawal

15.4 Dominance Review

The Secretariat and Standards Council should review dominance:

At formation
before committee draft
before public review
before approval
after a complaint

15.5 Corrective Measures

Recruit missing interests
add independent experts
limit affiliated voting
appoint a neutral chair
separate editor and sponsor roles
provide participation support
commission independent review
delay approval

15.6 Affiliation

Participants should disclose organizational and funding affiliations.

15.7 Coordinated Affiliates

Several participants under common control may be treated as one interest for balance analysis.

15.8 Open Participation

Open participation should not allow one organization to enroll unlimited affiliates to dominate.

15.9 Small-Actor Participation

Small actors may require:

Fee waivers
stipends
asynchronous participation
implementation support
shared legal and technical resources

15.10 Affected-Party Participation

Affected parties should influence:

Problem framing
risk and rights analysis
implementation burden
reporting
appeal

They should not be expected to provide specialist technical drafting without support.

16. Meetings and Deliberation

16.1 Meeting Notice

Provide:

Date
time
time zone
agenda
documents
participation method
confidentiality status

16.2 Global Scheduling

Rotate times for international groups.

16.3 Agenda Rights

Members should be able to propose agenda items.

16.4 Meeting Record

Record:

Attendance
conflicts
decisions
actions
objections
draft changes
votes
protected items

16.5 Asynchronous Deliberation

Use issue trackers, mailing lists, repositories, and written ballots to reduce geographic and scheduling barriers.

16.6 Deliberative Equality

Chairs should prevent:

Interruptions
harassment
repeated domination
private decisions presented as group decisions
exclusion through unexplained jargon

16.7 Closed Sessions

Closed sessions may be used for:

Held-out content
vulnerabilities
personal data
legal privilege
active incidents

A safe public summary should be provided where possible.

16.8 Informal Discussion

Informal work may support drafting.

Material decisions should return to the recorded process.

16.9 Meeting Accessibility

Provide reasonable accessibility and readable materials.

17. Evidence Development

17.1 Evidence Plan

The working group should maintain an evidence plan.

17.3 Source Quality

Apply EVIDENCE_STANDARDS.md.

17.4 Claim-Requirement Mapping

Each material requirement should map to:

Objective
evidence
risk or need
implementation
verification
uncertainty

17.5 Contrary Evidence

Maintain a contrary-evidence register.

17.6 Evidence Gaps

A gap may lead to:

Research requirement
nonnormative guidance
provisional status
narrower scope
withdrawal of requirement

17.7 Expert Judgment

Expert judgment should be:

Structured
conflict-aware
distinguishable from empirical evidence
documented
open to dissent

17.8 Confidential Evidence

A requirement may rely partly on confidential evidence only when:

Public evidence cannot safely support the need
qualified independent reviewers have access
the public rationale remains sufficiently understandable
the restriction is governed
the requirement is reviewable

17.9 Evidence Cutoff

The approval package should display the evidence current-through date.

17.10 Evidence Refresh

Refresh after:

Material new research
incident
protocol change
implementation failure
legal change
scheduled review

18. Requirements Engineering

18.1 Objective

Convert the identified need and evidence into clear, proportionate, implementable provisions.

18.2 Requirement Anatomy

A strong requirement identifies:

Responsible actor
required action or outcome
object
condition
timing
evidence
exception
relationship to other requirements

18.3 Requirement Types

Performance
process
management system
reporting
interface
security
competence
evaluation
lifecycle
outcome

18.4 Requirement Level

Baseline
enhanced
high-consequence
optional advanced
jurisdictional extension

18.5 Risk-Based Requirement

A risk-based requirement should define:

Risk assessment
decision owner
criteria
evidence
review
residual risk

18.6 Capability-Triggered Requirement

A capability trigger should define:

Construct
protocol
threshold
uncertainty
verification
resulting action
appeal

18.7 Process Requirement

A process requirement should not be treated as proof of outcome.

18.8 Outcome Requirement

An outcome requirement needs a valid method of assessment.

18.9 Documentation Requirement

Documentation should serve:

Implementation
evidence
accountability
continuity

Avoid documentation solely for audit appearance.

18.10 Proportionality

Assess:

Consequence
system scale
actor capacity
implementation cost
competition
alternatives
reversibility

18.11 Exceptions

Exceptions should be:

Defined
justified
documented
approved
time-limited where possible
reviewable

18.12 Equivalent Methods

Permit equivalent evidence when:

The objective is met
validity is demonstrated
interoperability remains sufficient
the standard does not require a unique interface

18.13 Requirement Test

Before inclusion, ask:

Is it necessary?
Is it understandable?
Is it implementable?
Is it verifiable?
Is it proportionate?
Is it evidence-supported?
Can it be gamed?
Can it be maintained?

19. Drafting Process

19.1 Working Drafts

Working drafts may be produced iteratively.

They have no approved standards status.

19.2 Draft Ownership

The working group owns substantive content within its charter.

The editor maintains form and approved changes.

19.3 Issue Tracker

Maintain a public or appropriately controlled issue tracker.

19.4 Draft Change Record

Record material changes and rationale.

19.5 Draft Structure

A standard should ordinarily include:

Foreword
introduction
scope
non-scope
normative references
terms and definitions
requirements
conformity or implementation provisions
annexes
bibliography
revision history

19.6 Scope Clause

The scope should identify:

Object
actors
lifecycle
domain
jurisdictional assumptions
intended use
excluded use

19.7 Normative References

A normative reference is required for implementation.

Use stable and accessible references where possible.

19.8 Informative References

Informative references support explanation but do not create required dependencies.

19.9 Definitions

Use TERMINOLOGY.md and TAXONOMY.md.

New definitions should be reviewed for cross-library consistency.

19.10 Notes and Examples

Notes and examples should not contain hidden requirements.

19.11 Annexes

Identify each annex as normative or informative.

19.12 Draft Quality Review

Review:

Technical consistency
normative language
cross-references
undefined terms
testability
accessibility
security
legal overclaim
public claims

20. Editorial Governance

20.1 Editor Role

The editor:

Incorporates approved changes
maintains structure
applies style
tracks issues
prepares publication files

20.2 Editor Limits

The editor may not silently:

Add requirements
remove agreed requirements
resolve substantive objections
alter thresholds
change scope
change normative force

20.3 Editorial Changes

Minor corrections may be accepted through a streamlined process.

20.4 Technical Editing

A technical editor may improve:

Precision
consistency
testability
cross-reference
machine readability

20.5 Legal Editing

Legal review may identify:

Unsupported legal claims
jurisdictional ambiguity
incorporation risk
intellectual-property issues

Legal review should not control technical substance beyond its role.

20.6 Plain-Language Review

Public-facing summaries should receive plain-language review.

20.7 Machine-Readable Artifacts

Schemas and code should be versioned with the text.

21. Intellectual Property and Licensing

21.1 Intellectual-Property Policy

A mature standards program should adopt a public intellectual-property policy before accepting formal technical contributions.

21.2 Contribution Rights

Contributors should grant sufficient rights for Standards Body to:

Reproduce
edit
publish
translate
maintain
archive
create machine-readable versions

21.3 Contributor Ownership

The policy should clarify whether contributors retain copyright in original contributions and which license applies.

21.4 Standards License

The public should understand:

Reading rights
implementation rights
quotation rights
redistribution rights
translation rights
derivative-profile rights

21.5 Open Access

Core public-interest standards should be freely readable.

21.6 Reference Implementations

Reference code should use a clear open-source or source-available license appropriate to interoperability and security.

21.7 Data and Task Rights

Evaluation tasks and datasets may need separate licensing and access controls.

21.8 Third-Party Material

Do not include third-party protected material without permission or applicable legal basis.

21.9 Brand and Mark

22. Patent and Essential-Claims Policy

22.1 Need

Technical standards can implicate patents.

A patent policy should exist before standards likely to require patented technology are approved.

22.2 Disclosure

Participants should disclose known patent claims that may be essential, subject to lawful policy.

22.3 Essential Claim

An essential claim is a patent claim that cannot be avoided in implementing a normative requirement without a technically and commercially reasonable alternative, as defined by the adopted policy.

22.4 Licensing Commitment

Possible approaches:

Royalty-free
reasonable and nondiscriminatory
exclusion of patented requirement
alternative implementation
case-specific commitment

W3C's patent policy seeks royalty-free implementation of its specifications, while other standards systems use different models.[^w3c-patent]

22.5 Neutrality

Standards Body should not adjudicate patent validity unless legally authorized.

22.6 Patent Search

Standards Body does not guarantee that all patents have been identified.

22.7 Conflict

Patent holders participating in drafting should disclose relevant interests.

22.8 Proprietary Lock-In

Avoid requirements that make one vendor's proprietary technology unavoidable when open or equivalent alternatives exist.

23. Security and Confidential Drafting

23.1 Open Baseline

Drafting should be open by default.

23.2 Protected Work

Protection may be necessary for:

Held-out evaluation tasks
vulnerabilities
exploit methods
biological or chemical details
system prompts
restricted model information
personal data
active incidents

23.3 Protected Annex

A standard may contain:

Public normative core
controlled implementation annex
restricted test annex
confidential evidence package

23.4 Public Accountability

The public document should explain:

Protected category
reason
governance
access criteria
review date
effect on implementation and review

23.5 Access

Use role-based access and chain of custody.

23.6 Restricted Participation

Participants in protected drafting should meet:

Need
competence
conflict
security
legal requirements

23.7 Independent Review

Restricted provisions require independent review by persons with sufficient access.

23.8 Compromise

Compromise may require:

Draft suspension
task replacement
security investigation
public notice
validity review
withdrawal

24. Prototype and Pilot Stage

24.1 Purpose

Piloting tests whether the draft works outside the drafting room.

24.2 Pilot Requirement

A high-consequence technical or assurance standard should ordinarily receive a pilot before final approval.

24.3 Pilot Participants

Seek variation in:

Organization size
system type
region
technical architecture
evaluator
resource level
open and closed systems

24.4 Pilot Questions

Can implementers understand the standard?
Can they produce the required evidence?
Do evaluators agree?
Which requirements are ambiguous?
What does implementation cost?
Which actors are excluded?
Does the standard reduce the target problem?
Can it be gamed?
Does it create unexpected risk?

24.5 Reference Implementation

For interface or data standards, build or test a reference implementation where feasible.

IETF's longstanding emphasis on open process, technical competence, rough consensus, and running code illustrates the value of implementation evidence in technical standardization.[^ietf-process]

24.6 Pilot Evidence

Preserve:

Implementation records
deviations
costs
evaluator findings
incidents
participant feedback
unresolved issues

24.7 Pilot Status

A pilot does not establish conformity or approval unless explicitly defined.

24.8 Pilot Failure

Failure may lead to:

Revision
narrower scope
guidance rather than standard
further research
termination

25. Committee Draft

25.1 Readiness

A working draft may become a committee draft when:

Scope is stable
normative provisions are identified
major evidence is available
pilot plan or evidence exists
conflicts are disclosed
the working group supports advancement

25.2 Advancement Package

Include:

Draft
change log
evidence map
implementation evidence
balance report
substantial objections
security status
public-interest review
editor report

25.3 Approval

The working group approves advancement according to its charter.

25.4 Committee-Draft Label

The document should state that it is not an approved standard.

25.5 Multiple Committee Drafts

A project may produce several committee drafts.

25.6 External Review Before Public Review

High-consequence drafts should receive independent technical or methodological review before public release.

26. Public Review

26.1 Purpose

Public review permits interested persons to examine and challenge the draft before approval.

26.2 Notice

The public notice should state:

Project
document class
scope
status
review period
access
comment method
related materials
confidentiality limits
contact
next stage

26.3 Review Period

Recommended minimum periods:

First public review: 45 days
Subsequent substantive review: 30 days
Narrow correction: 15 days
Urgent provisional draft: 15 days, followed by a fuller review after publication

The Standards Council may approve a different period with reasons.

26.4 Extended Review

Use 60 to 90 days when:

The document is complex
implementation consequences are high
translation is needed
international consultation is expected
legal incorporation is plausible
holidays materially reduce access

26.5 Draft Access

The public-review draft should be freely accessible during review.

26.6 Supporting Materials

Publish where safe:

Evidence map
issue list
pilot report
impact assessment
implementation examples
known dissent
comparison to external standards

26.7 Comment Channels

Support:

Structured form
email
repository issue
formal submission
accessible alternative

26.8 Commenter Information

Request:

Name
affiliation
interest
clause
comment
rationale
proposed change
confidentiality request

Anonymous comments may be considered when sufficiently specific.

26.9 Public Comment Status

Comments should ordinarily be public.

Protected submissions may be accepted for:

Security
personal data
confidential implementation evidence
whistleblowing
legal restriction

26.10 Outreach

Directly notify:

Known affected groups
relevant standards bodies
regulators
public-interest organizations
evaluators
developers
regional partners
smaller-actor networks

26.11 Public Hearing

A hearing or workshop may supplement written review.

It should not replace written comments and records.

27. Comment Management

27.1 Comment Register

Assign each comment:

Identifier
source
clause
category
proposed action
status
response
responsible person

27.3 Duplicate Comments

Similar comments may be grouped.

Do not use grouping to hide the scale or diversity of concern.

27.4 Comment Response

A response should state:

Accepted
accepted with modification
partly accepted
rejected
deferred
outside scope

and explain why.

27.5 Material Comment

A comment is material when it may change:

Scope
requirement
threshold
rights effect
implementation cost
security
conformity assessment
legal interpretation
consensus

27.6 Protected Comment

A protected comment should receive the same substantive consideration as a public comment.

27.7 Response Publication

Publish the comment-disposition report, subject to redaction.

27.8 Commenter Notification

Notify commenters of disposition and appeal rights where applicable.

27.9 Unresolved Objection

A commenter may identify the response as unresolved.

The working group should determine whether it is a substantial objection.

28. Substantial Objections

28.1 Criteria

A substantial objection should be:

Specific
relevant
reasoned
material to the standard or process
supported where possible

28.2 Grounds

Technical invalidity
insufficient evidence
severe safety concern
rights concern
disproportionate burden
anticompetitive effect
incompatibility
legal overclaim
lack of balance
procedural exclusion
security weakness
impossible conformity assessment

28.3 Response Duty

The working group should:

acknowledge the objection;
understand its basis;
examine evidence;
attempt resolution;
document changes;
preserve unresolved elements;
notify the objector.

28.4 Resolution Methods

Change draft
clarify
add alternative method
narrow scope
create profile
add safeguard
obtain more evidence
defer provision
preserve dissent
reject with reasons

28.5 No Veto

A substantial objection does not automatically create a veto.

28.6 No Dismissal by Minority Status

An objection is not weak merely because few participants support it.

28.7 Unresolved Objector

An unresolved objector should receive notice of procedural appeal rights.

ANSI's standards process similarly requires unresolved objectors to be notified of appeal rights.[^ansi-appeal]

28.8 Objection Register

Preserve unresolved objections with the standard's approval package.

29. Consensus Determination

29.1 Responsibility

The working group assesses technical consensus.

The Standards Council verifies the process and makes the formal consensus determination within its authority.

29.2 Consensus Evidence

Consider:

Participation balance
voting or polling
substantial objections
response quality
implementation evidence
public comments
independent review
affected-party concerns
international reservations
meeting and issue records

29.3 Consensus Indicators

Broad support across interest categories
no unaddressed critical objection
reasoned resolution
implementation feasibility
acceptance of remaining limitations

29.4 Consensus Failure

Consensus is not established when:

One category dominates
material evidence was unavailable
critical objections were ignored
participants lacked notice
the draft changed substantially without review
protected information prevented adequate independent challenge
voting was manipulated

29.5 Polls

Informal polls may identify direction.

They do not replace the final consensus assessment.

29.6 Consensus Call

The chair may issue a formal consensus call.

It should state:

Question
draft version
response period
options
objection process
record

29.7 Consensus Report

The chair and Secretariat should prepare:

Participation
support
objections
changes
unresolved issues
chair assessment
editor confirmation
minority statement

29.8 Council Review

The Standards Council may:

Confirm consensus
require further work
require new public review
approve nonconsensus publication status
discontinue

30. Voting

30.1 Role of Voting

Voting may:

Approve milestones
confirm membership decisions
resolve procedural matters
support consensus evidence
approve a standard where procedures permit

30.2 Voting Is Not Consensus by Itself

A high positive percentage does not cure:

Dominance
exclusion
ignored objection
invalid evidence

30.3 Eligible Voters

Voting eligibility should be based on:

Defined membership
conflict compliance
participation
affiliation controls
role

30.4 One Organization, Multiple Participants

Affiliated participants may contribute.

Voting rules should prevent one organization from multiplying control.

30.5 Working-Group Advancement

Recommended default:

At least two-thirds of eligible votes cast support advancement
and no unresolved critical process defect exists

The charter may use a different rule.

30.6 Final Standards Ballot

Recommended default:

At least two-thirds of eligible unconflicted voters support approval
less than one-quarter oppose
quorum and balance are met
consensus is separately determined

30.7 Abstention

An abstention is not support or opposition.

30.8 Nonresponse

Nonresponse should not automatically count as approval.

30.9 Written Ballot

Final ballots should ordinarily be written and recorded.

30.10 Ballot Comments

Negative votes should include reasons.

A negative vote without reason may remain recorded but cannot always be resolved.

30.11 Recirculation

Material changes made after ballot should be recirculated.

31. Recirculation and Additional Review

31.1 Material Change

A material change affects:

Scope
normative requirement
threshold
conformance
implementation burden
rights
security
legal effect
interoperability

31.2 Recirculation Requirement

Material changes after public review should receive additional review.

31.3 Review Scope

The additional review may be limited to changed sections if:

Context remains understandable
dependencies are included
the Standards Council approves

31.4 Nonmaterial Change

Editorial and clarifying changes may not require new public review.

31.5 Materiality Decision

The chair proposes.

The Secretariat and Standards Council review.

31.6 Disputed Materiality

A participant may appeal a refusal to recirculate a material change.

32. Independent Review

32.1 Purpose

Independent review challenges the standard beyond the drafting group.

32.2 Required Review

C3 and C4 standards should ordinarily receive independent review.

S5 assurance-ready standards should receive:

Technical review
conformity-assessment review
public-interest review
implementation review

32.3 Reviewer Selection

Use:

Competence
independence
access
conflict disclosure
diversity of method
no result-dependent compensation

32.4 Review Scope

Need
construct
evidence
normative requirements
testability
implementation
security
public claims
competition
maintenance

32.5 Reviewed-Party Response

The working group responds to findings.

32.6 Reviewer Dissent

Publish or preserve material dissent.

32.7 Confidential Review

Reviewers may receive protected evidence under controls.

32.8 Review Status

State whether review was:

Limited
full
technical
methodological
legal
security
public-interest
conformity-assessment

32.9 No Prestige Substitute

A famous reviewer does not replace a defined mandate and method.

33. Public-Interest and Rights Review

33.1 Trigger

Required for standards that may affect:

Rights
employment
public services
health
critical infrastructure
access
competition
vulnerable populations
public surveillance
information ecosystems

33.2 Assessment

Examine:

Benefits
harms
burden
distribution
accessibility
discrimination
privacy
due process
labor
market concentration
environment
international inequality

33.3 Alternatives

Consider whether a less restrictive or less burdensome standard could achieve the objective.

33.4 Affected-Party Evidence

Include direct evidence where possible.

33.5 Council Opinion

The Public Interest and Rights Council may:

Support
support with conditions
require reconsideration
issue dissent
recommend no approval

33.6 Record

Publish the opinion and response where safe.

34. Competition and Market Review

34.1 Purpose

Standards can shape market access.

34.2 Review Questions

Does the standard favor incumbents?
Does it require proprietary technology?
Can equivalent methods comply?
Are costs proportionate?
Can small organizations implement it?
Does it create evaluator concentration?
Does it tie compliance to membership?
Does it create patent lock-in?
Does it conflict with open-source distribution?

34.3 Competition Controls

Performance-based requirements
equivalent-method pathways
open schemas
public reference implementations
reduced fees
shared infrastructure
modular profiles
transition periods

34.4 No Protection of Business Model

A standard should not protect Standards Body's own services or partner revenues.

34.5 Review Record

Include competition findings in the approval package.

35. International and Coherence Review

35.1 Existing Standards Search

Before approval, review:

ISO and IEC
IEEE
ITU
IETF
W3C
OASIS
CEN, CENELEC, and ETSI
national standards
sector standards
regulatory technical standards
public frameworks

35.2 Coherence Decision

Determine whether to:

Adopt
reference
profile
extend
map
collaborate
proceed independently with reasons

35.3 International Participation

Invite relevant cross-regional institutions.

35.4 National Differences

Preserve legitimate local extensions.

35.5 Translation

Translate key public-review material for international candidates where resources permit.

35.6 International Standard Claim

Do not call a document an international standard merely because participants come from several countries.

The WTO principles require meaningful opportunities for relevant bodies across members and avoidance of privilege for particular suppliers, countries, or regions.[^wto-principles]

35.7 Formal Liaison

A liaison should have an authorized mandate.

36. Security Review

36.1 Trigger

Required when the standard concerns:

Held-out evaluation
cyber capabilities
biological or chemical risks
system vulnerabilities
controlled model access
incident exchange
sensitive infrastructure
personal data

36.2 Questions

What information may create harm?
Which implementation details must remain protected?
Can conformity be demonstrated securely?
Can external participants review sufficiently?
Does the standard expose safeguards?
What happens after compromise?

36.3 Security Annex

Use protected annexes where appropriate.

36.4 Public Minimum

Publish enough for:

Understanding
implementation eligibility
governance
appeal
claim limits

36.5 Security Approval

The Security Committee should approve restrictions, not the technical content as a whole.

37. Conformity-Assessment Readiness

37.1 Separate Decision

Approval as a standard does not establish readiness for conformity assessment.

37.2 Readiness Questions

Is the object defined?
Are requirements unambiguous?
Is evidence specified?
Are methods valid?
Can different evaluators agree?
Are competence requirements defined?
Are sampling and surveillance defined?
Are claims controlled?
Can status be suspended or withdrawn?
Are appeals possible?

37.3 Assurance Categories

Self-assessment
second-party assessment
third-party evaluation
audit
inspection
certification

37.4 Conformity Annex

An assurance-ready standard should include or reference:

Conformity criteria
evidence
assessment method
sampling
decision rules
reporting
nonconformity
surveillance
status
appeal

37.5 Accreditation Scope

If external accreditation is contemplated, define the competence scope precisely.

37.6 False Assurance Risk

Do not create an assurance scheme where conformance can be achieved through paperwork without meaningful outcomes.

38. Approval Package

38.1 Required Contents

The final package should include:

Final draft
project charter
need statement
evidence map
stakeholder and balance report
meeting and ballot records
pilot and implementation evidence
public comments
comment disposition
substantial objections
consensus report
independent reviews
public-interest opinion
competition review
international review
security review
conformity-assessment readiness
implementation plan
maintenance plan
intellectual-property statement
appeals status

38.2 Completeness Check

The Secretariat performs a process-completeness check.

38.3 Technical Recommendation

The working group recommends approval.

38.4 Council Decision

The Standards Council determines:

Process compliance
consensus
document status
remaining conditions

38.5 Higher Review

The Governing Board should not ordinarily approve individual technical standards.

Board approval may be required where:

The institution is entering a new authority stage
the standard creates major financial or legal risk
certification or public-law recognition is implicated
the governance framework reserves the decision

39. Approval Outcomes

39.1 Approve

The standard meets the process.

39.2 Approve With Conditions

Conditions may concern:

Effective date
pilot
implementation guidance
security
review
public claims
missing translation

39.3 Provisional Approval

Use when urgent implementation is justified but evidence or consensus remains incomplete.

39.4 Return for Revision

Material issues remain.

39.5 Publish as Guidance

The content is useful but not ready for standards status.

39.6 Defer

Await:

Evidence
external standard
legal change
implementation
resources

39.7 Reject

The project should not advance.

39.8 Discontinue

No further active work is planned.

39.9 Approval Record

Publish reasons and status.

40. Appeals

40.1 Appeal Scope

Appeals concern procedural due process and authority.

They may address whether a technical issue received fair consideration.

They do not allow the Appeals Panel to replace the technical committee merely because it prefers a different technical outcome.

40.2 Eligible Grounds

Lack of notice
exclusion
dominance
conflict
failure to consider comment
improper consensus determination
material change without recirculation
lack of authority
security overclassification
unequal treatment
failure to follow procedure

40.3 Internal Resolution

First seek resolution within:

Working group
Standards Council

40.4 Independent Appeal

Unresolved procedural appeals go to the Appeals and Review Panel.

40.5 Interim Status

Approval may be paused when the appeal could materially affect validity.

40.6 Appeal Record

Publish a reasoned decision or safe summary.

40.7 External Rights

Internal appeal does not replace legal or contractual rights.

41. Publication

41.1 Publication Authority

The Standards Council authorizes publication after approval and resolution of eligible appeals.

41.2 Publication Package

Publish:

Standard
identifier
version
approval date
effective date
status
scope
normative status
public claims
implementation resources
comment-disposition summary
unresolved dissent
maintenance owner
review date
correction channel

41.3 Stable Identifier

Each standard should receive a persistent identifier.

Preferred pattern:

SB-STD-[DOMAIN]-[YEAR]-[SEQUENCE]

41.4 Version

Use semantic or controlled edition numbering.

41.5 Effective Date

The effective date may follow publication to permit transition.

41.6 Free Public Access

Core standards should be freely readable.

41.7 Machine-Readable Publication

Publish where relevant:

JSON Schema
JSON-LD
XML
YAML
controlled vocabularies
test code
reference implementations

41.8 Accessible Format

Provide accessible HTML and downloadable formats.

41.9 Citation

Provide a canonical citation.

41.10 Public Summary

Explain:

Problem
requirements
intended users
limitations
status
nonclaims

41.11 Protected Components

Explain how qualified implementers or evaluators may access controlled components.

41.12 Publication Archive

Preserve all public versions.

42. Status and Claims

42.1 Status Labels

Research draft
working draft
committee draft
public-review draft
provisional specification
approved standard
confirmed standard
amended standard
superseded standard
withdrawn standard
retired standard

42.2 Accurate Use

Every public page and file should display current status.

42.3 Approved Standards Body Standard

This label means only that the document completed the approved Standards Body process.

42.4 Conformity Claim

An organization may claim conformity only when:

The relevant version is identified
scope is identified
evidence exists
the claim follows the standard
any assessment party is identified

42.5 Prohibited Claims

Unless separately established, prohibit:

Officially safe
government approved
regulator certified
globally certified
internationally approved
accredited by Standards Body
guaranteed compliant
risk free

42.6 Membership Claim

Membership does not establish conformity.

42.7 Participation Claim

Participation in drafting does not establish endorsement.

42.8 Pilot Claim

Pilot participation does not establish certification.

42.9 Registry Verification

Where a claim depends on current status, provide a public registry.

43. Implementation

43.1 Implementation Plan

The standard should define:

Intended implementers
prerequisites
transition
dependencies
evidence
support
monitoring
review

43.2 Implementation Guide

Provide nonnormative guidance where useful.

43.3 Reference Artifacts

Possible artifacts:

Templates
schemas
checklists
sample reports
code
test data
mappings
decision records

43.4 Training

Training may support adoption.

Completion of Standards Body training should not be required where equivalent competence exists unless justified.

43.5 Help Desk

A support channel may answer implementation questions.

Responses that change normative meaning should enter the formal interpretation process.

43.6 Implementation Community

Create forums for:

Questions
examples
issue reporting
translation
interoperability
feedback

43.7 Small-Actor Support

Provide:

Simplified guidance
shared infrastructure
open tools
phased implementation
reduced fees
technical assistance

43.8 Implementation Data

Collect:

Adoption
cost
ambiguity
nonconformity
evaluator disagreement
unintended effects
innovation
burden

43.9 No Adoption Theater

Adoption should not be measured solely by downloads, signatures, or public pledges.

44. Adoption and External Use

44.1 Voluntary Adoption

Organizations may voluntarily adopt a standard.

44.2 Contractual Adoption

A contract may incorporate the standard.

The contract should identify:

Version
scope
evidence
remedies
update rules

44.3 Procurement Adoption

A purchaser may require conformity.

Procurement should permit equivalent evidence where appropriate.

44.4 Certification Adoption

A certification scheme may use the standard if assurance readiness is established.

44.5 Regulatory Adoption

A regulator or legislature may:

Reference
incorporate
recognize
adapt
require

the standard through its own authority.

44.6 Presumption of Conformity

Standards Body cannot create a legal presumption of conformity by itself.

In the European Union, harmonized standards referenced in the Official Journal can support presumption of conformity under applicable legislation, illustrating how legal effect arises from the public legal framework rather than standards publication alone.[^eu-ai-standardisation]

44.7 Government Relationship

When public authorities consider adoption, Standards Body should provide:

Current version
evidence
limitations
maintenance
implementation
dissent
transition
international mappings

44.8 Dynamic Incorporation Risk

Automatic incorporation of future revisions can create accountability and delegation concerns.

External authorities should determine how updates take effect.

44.9 Legal Review

Standards Body should obtain qualified review before representing legal effect.

45. Interpretation

45.1 Purpose

An interpretation clarifies existing meaning.

It does not create a new requirement.

45.2 Request

An interpretation request should identify:

Standard
version
clause
question
implementation context
urgency

45.3 Screening

Determine whether the request is:

Editorial
implementation support
formal interpretation
amendment request
dispute
outside scope

45.4 Authority

The responsible maintenance group prepares interpretations.

The Standards Council approves formal interpretations.

45.5 Process

Review original intent
inspect records
examine implementation
assess legal and technical effect
check whether the answer changes requirements
publish response

45.6 No Hidden Amendment

If the answer changes normative meaning, use amendment or revision.

45.7 Interpretation Status

Interpretations should display:

Identifier
date
version
authority
status
affected clause

45.8 Conformity Effect

A formal interpretation may affect future conformity decisions.

Transition should be provided where reliance existed.

46. Errata and Corrections

46.1 Erratum

An erratum corrects a clear error without changing intended normative substance.

46.2 Types

Typographical
cross-reference
formatting
schema
example
translation
technical editorial
substantive correction

46.3 Editorial Errata

May use a streamlined approval process.

46.4 Substantive Correction

A change affecting normative meaning requires amendment or revision.

46.5 Errata Register

Publish:

Standard
clause
error
correction
date
status
incorporated version

46.6 Urgent Correction

A safety- or security-relevant error may require:

Immediate warning
temporary suspension
corrected edition
implementation notice
re-evaluation

46.7 No Silent Replacement

Preserve the original version and visible correction.

47. Amendment

47.1 Purpose

An amendment changes a bounded part of an approved standard.

47.2 Amendment Proposal

Include:

Clauses
reason
evidence
implementation impact
conformity impact
security
transition
public-review need

47.3 Process

A substantive amendment should ordinarily receive:

Working-group review
public review
comment disposition
consensus
approval
appeals

47.4 Combined Text

Publish a consolidated edition or clearly link the amendment.

47.5 Versioning

Amendments should update the version.

47.6 Compatibility

State whether the amendment is:

Backward compatible
conditionally compatible
breaking

48. Revision

48.1 Revision Trigger

Scheduled review
new evidence
incident
implementation failure
legal change
technology change
interoperability need
accumulated amendments
obsolete terminology
assurance failure

48.2 Revision Scope

A revision may replace the complete standard.

48.3 Process

A major revision should follow the full standards process proportionate to changes.

48.4 Bridge

Provide:

Change summary
clause mapping
migration
evidence
compatibility
effective date
treatment of prior conformity

48.5 Existing Certificates or Claims

A new version does not automatically invalidate prior certificates or claims.

The scheme or adopting authority should define transition.

48.6 Revision History

Preserve all editions.

49. Systematic Review of Standards

49.1 Review Cycle

Suggested default:

Frontier technical and evaluation standards: every one to three years
Stable terminology and infrastructure standards: every three to five years
Provisional specifications: every six to twelve months
Incident-triggered review: immediate as appropriate

49.2 Review Questions

Does the need remain?
Is the evidence current?
Is the construct valid?
Is the standard implemented?
Are requirements effective?
Are there incidents?
Is the burden proportionate?
Is the market distorted?
Are external standards available?
Is conformity consistent?
Does the standard remain secure?
Should it be confirmed, revised, or withdrawn?

49.3 Public Input

Request implementation and review evidence.

49.4 Outcomes

Confirm
amend
revise
split
merge
supersede
withdraw
retire

49.5 Confirmation

Confirmation should not be automatic after silence.

49.6 Review Record

Publish the evidence and decision.

50. Supersession, Withdrawal, and Retirement

50.1 Supersession

A new standard or version replaces the prior one.

50.2 Withdrawal

Approval ends because:

The standard is invalid
obsolete
harmful
compromised
duplicative
unsupported
impossible to maintain

50.3 Retirement

Active maintenance ends.

A retired standard may remain historically relevant.

50.4 Withdrawal Proposal

May arise from:

Maintenance group
Standards Council
incident
appeal
external standard
public authority
implementer

50.5 Due Process

Where organizations rely on the standard, provide:

Notice
reasons
comment
transition
appeal

unless urgent harm requires immediate suspension.

50.6 Suspension

Temporarily suspend status when:

Integrity is compromised
a serious error is under investigation
security is breached
governance is invalid

50.7 Registry

Update status immediately.

50.8 Public Claims

Organizations should stop making current-conformity claims after withdrawal according to the transition rule.

51. Urgent and Provisional Standards

51.1 Purpose

A provisional specification may address urgent coordination or safety needs before the full evidence and consensus process is complete.

51.2 Eligibility

Use only when:

Delay creates material risk or fragmentation
a bounded stable core exists
uncertainty can be disclosed
implementation can be monitored
expiration is defined

51.3 Required Controls

Explicit provisional label
evidence and uncertainty
limited scope
rapid independent review
public comment
expiration
monitoring
no broad certification
full-review plan

51.4 Approval

The Standards Council may approve under an urgent process.

C4 matters may require additional governance review.

51.5 Duration

Recommended maximum:

Twelve months without formal renewal

51.6 Renewal

Renewal requires evidence and public review.

51.7 Transition

A provisional specification may become:

Consensus standard
recommended practice
revised provisional specification
withdrawn

51.8 No Permanent Provisional Status

Repeated renewal should trigger governance review.

52. Fast-Track and Adoption of External Standards

52.1 Fast-Track Purpose

Avoid duplicating mature external work.

52.2 Eligible External Document

Consider:

Process quality
technical relevance
access
licensing
evidence
participation
implementation
maintenance
interoperability
public-interest impact

52.3 Adoption Types

Normative reference
endorsement
profile
republication by permission
local adoption
crosswalk
joint standard

52.4 Fast-Track Process

Proposal
external-process assessment
gap analysis
public review
local requirements
approval
maintenance and update linkage

52.5 No Blind Adoption

Prestige of the external organization is not enough.

52.6 External Change

Define how later external revisions affect the Standards Body adoption.

52.7 Withdrawal

If the external source is withdrawn or materially changed, review promptly.

53. Joint Standards Development

53.1 Purpose

Standards Body may develop work jointly with another institution.

53.2 Agreement

Define:

Scope
governance
decision rules
branding
intellectual property
publication
comments
appeals
security
maintenance
withdrawal
conflict resolution

53.3 Equal Process

The joint process should meet the stronger applicable due-process requirement.

53.4 Authority Claims

State which organization approved the document and under which process.

53.5 Joint Maintenance

Assign ownership and update procedure.

53.6 Failure

Define what happens if the partners disagree or withdraw.

54. International Standards Candidate Process

54.1 Candidate Status

A Standards Body document may be classified as an international candidate only after demonstrating:

Cross-regional participation
open opportunity
no country or region dominance
multilingual or translation planning
development-dimension consideration
coherence review
international implementation
durable governance

54.2 National Bodies

Standards Body should cooperate with national standards bodies rather than claim to replace their representative role.

54.3 International Organization Path

Possible pathways:

Liaison
contribution
joint development
national adoption
regional adoption
submission to an established international process

54.4 Evidence Portability

International candidates should support:

Common metadata
local extensions
equivalence
recognition
translations
jurisdictional profiles

54.5 Reservations

Preserve regional or national reservations.

54.6 No Universal Claim

No document should be described as universally accepted.

55. Translation and Localization

55.1 Translation Status

Translations may be:

Official
approved
community
informative
machine-assisted
draft

55.2 Controlling Language

State which version controls if differences arise.

55.3 Translation Process

Qualified translator
technical review
terminology review
local review
public correction
version alignment

55.4 Normative Meaning

A translation intended for conformity should preserve normative force.

55.5 Localization

A local profile may adapt:

Law
institutions
terminology
examples
reporting
implementation

It should not silently weaken the common core.

55.6 Translation Equity

Do not require all participation to occur only in one language where an international process claims broad reach.

56. Standards and Regulation

56.1 Distinction

A voluntary standard and a binding regulation are distinct.

56.2 Regulatory Request

A public authority may request standards work.

The request should be public where lawful and should not eliminate the standards process.

56.3 Public Authority Participation

Government representatives may:

Provide legal context
observe
contribute technical expertise
identify public-policy needs

Their role should be documented.

56.4 Legal Alignment

A harmonized or regulatory-support standard should map clauses to legal requirements where appropriate.

56.5 Legal Review

Qualified legal review is required for legal claims.

56.6 Public Authority Decision

The authority determines whether the standard receives legal recognition.

56.7 Standards Independence

Standards Body should remain able to identify technical deficiencies even when a public authority requested the work.

56.8 Accelerated Legal Timelines

Regulatory deadlines should not justify false claims of consensus or validity.

CEN and CENELEC have used accelerated procedures for AI Act standards while retaining established procedural routes, illustrating the need to distinguish procedural acceleration from abandonment of standards controls.[^cen-ai-accelerate]

57. Standards and Conformity Assessment

57.1 Separation

Standards define criteria.

Conformity assessment determines whether criteria are fulfilled.

57.2 Scheme Development

A certification or assurance scheme needs more than a standard.

It needs:

Scheme rules
assessment methods
competence
decisions
surveillance
complaints
marks
status
withdrawal

57.3 Standards Body Role

Standards Body may develop standards and scheme concepts.

It should not claim certification or accreditation merely through publication.

57.4 Assessment Feedback

Conformity-assessment experience should inform revisions.

57.5 Auditor Participation

Auditors and certification bodies may contribute.

They should not dominate requirements that create demand for their services.

57.6 Accreditation Cooperation

Evaluator and conformity-assessment standards should support external accreditation systems where appropriate.

58. Standards and Evaluation Protocols

58.1 Dynamic Protocols

Protocol standards should incorporate:

Stable construct
versioned tasks
elicitation
scoring
security
bridge studies
expiration

58.2 Protected Tasks

The public standard may govern protected task banks without publishing exact content.

58.3 Protocol Change

Task and environment changes may use controlled protocol procedures without requiring full standards revision when the standard permits them.

58.4 Result Comparability

Define how results remain comparable across protocol versions.

58.5 Validation

Protocol standards should maintain a validity case.

58.6 Evaluator Discretion

Define where professional judgment is allowed and governed.

59. Standards and Open-Source Ecosystems

59.1 Open Participation

Open-source developers and maintainers should have pathways to participate.

59.2 Distributed Responsibility

Standards should account for:

Forks
downstream modifications
volunteer maintainers
distributors
deployers
package ecosystems

59.3 Access Requirements

Avoid requirements that assume privileged provider access when alternatives exist.

59.4 Reference Implementations

Open reference tools can reduce barriers.

59.5 Security

Open publication should not expose active dangerous details without review.

59.6 Licensing Compatibility

Assess whether required artifacts can be produced under common open-source licenses.

60. Standards and Small Organizations

60.1 Burden Assessment

Estimate:

Staff
legal
compute
security
evaluation
documentation
certification
recurring cost

60.2 Proportionate Pathways

Possible approaches:

Risk tiers
shared services
phased compliance
templates
sampling
pooled evaluation
open tools
grants

60.3 No Severe-Risk Exemption by Size

Small size alone should not waive a requirement necessary for severe risk.

60.4 Functional Equivalence

Permit valid alternate evidence.

60.5 Participation

Include small organizations before requirements are fixed.

61. Standards Process Quality Assurance

61.1 Process Quality

Standards quality depends on both:

Technical substance
Process integrity

61.2 Secretariat Checkpoints

The Secretariat should perform process checks at:

New-work proposal
charter approval
working-group formation
committee draft
public review
final ballot
publication
systematic review

61.3 Process Audit Questions

Was the project authorized?
Was scope controlled?
Was participation open?
Was balance reviewed?
Were conflicts disclosed?
Was evidence sufficient?
Were comments considered?
Were material changes recirculated?
Was consensus assessed?
Were appeals available?
Was maintenance assigned?
Were public claims accurate?

61.4 Independent Process Audit

A formal standards program should receive periodic external process audit.

61.5 Nonconformity

A process nonconformity may be:

Minor
material
critical

61.6 Critical Nonconformity

Examples:

Dominance
undisclosed controlling conflict
no public review
ignored critical objection
invalid vote
approval by unauthorized body
material change without recirculation
falsified record

61.7 Corrective Action

A nonconformity may require:

Record correction
renewed review
reballot
appeal
standard suspension
withdrawal
governance change

61.8 Process Integrity Statement

The publication package should include a statement of process completion.

62. Process Performance Metrics

62.1 Purpose

Metrics should improve the process rather than reward document volume.

62.2 Project Metrics

Time by stage
participation
balance
public comments
resolution time
objections
appeals
pilot implementations
independent reviews
revisions
maintenance burden

62.3 Participation Metrics

Interest categories
geography
organization size
attendance
voting participation
comment influence
stipend use
translation
accessibility

62.4 Quality Metrics

Requirement ambiguity
implementation variance
evaluator agreement
correction rate
incident relevance
external adoption
duplication
supersession speed

62.5 Outcome Metrics

Improved comparability
reduced evaluation disagreement
lower implementation error
improved incident learning
better interoperability
reduced assurance shopping
increased competent participation

62.6 Anti-Metric Rule

Do not optimize the process for:

Number of standards
speed alone
unanimous votes
number of members
public comments without influence
adoption without outcome evidence

62.7 Annual Standards Report

Publish:

Work program
stage movement
discontinued projects
participation
comments
appeals
corrections
maintenance
implementation evidence
process audit
improvements

63. Standards Process Maturity Model

Level 0: Informal Document Production

Characteristics:

No stable process
author-controlled outputs
no public review
no appeal
no maintenance

Level 1: Documented Drafting

Characteristics:

Scope
editor
version
internal review
public status label

Level 2: Open Working-Group Process

Characteristics:

Charter
participation
conflicts
issue tracking
committee drafts
public review

Level 3: Consensus and Due Process

Characteristics:

Balance
substantial-objection process
formal consensus
appeal
process audit
maintenance

Level 4: Evidence and Implementation Standardization

Characteristics:

Evidence maps
pilots
independent review
public-interest review
conformity readiness
international coherence

Level 5: Adaptive and Interoperable Standards Institution

Characteristics:

Dynamic standards
machine-readable artifacts
international mappings
incident feedback
rapid correction
measured outcomes
external recognition

63.1 Maturity Rule

Control:

Independent review and mandatory status triggers.

65. Serious Objections and Responses

Objection 1: Frontier AI changes too quickly for standards

Some details change too quickly.

Standards can still define stable infrastructure for:

Identity
evidence
process
metadata
governance
change control
evaluation integrity

Dynamic components should be versioned separately.

Objection 2: Consensus standards will be dominated by industry

Industry dominance is a real risk.

The process uses:

Constituency balance
public-interest review
conflict controls
public comment
independent review
participation support

Industry expertise remains necessary.

Objection 3: Open participation cannot work with sensitive AI evidence

Exact evidence may remain restricted.

The public process can still govern:

Construct
requirements
access criteria
review
status
appeal
limitations

Objection 4: Standards will become de facto regulation without democratic legitimacy

This can occur through procurement, market pressure, or legal reference.

Standards Body should preserve transparent process and bounded claims.

Public authorities remain responsible for democratic and legal adoption.

Objection 5: Public comment is too slow

Public review should be proportionate.

Urgent provisional routes can operate faster with expiration and later full review.

Objection 6: Small organizations cannot participate meaningfully

Participation support and modular implementation are required.

A process that is nominally open but practically inaccessible is not sufficiently open.

Objection 7: Consensus lets one objector block progress

Consensus is not unanimity.

The process requires serious consideration, not universal agreement.

Objection 8: Technical committees cannot represent the public interest

They should not claim to.

Public-interest governance should be a distinct institutional function.

Objection 9: A free standard is financially unsustainable

Funding may come from:

Grants
membership
training
infrastructure
services
sponsorship under independence rules

Core public access should remain protected.

Objection 10: Existing standards bodies should do all of this work

Existing bodies should be used where fit.

Standards Body should specialize where frontier evaluation infrastructure requires deeper or faster work and should contribute mature outputs into established systems where appropriate.

66. Implementation Pathway

Phase 1: Procedural Adoption

Adopt this process internally
label all current outputs accurately
establish work-program register
create proposal and charter templates
establish issue and version control

Phase 2: Pilot Working Group

Select one bounded specification
charter a balanced group
run evidence and drafting process
document conflicts and participation
publish a committee draft

Phase 3: Public Review Pilot

Run public notice
accept comments
publish dispositions
assess substantial objections
test appeal process

Phase 4: Implementation Pilot

Recruit varied implementers
collect evidence
test evaluator agreement
revise requirements
publish pilot report

Phase 5: Governance Readiness

Establish Standards Council
establish public-interest review
establish independent Appeals Panel
adopt intellectual-property policy
adopt security process

Phase 6: Formal Standards Program

Publish procedures
publish work program
form committees
conduct external process review
approve first formal Standards Body standard

Phase 7: Assurance Readiness

Develop conformity annexes
conduct evaluator proficiency
assess scheme and accreditation relationships
restrict public claims until mature

Phase 8: International Interoperability

Create crosswalks
establish liaisons
translate core documents
conduct multi-region implementation
consider contribution to established international bodies

67. First Standards Program Pilot

67.1 Proposed Pilot

Title: Frontier AI Evaluation Result and Evidence Reporting Specification

67.2 Purpose

Create a common, machine-readable and human-readable result profile covering:

System identity
protocol
evaluator
elicitation
task integrity
score
uncertainty
evidence level
review
status
expiration
correction

67.3 Why This Pilot

It is:

Foundational
lower risk than a safety certification
useful across institutions
linked to all eight foundations
suitable for public and protected evidence
capable of reference implementation
compatible with registry infrastructure

67.4 Participants

Frontier developers
independent evaluators
government evaluation institutes
researchers
standards experts
public-interest experts
open-source participants
international partners

67.5 Deliverables

Terminology
JSON schema
human-readable report
evidence passport
implementation guide
pilot report
interoperability mapping

67.6 Success Criteria

Multiple independent implementations
consistent interpretation
manageable burden
protected-evidence compatibility
public readability
international extensibility
correction and versioning

67.7 Nonclaims

The pilot would not:

Certify systems
accredit evaluators
determine safety
create legal compliance

68. Standards Development Scorecard

Dimension	Core question
Need	Is there a demonstrated problem requiring standardization?
Alternative	Is a standard preferable to research, guidance, law, or tooling?
Maturity	Is the evidence mature enough for the document class?
Scope	Is the project bounded and controlled?
Existing work	Has duplication been assessed?
Charter	Are authority, deliverables, and process defined?
Participation	Are relevant parties able to participate?
Balance	Is dominance prevented?
Competence	Does the group include the required expertise?
Public interest	Are affected parties and rights considered?
Evidence	Are requirements traceable to credible evidence?
Contrary evidence	Is dissenting evidence visible?
Drafting	Are normative provisions precise and testable?
Technology neutrality	Are unnecessary proprietary prescriptions avoided?
Intellectual property	Are contribution, license, and patent issues governed?
Security	Is sensitive information protected without blocking accountability?
Pilot	Has the standard been implemented or tested?
Public review	Was the draft available for meaningful review?
Comments	Were comments tracked and answered?
Objections	Were substantial objections addressed?
Consensus	Is consensus genuinely supported?
Voting	Were voting rights, affiliations, and thresholds valid?
Recirculation	Were material changes reviewed?
Independent review	Did qualified reviewers challenge the work?
Competition	Is market exclusion proportionate?
International	Is coherence and cross-border use addressed?
Conformity	Can requirements support consistent assessment if intended?
Approval	Is the approval package complete?
Claims	Are status and legal effect described accurately?
Access	Is the standard publicly and accessibly available?
Implementation	Are guidance and transition available?
Maintenance	Are owner, review, correction, and withdrawal defined?
Outcome	Does implementation improve the target problem?
Appeal	Is procedural review available?
Audit	Can the process be reconstructed and audited?

68.1 Critical Failures

The following normally prevent approval as a consensus standard:

No demonstrated need
undefined scope
no work-group charter
controlling dominance
no conflict disclosure
no public review
no comment disposition
ignored critical objection
no implementation evidence for a high-consequence standard
normative requirements that cannot be assessed
material change without recirculation
invalid consensus claim
no appeal
no maintenance owner
legal or certification claims beyond authority

68.2 No Composite Score

Do not average the scorecard into one overall rating.

A critical process failure should remain decisive.

69. New Work Proposal Template

Proposal ID:
Proposed title:
Proposer:
Date:
Document class:
Proposed maturity:
Consequence level:

Problem

Public-Interest or Coordination Need

Why Standardization Is Appropriate

Alternatives Considered

Proposed Scope

Non-Scope

Intended Users

Affected Parties

Evidence

Existing Standards and Work Programs

Technical Dependencies

Legal and Regulatory Context

Security and Confidentiality

Intellectual Property

Implementation and Pilot Plan

Conformity-Assessment Intent

International Relevance

Participation and Balance

Resources and Timeline

Maintenance

Conflicts

Requested Decision

70. Project Charter Template

Project ID:
Title:
Parent body:
Document class:
Version:
Effective date:

Purpose

Need

Deliverable

Scope

Exclusions

Intended Users

Affected Parties

Normative Intent

Evidence Maturity

Assurance Intent

Working Group

Chair

Vice Chair

Editor

Secretariat

Interest Categories

Balance Requirements

Participation Eligibility

Voting Eligibility

Decision Method

Conflict Rules

Security Classification

Intellectual-Property Policy

Milestones

Public Review

Appeals

Maintenance

Sunset

71. Stakeholder and Balance Matrix

Interest category	Need or impact	Participants	Voting share	Affiliations	Barriers	Support	Missing perspectives
Developers
Deployers
Evaluators
Public interest
Affected parties
Government
Small actors
International

Dominance Review

Largest organizational bloc:
Largest funding relationship:
Chair affiliation:
Editor affiliation:
Missing categories:
Corrective actions:
Review date:

72. Requirement Traceability Template

Requirement ID	Responsible actor	Objective	Risk or need	Evidence	Implementation	Conformity evidence	Exceptions	Related requirements

73. Working Draft Review Checklist

Before advancement, confirm:

Scope matches the charter.
document class is accurate.
normative and informative text are separated.
terms are defined.
requirements identify responsible actors.
requirements are necessary and proportionate.
assessment evidence is specified where intended.
external standards are considered.
intellectual-property issues are identified.
security-sensitive content is classified.
public-interest impacts are reviewed.
small-actor burden is assessed.
implementation evidence exists or is planned.
issues and dissent are recorded.
version and status are visible.

74. Public Review Notice Template

Project:
Draft:
Version:
Document status: Public-review draft
Review opens:
Review closes:
Responsible working group:

Purpose

Scope

Intended Use

Material Changes

Supporting Evidence

Known Limitations and Dissent

How to Comment

Comment Information Requested

Public and Confidential Comment Treatment

Accessibility and Translation

Next Stage

Contact

75. Public Comment Template

Commenter:
Affiliation:
Interest category:
Draft version:
Clause:
Comment type:

Editorial
technical
evidence
scope
rights
security
legal
implementation
interoperability
competition
process

Comment

Rationale and Evidence

Proposed Change

Confidentiality Request

Conflict Disclosure

76. Comment Disposition Template

Comment ID:
Draft:
Clause:
Commenter:
Responsible reviewer:

Comment Summary

Evidence

Disposition

Accepted
accepted with modification
partly accepted
rejected
deferred
outside scope
duplicate

Response

Draft Change

Substantial Objection Status

Commenter Notification

Appeal Information

77. Substantial Objection Template

Objection ID:
Objector:
Affiliation and interest:
Draft:
Date:

Provision or Process Challenged

Objection

Material Consequence

Evidence

Proposed Resolution

Working-Group Response

Changes

Remaining Disagreement

Final Status

Resolved
partly resolved
preserved as dissent
rejected with reasons
outside scope

Appeal Notice

78. Consensus Report Template

Project:
Draft version:
Chair:
Date:

Participation

Interest Balance

Conflicts and Recusals

Deliberation

Polls and Ballots

Public Comments

Substantial Objections

Changes Made

Independent Review

Public-Interest Opinion

Security Review

Unresolved Dissent

Chair's Consensus Assessment

Secretariat Process Assessment

Standards Council Determination

79. Pilot Implementation Record

Pilot ID:
Draft:
Implementer:
System or organization:
Region:
Date:

Implementation Scope

Resources

Requirements Implemented

Deviations

Evidence Produced

Ambiguities

Costs and Burden

Security Issues

Evaluator Findings

Unintended Effects

Suggested Changes

Public or Controlled Status

80. Independent Standards Review Template

Standard or draft:
Reviewer:
Qualifications:
Independence profile:
Access:
Date:

Mandate

Need and Scope

Evidence

Requirement Validity

Implementation and Testability

Conformity-Assessment Readiness

Public-Interest and Competition

Security

International Coherence

Maintenance

Material Findings

Required Changes

Dissent

Recommendation

Approve
approve with conditions
revise
return to research
do not approve

81. Approval Record Template

Standard ID:
Title:
Version:
Decision body:
Date:

Approval Authority

Approval Package

Quorum and Voting

Consensus Determination

Conflicts and Recusals

Public-Interest Review

Security Review

Independent Review

Unresolved Objections

Appeals

Decision

Approve
approve with conditions
provisional approval
revise
guidance only
defer
reject

Conditions

Effective Date

Review Date

Maintenance Owner

Public Claims

82. Interpretation Request Template

Request ID:
Standard and version:
Clause:
Requester:
Date:

Question

Implementation Context

Urgency

Existing Interpretations

Proposed Understanding

Potential Conformity Effect

Security or Confidentiality

Decision and Rationale

Status

83. Amendment or Revision Proposal Template

Proposal ID:
Standard:
Current version:
Proposer:
Date:

Trigger

Proposed Change

Reason

Evidence

Affected Requirements

Implementation Impact

Conformity Impact

Compatibility

Security

Legal and International Impact

Transition

Public Review

Requested Outcome

Erratum
amendment
revision
suspension
withdrawal

84. Systematic Review Record Template

Standard:
Version:
Review period:
Maintenance body:

Current Need

Adoption and Use

Implementation Evidence

Evaluation and Assurance Evidence

Incidents and Failures

Comments and Interpretations

External Standards

Legal and Technical Change

Burden and Competition

International Use

Security

Evidence Current-Through Date

Recommendation

Confirm
amend
revise
split
merge
supersede
withdraw
retire

Decision

Next Review

85. Withdrawal Notice Template

Standard:
Version:
Status:
Effective date:

Reason

Evidence

Immediate Risk

Replacement or Successor

Transition

Existing Claims

Certificates or Assessments

Registry Update

Appeal

86. Standards Process Audit Template

Audit period:
Auditor:
Independence:
Scope:

Work Program

New Work

Charters

Participation and Balance

Conflicts

Meetings and Records

Evidence

Drafting

Public Review

Comments

Consensus and Voting

Appeals

Approval

Publication

Maintenance

Security

Intellectual Property

Findings

Corrective Actions

Public Summary

87. Canonical Standards Body Standards-Development Positions

Standards Body adopts the following working positions.

Standards development is a public-interest institutional process, not document production alone.
A standard should respond to a demonstrated need.
Standardization is not always the correct response.
Research, guidance, specifications, standards, certification, accreditation, and regulation are distinct.
Evidence maturity should determine document maturity.
A document should not advance automatically through standards stages.
Standards should be returned to research when the construct or method remains weak.
Urgency may justify provisional status, not false certainty.
Every project should have a public identifier, status, owner, and charter.
Scope should be bounded before drafting.
Material scope expansion requires renewed authorization.
Relevant external standards should be identified before new work begins.
Standards Body should adopt, map, profile, or extend suitable external work rather than duplicate it unnecessarily.
Participation should be open to directly and materially interested parties under defined procedures.
Nominal openness is insufficient when participation barriers make influence inaccessible.
Balance concerns interests, influence, resources, and control, not only headcount.
Affiliated participants may be treated as one interest for dominance analysis.
No developer, evaluator, government, funder, country, or region should dominate an international-candidate process.
Competence and stakeholder interest should both be represented.
Affected parties should influence problem definition and impact analysis.
Public-interest review should be capable of changing the draft.
Working groups should be chartered and time-limited.
Chairs govern process, not substantive truth.
Editors may not change normative substance silently.
Material drafting changes should be recorded.
Requirements should identify responsible actors and observable evidence.
Undefined words such as adequate, robust, meaningful, and reasonable should not carry ungoverned normative weight.
Performance-based requirements are preferred when equivalent technical approaches can meet the objective.
Prescriptive requirements may be necessary for interoperability or severe-risk controls.
Documentation should support evidence and continuity, not compliance theater.
Equivalent methods should be permitted when they meet the objective credibly.
Normative and informative text should be clearly separated.
Intellectual-property and patent rules should be adopted before formal technical standards work requires them.
Core public-interest standards should be freely readable.
A public standard and protected evaluation annex may coexist.
Confidentiality does not establish validity.
Consequential restricted provisions require qualified independent review.
High-consequence standards should ordinarily be piloted before final approval.
Implementation evidence is part of standards evidence.
A reference implementation can support interoperability but does not define the only valid implementation unless the standard requires it.
A committee draft is not an approved standard.
Public-review drafts should be freely accessible during the review period.
The first public review should ordinarily remain open for at least 45 days.
Shortened review periods should be justified and disclosed.
Public comments should be tracked and answered.
Protected comments should receive substantive consideration.
Similar comments may be grouped but not hidden.
A substantial objection should receive a reasoned response.
A substantial objection does not automatically create a veto.
Minority status does not invalidate an objection.
Unresolved objectors should receive notice of procedural appeal rights.
Consensus is broad agreement after serious efforts to address substantial objections.
Consensus is not unanimity.
Consensus is not silence.
Consensus is not simple majority voting.
A positive ballot cannot cure dominance or due-process failure.
Material changes after review should be recirculated.
High-consequence and assurance-ready standards should receive independent review.
Public-interest, competition, international, security, and conformity-readiness reviews should remain distinguishable.
A standard may be technically approved while not assurance-ready.
The approval package should permit reconstruction of the process.
The Standards Council should determine process compliance and consensus within its authority.
The Governing Board should not ordinarily rewrite technical standards.
Approval as a Standards Body standard does not make a document legally binding.
Standards Body cannot create a legal presumption of conformity by itself.
Standards Body approval is not certification.
Standards Body should not initially certify systems or accredit evaluators.
Public claims should identify the standard version and scope.
Membership or drafting participation does not establish conformity or endorsement.
Standards should use persistent identifiers and visible status.
Public standards should be available in accessible human-readable formats.
Machine-readable artifacts should be versioned with the normative text.
Implementation support should not create hidden requirements.
Formal interpretations should clarify, not amend.
Material normative change requires amendment or revision.
Errors should not be corrected silently.
Frontier AI standards should have shorter review cycles where change warrants.
Confirmation should require evidence, not silence.
Standards should be suspended or withdrawn when validity, security, or governance fails.
Institutional reputation should not prevent withdrawal.
Provisional standards should expire automatically unless renewed through review.
Repeated provisional renewal should trigger governance review.
External standards may use fast-track adoption only after local process and impact review.
Joint standards require defined governance, intellectual property, maintenance, and appeals.
International candidate status requires meaningful cross-regional process, not merely multinational attendance.
Translation status and controlling language should be visible.
Local profiles should not silently weaken the common core.
Regulatory deadlines should not manufacture technical consensus.
The public authority determines the legal effect of a standard.
Conformity assessment requires scheme rules beyond the standard text.
Evaluators and auditors may contribute but should not design standards around self-created commercial demand.
Open-source and small-actor implementation should be considered from the beginning.
Small size should not waive controls necessary for severe risk.
Standards-process quality should be audited.
Process failures may require reballot, renewed review, suspension, or withdrawal.
Standards performance should be measured through outcomes, not document count.
A mature standards institution should publish discontinued work and failures.
Standards Body should contribute mature work to established standards systems when that better serves interoperability and legitimacy.
Standards Body should remain willing to decide that a proposed standard should not exist.
The ultimate test of a standard is whether it improves shared practice and evidence without creating greater error, exclusion, or false assurance.

88. Relationship to Other Canonical Files

`PROJECT_IDENTITY.md`

Defines the project's present stage, authority, and permitted public claims.

This process cannot transform a research project into a recognized standards body by declaration.

`PROJECT_MANIFESTO.md`

Defines the deeper purpose of creating credible frontier AI infrastructure.

`INSTITUTION_DESIGN.md`

Defines the organizational ecosystem and separation among standards, evaluation, certification, accreditation, and enforcement.

`GOVERNANCE_FRAMEWORK.md`

Defines the Standards Council, decision rights, voting, conflicts, appeals, transparency, and institutional transition.

`FOUNDATIONS.md`

Defines the eight foundations from which standards topics arise.

`FOUNDATIONS_APPENDIX.md`

Defines the integrated lifecycle connecting evaluation evidence to standards maturity.

`TERMINOLOGY.md`

Provides the controlled vocabulary for standards, requirements, consensus, assurance, and status.

`EVIDENCE_STANDARDS.md`

Defines the evidence levels and quality used to justify standards requirements.

`RESEARCH_METHODOLOGY.md`

Governs the preliminary research, pilots, implementation studies, and standards research.

`TAXONOMY.md`

Classifies document types, standards stages, requirements, actors, decisions, and statuses.

`EVALUATION_PHILOSOPHY.md`

Defines how evaluation methods should be interpreted before they become standardized.

`EVALUATOR_ACCREDITATION_FRAMEWORK.md`

Will define the competence and recognition system for evaluators using standards and protocols.

`CONTRIBUTOR_FRAMEWORK.md`

Will define contributor participation, conduct, credit, access, and removal.

`TRANSPARENCY_FRAMEWORK.md`

Will define public review, disclosure, protected comments, records, and access.

`PARTNERSHIP_PRINCIPLES.md`

Will govern joint standards work and liaison relationships.

`LONG_TERM_ROADMAP.md`

Will sequence the transition from research outputs to a formal standards-development program.

89. Final Standards-Development Position

Standards are among the most durable ways an institution can shape a technical field.

They can outlive:

The evidence that justified them
the people who drafted them
the systems they were designed for
the political moment that adopted them
the institution that published them

That durability makes standards valuable.

It also makes premature standards dangerous.

Frontier AI standards may influence:

Which capabilities are measured
which safeguards are required
which evidence becomes portable
which evaluators enter the market
which organizations can comply
which systems receive procurement access
which technical methods become legally recognized
which failures become visible
which uncertainties disappear from public view

The institution should therefore resist two temptations.

The first is to delay all standardization until complete certainty exists.

Complete certainty will not exist.

The second is to publish standards quickly to appear relevant.

Relevance without validity creates false assurance.

The correct process is progressive.

Research should remain research.

Promising methods should become recommended practices.

Tested methods should become pilot specifications.

Implemented and reviewed practices may become consensus standards.

Only precise and validated standards should support conformity assessment.

Only public authorities can determine legal effect.

Every stage should preserve:

Evidence
participation
dissent
version
status
review
correction
withdrawal

A credible standards process does not guarantee that every requirement is right.

It guarantees something more realistic and institutionally valuable:

The problem was defined.
Relevant interests could participate.
evidence was examined.
requirements were tested.
objections were considered.
decisions were recorded.
appeals were possible.
the standard will be maintained.
error can be corrected.

The defining standards-development rule of Standards Body is:

Standardize only what can be stated clearly, supported credibly, implemented practically, assessed fairly, challenged openly, and maintained responsibly.

References and Research Basis

[^iso-directives]: International Organization for Standardization and International Electrotechnical Commission, ISO/IEC Directives, Part 1, Procedures for the Technical Work, current consolidated edition. https://www.iso.org/sites/directives/current/consolidated/index.html

[^iso-part2]: International Organization for Standardization and International Electrotechnical Commission, ISO/IEC Directives, Part 2, Principles and Rules for the Structure and Drafting of ISO and IEC Documents. https://www.iso.org/sites/directives/current/part2/index.xhtml

[^ansi-essential]: American National Standards Institute, ANSI Essential Requirements: Due Process Requirements for American National Standards, current edition. https://www.ansi.org/american-national-standards/ans-introduction/essential-requirements

[^ansi-overview]: American National Standards Institute, American National Standards Process Overview. https://www.ansi.org/american-national-standards/ans-introduction/overview

[^ansi-appeal]: American National Standards Institute, Rights to Appeal in the American National Standards Process and approval-step guidance for unresolved objectors. https://www.ansi.org/american-national-standards/appeals

[^wto-principles]: World Trade Organization, Principles for the Development of International Standards, Guides and Recommendations, covering transparency, openness, impartiality and consensus, effectiveness and relevance, coherence, and the development dimension. https://www.wto.org/english/tratop_e/tbt_e/principles_standards_tbt_e.htm

[^wto-code]: World Trade Organization, Agreement on Technical Barriers to Trade, Annex 3, Code of Good Practice for the Preparation, Adoption and Application of Standards. https://www.wto.org/english/docs_e/legal_e/17-tbt_e.htm

[^cen-standards]: CEN and CENELEC, European Standards, describing consensus, openness, transparency, national commitment, and technical coherence. https://www.cencenelec.eu/european-standardization/european-standards/

[^cen-guide30]: CEN and CENELEC, Guide 30, European Guide on Standards and Regulation. https://www.cencenelec.eu/media/Guides/CEN-CLC/cenclcguide30.pdf

[^cen-ai-accelerate]: CEN and CENELEC, Update on the Decision to Accelerate Development of Standards for Artificial Intelligence, October 23, 2025. https://www.cencenelec.eu/news-events/news/2025/brief-news/2025-10-23-ai-standardization/

[^eu-ai-standardisation]: European Commission, Standardisation of the AI Act and Understanding the Standardisation of the AI Act, current through 2026. https://digital-strategy.ec.europa.eu/en/policies/ai-act-standardisation and https://digital-strategy.ec.europa.eu/en/faqs/understanding-standardisation-ai-act

[^ietf-process]: Internet Engineering Task Force, Guide to the IETF Standards Process, with BCP 9 and RFC 2026 process sources. https://www.ietf.org/process/process/

[^ietf-rfc]: Internet Engineering Task Force, About RFCs, including publication statuses, updates, obsolescence, and errata. https://www.ietf.org/process/rfcs/

[^w3c-process]: World Wide Web Consortium, W3C Process Document, August 18, 2025. https://www.w3.org/policies/process/

[^w3c-patent]: World Wide Web Consortium, W3C Patent Policy, May 15, 2025. https://www.w3.org/policies/patent-policy/

[^oasis-process]: OASIS Open, Technical Committee Process. https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26/

[^oasis-drafts]: OASIS Open, Committee Specification Drafts and Public Review, OASIS TC Handbook. https://docs.oasis-open.org/TChandbook/Reference/CommitteeSpecDrafts.html

[^nist-standards]: National Institute of Standards and Technology, Standards.gov and Standards Coordination Office. https://www.nist.gov/standardsgov

[^nist-ai-standards]: National Institute of Standards and Technology, AI Standards. https://www.nist.gov/artificial-intelligence/ai-standards

[^iso-certification]: International Organization for Standardization, Certification, clarifying that ISO develops standards but does not itself perform certification. https://www.iso.org/certification.html

Revision Record

Version 1.0

Date: July 16, 2026

Change type: Complete foundational edition

Summary: Establishes the canonical Standards Body standards-development process. Defines authority limits, document classes, normative language, work programs, need identification, preliminary research, new-work proposals, project classification, charters, stakeholder mapping, working groups, participation, balance, dominance, meetings, evidence, requirements engineering, drafting, editing, intellectual property, patents, security, pilots, committee drafts, public review, comments, substantial objections, consensus, voting, recirculation, independent and public-interest review, competition, international coherence, conformity-assessment readiness, approval, appeals, publication, public claims, implementation, external adoption, interpretations, corrections, amendments, revisions, systematic review, withdrawal, urgent and provisional standards, fast-track adoption, joint development, international candidates, translation, regulation, conformity assessment, evaluation protocols, open-source and small-actor participation, quality assurance, performance, maturity, failure modes, objections, implementation, pilot design, scorecard, operational templates, canonical positions, and primary research basis.

Status: Approved foundational source.

Downloads

PDF, Version 1.0 SHA-256 7352d4472cb364cc4646020073a5e0e723d233df1d6c2f8782c0f81cc9d36e15
Markdown, Version 1.0 SHA-256 ed6c538ca8bd5b09da5edcd484434ea0384e50063b60d347eade2d3d59a0be98
HTML, Version 1.0 SHA-256 1ee5f1871ca91b73a94089916346cf93352dd8edfb539d126828ae0f2c87c5af

Citation and record

Standards Body. "Standards Body Standards Development Process." Institutional-design proposal, public edition, Version 1.0, July 17, 2026. https://standardsbody.ai/library/institutional-design/standards-development-process/

Canonical page: /library/institutional-design/standards-development-process/

Immutable Version 1.0: /library/institutional-design/standards-development-process/versions/1.0/

Corrections: [email protected]. Corrections, supersession, and withdrawal are recorded; released versions are preserved without silent edits.

Standards Body Institution Design Institutional-design proposal
Authority and Nonauthority Site page
Standards Body Project Identity Foundational source
The Foundations of Frontier AI Evaluation Infrastructure Foundational source