Standards Body · Institutional-design proposal, public edition · Released July 17, 2026
Canonical record: https://standardsbody.ai/library/institutional-design/standards-development-process/
Standards Body is an independent research and institutional-design project. It is not currently a regulator, accreditation body, certification body, or governmental authority. This document is research; it is not an adopted standard.
Project: Standards Body
Primary domain: standardsbody.ai
Core line: Foundations for Frontier AI
Document type: Canonical 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
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:
Until the institutional readiness requirements in this document are met, Standards Body outputs should be labeled accurately as:
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:
This document establishes the complete standards-development process for Standards Body.
It defines:
The process is designed for frontier AI, a domain in which:
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.
Standards convert knowledge into repeatable expectations.
They can define:
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.
The complete process contains fifteen stages.
The process is not a conveyor belt.
A project may be:
The process is governed by:
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 Body may eventually develop:
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.
A standards project should be classified by evidence maturity.
The problem and methods remain uncertain.
A method exists but lacks broad implementation evidence.
Evidence supports guidance but not formal conformity.
A defined specification is ready for controlled implementation.
Evidence, implementation, participation, and process support formal approval.
Requirements are sufficiently precise and validated for conformity assessment.
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.
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 means broad agreement after serious efforts to resolve substantial objections.
Consensus does not require unanimity.
Consensus is not:
A substantial objection must be:
A mature standard should ordinarily receive at least one public-review period.
Recommended minimum:
Longer periods should be used when:
Approval requires more than a positive vote.
The approval package should show:
Every standard should have:
Frontier AI standards should ordinarily receive review more frequently than traditional five-year cycles when technology and threats move rapidly.
The objective is not to publish the greatest number of standards.
The objective is to publish standards that:
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.
A standards project should begin with a demonstrated coordination, measurement, safety, assurance, interoperability, or public-interest need.
The stronger the requirement, the stronger the evidence and implementation basis should be.
Choose a standard, specification, guidance document, test method, profile, or research report according to the need.
Participation and governance should be open.
Protected technical details may remain controlled when necessary.
Consensus should seek broad agreement without erasing material disagreement.
Participation should prevent dominance.
It need not assign identical numbers to every possible interest.
Stakeholders bring interests.
Experts bring competence.
A credible process needs both.
Public-interest review should affect scope, requirements, claims, and implementation.
A standard should be tested through implementations, pilots, simulations, or field evidence before high-consequence approval.
Use performance-based requirements when different technical approaches can achieve the objective credibly.
A requirement intended for conformity assessment should be sufficiently precise to support consistent evidence and decisions.
Prestigious participants do not eliminate the need for due process.
A standard without a maintenance system is incomplete.
Standards Body should avoid conflicting with or duplicating suitable external standards without reason.
Participation and access should not be limited unnecessarily by fees, language, location, or organizational size.
The legal effect of a standard arises from an external lawful mechanism, not from the document's internal label.
A technically useful standard may not yet be suitable for certification, audit, or accreditation.
Standards should support interpretation, correction, revision, suspension, supersession, and withdrawal.
This process applies to:
The following do not automatically enter the standards process:
Approval does not establish legal compliance unless the relevant legal authority gives it that effect.
Conformity with a standard does not establish universal safety.
Standards Body consensus does not establish worldwide consensus.
International participants do not transform Standards Body into an international organization.
A standard is not a certificate.
A standards-development process is not accreditation.
Definitions in TERMINOLOGY.md govern.
A document established through a defined process that provides requirements, specifications, guidelines, characteristics, or common practices for repeated use.
A detailed description of technical requirements, interfaces, methods, structures, or performance.
A specified procedure for measuring or evaluating one or more properties.
A standard defining a complete evaluation or operational protocol.
A selected and constrained implementation of broader standards for a defined use, domain, or jurisdiction.
A condition that must be fulfilled within the document's stated scope.
A provision expressing a preferred course of action.
A provision identifying an allowed course of action.
Broad agreement after serious effort to address substantial objections.
A reasoned material concern concerning technical validity, safety, rights, implementation, legal effect, competition, interoperability, evidence, or process.
A defined period during which interested persons may review and comment on a draft.
The documented treatment of a submitted comment.
An editor- or working-group-controlled draft without approved standards status.
A draft approved by the responsible committee for a defined next stage.
A committee draft released for public review.
A document approved under the applicable Standards Body process.
A formal clarification concerning application of an existing provision without changing its normative requirement.
A formally approved change to part of a standard.
A new edition or version incorporating substantive changes.
A decision that an existing standard remains current without substantive revision.
Replacement of one standard or version by another.
Formal termination of current Standards Body approval.
End of active maintenance and recommended current use.
A provision containing a requirement, recommendation, permission, definition, or rule necessary for implementation.
Explanatory or supporting material that does not create a normative obligation.
Publish:
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]
The process should not privilege a supplier, country, region, evaluator, funder, or technical architecture improperly.
No interest category should dominate.
Dominance can exist without numerical majority through:
The process should attempt to reconcile conflicting views and document unresolved objections.
Participants should receive:
A standard should respond to a real need and remain current.
Avoid conflicting or duplicative standards.
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]
Requirements should be supported by evidence appropriate to consequence.
A standard should be usable in real systems.
Requirements intended for conformity assessment should support consistent evidence.
Protect sensitive information proportionately.
Support:
Update or withdraw obsolete standards.
Process actors should be conflict-screened and decisions reviewable.
Standards Body should distinguish the following document classes.
Purpose:
Normative status:
Purpose:
Normative status:
Purpose:
Normative status:
Purpose:
Normative status:
Purpose:
Purpose:
Purpose:
Purpose:
Purpose:
Purpose:
Purpose:
Purpose:
Every document should state:
Related standards may form a family.
A family should define:
Frontier AI standards should be modular where possible.
Possible modules:
Normative text should be clearly distinguishable from:
A standard intended for implementation should define what it means to conform.
The standard should specify permitted and prohibited public claims.
The standard should define how versions relate.
The standard should define review and retirement.
Standards Body should use controlled normative language.
Indicates a requirement.
Indicates a prohibition.
Indicates a recommendation.
Indicates a discouraged practice.
Indicates permission.
Indicates possibility or capability, not permission.
Where a document uses must rather than shall, the drafting convention should remain consistent and documented.
A requirement should ordinarily contain one principal obligation.
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.
A requirement intended for conformity assessment should identify evidence or observable outcome.
Avoid unsupported terms such as:
unless:
Use technology-neutral language when the objective can be met through multiple valid approaches.
Prescriptive requirements may be justified where:
Each requirement should trace to:
The standards work program provides public visibility into planned and active work.
For each project, publish:
Proposed projects should be visible before authorization where practical.
Active work should show milestone status.
A paused project should state:
A discontinued project should preserve:
The Standards Council should review the work program at least twice each year.
The work program should balance:
The institution should not set publication quotas that incentivize weak standards.
A standards need may arise from:
The need statement should answer:
A standard may be appropriate when the problem requires:
Consider:
Do not begin formal standards work when:
Urgency may justify a provisional specification.
It does not eliminate the need for evidence, review, expiration, and correction.
The preliminary stage determines whether the topic is ready for standardization.
Apply EVIDENCE_STANDARDS.md.
The outcome may recommend:
Publish the preliminary research where safe.
High-consequence proposals should receive independent preliminary review.
A proposal may be submitted by:
The proposal should include:
Publish the proposal for comment before authorization when practical.
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.
Approve only when:
Possible outcomes:
A new-work rejection may receive procedural review but does not create a right to compel Standards Body to undertake the project.
Classify using:
Classification determines:
The charter controls scope, authority, participation, and deliverables.
The Standards Council approves the charter.
Technical and public-interest bodies may require conditions.
A material scope change requires:
The chair and Secretariat should prevent requirements outside the charter.
A project may be split when:
Stakeholder mapping identifies who:
Possible categories:
A participant may possess both.
Record them separately.
The working group should identify interests that are absent.
For each category, define:
Update the stakeholder map when scope changes.
A working group is the primary drafting and technical deliberation body.
Membership should be open under defined eligibility and competence conditions.
Voting status may require:
Observers may:
They may lack voting rights or protected access.
Liaisons represent formal relationships with external institutions.
The chair manages process.
The chair should not unilaterally determine content.
Supports continuity and acts during conflicts or absence.
The editor maintains the document and issue log.
The Secretariat supports:
Before substantive drafting, review composition for:
Provide:
A participant may be removed for:
Use due process.
Balance means that the process includes materially affected interests without allowing one category to control the outcome improperly.
Numerical balance can be useful.
It is not sufficient.
Five nominally independent participants funded by one actor may still constitute dominance.
The Secretariat and Standards Council should review dominance:
Participants should disclose organizational and funding affiliations.
Several participants under common control may be treated as one interest for balance analysis.
Open participation should not allow one organization to enroll unlimited affiliates to dominate.
Small actors may require:
Affected parties should influence:
They should not be expected to provide specialist technical drafting without support.
Provide:
Rotate times for international groups.
Members should be able to propose agenda items.
Record:
Use issue trackers, mailing lists, repositories, and written ballots to reduce geographic and scheduling barriers.
Chairs should prevent:
Closed sessions may be used for:
A safe public summary should be provided where possible.
Informal work may support drafting.
Material decisions should return to the recorded process.
Provide reasonable accessibility and readable materials.
The working group should maintain an evidence plan.
Apply EVIDENCE_STANDARDS.md.
Each material requirement should map to:
Maintain a contrary-evidence register.
A gap may lead to:
Expert judgment should be:
A requirement may rely partly on confidential evidence only when:
The approval package should display the evidence current-through date.
Refresh after:
Convert the identified need and evidence into clear, proportionate, implementable provisions.
A strong requirement identifies:
A risk-based requirement should define:
A capability trigger should define:
A process requirement should not be treated as proof of outcome.
An outcome requirement needs a valid method of assessment.
Documentation should serve:
Avoid documentation solely for audit appearance.
Assess:
Exceptions should be:
Permit equivalent evidence when:
Before inclusion, ask:
Working drafts may be produced iteratively.
They have no approved standards status.
The working group owns substantive content within its charter.
The editor maintains form and approved changes.
Maintain a public or appropriately controlled issue tracker.
Record material changes and rationale.
A standard should ordinarily include:
The scope should identify:
A normative reference is required for implementation.
Use stable and accessible references where possible.
Informative references support explanation but do not create required dependencies.
Use TERMINOLOGY.md and TAXONOMY.md.
New definitions should be reviewed for cross-library consistency.
Notes and examples should not contain hidden requirements.
Identify each annex as normative or informative.
Review:
The editor:
The editor may not silently:
Minor corrections may be accepted through a streamlined process.
A technical editor may improve:
Legal review may identify:
Legal review should not control technical substance beyond its role.
Public-facing summaries should receive plain-language review.
Schemas and code should be versioned with the text.
A mature standards program should adopt a public intellectual-property policy before accepting formal technical contributions.
Contributors should grant sufficient rights for Standards Body to:
The policy should clarify whether contributors retain copyright in original contributions and which license applies.
The public should understand:
Core public-interest standards should be freely readable.
Reference code should use a clear open-source or source-available license appropriate to interoperability and security.
Evaluation tasks and datasets may need separate licensing and access controls.
Do not include third-party protected material without permission or applicable legal basis.
Copyright access does not create a right to claim endorsement or use certification marks.
Technical standards can implicate patents.
A patent policy should exist before standards likely to require patented technology are approved.
Participants should disclose known patent claims that may be essential, subject to lawful policy.
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.
Possible approaches:
W3C's patent policy seeks royalty-free implementation of its specifications, while other standards systems use different models.[^w3c-patent]
Standards Body should not adjudicate patent validity unless legally authorized.
Standards Body does not guarantee that all patents have been identified.
Patent holders participating in drafting should disclose relevant interests.
Avoid requirements that make one vendor's proprietary technology unavoidable when open or equivalent alternatives exist.
Drafting should be open by default.
Protection may be necessary for:
A standard may contain:
The public document should explain:
Use role-based access and chain of custody.
Participants in protected drafting should meet:
Restricted provisions require independent review by persons with sufficient access.
Compromise may require:
Piloting tests whether the draft works outside the drafting room.
A high-consequence technical or assurance standard should ordinarily receive a pilot before final approval.
Seek variation in:
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]
Preserve:
A pilot does not establish conformity or approval unless explicitly defined.
Failure may lead to:
A working draft may become a committee draft when:
Include:
The working group approves advancement according to its charter.
The document should state that it is not an approved standard.
A project may produce several committee drafts.
High-consequence drafts should receive independent technical or methodological review before public release.
Public review permits interested persons to examine and challenge the draft before approval.
The public notice should state:
Recommended minimum periods:
The Standards Council may approve a different period with reasons.
Use 60 to 90 days when:
The public-review draft should be freely accessible during review.
Publish where safe:
Support:
Request:
Anonymous comments may be considered when sufficiently specific.
Comments should ordinarily be public.
Protected submissions may be accepted for:
Directly notify:
A hearing or workshop may supplement written review.
It should not replace written comments and records.
Assign each comment:
Similar comments may be grouped.
Do not use grouping to hide the scale or diversity of concern.
A response should state:
and explain why.
A comment is material when it may change:
A protected comment should receive the same substantive consideration as a public comment.
Publish the comment-disposition report, subject to redaction.
Notify commenters of disposition and appeal rights where applicable.
A commenter may identify the response as unresolved.
The working group should determine whether it is a substantial objection.
A substantial objection should be:
The working group should:
A substantial objection does not automatically create a veto.
An objection is not weak merely because few participants support it.
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]
Preserve unresolved objections with the standard's approval package.
The working group assesses technical consensus.
The Standards Council verifies the process and makes the formal consensus determination within its authority.
Consider:
Consensus is not established when:
Informal polls may identify direction.
They do not replace the final consensus assessment.
The chair may issue a formal consensus call.
It should state:
The chair and Secretariat should prepare:
The Standards Council may:
Voting may:
A high positive percentage does not cure:
Voting eligibility should be based on:
Affiliated participants may contribute.
Voting rules should prevent one organization from multiplying control.
Recommended default:
The charter may use a different rule.
Recommended default:
An abstention is not support or opposition.
Nonresponse should not automatically count as approval.
Final ballots should ordinarily be written and recorded.
Negative votes should include reasons.
A negative vote without reason may remain recorded but cannot always be resolved.
Material changes made after ballot should be recirculated.
A material change affects:
Material changes after public review should receive additional review.
The additional review may be limited to changed sections if:
Editorial and clarifying changes may not require new public review.
The chair proposes.
The Secretariat and Standards Council review.
A participant may appeal a refusal to recirculate a material change.
Independent review challenges the standard beyond the drafting group.
C3 and C4 standards should ordinarily receive independent review.
S5 assurance-ready standards should receive:
Use:
The working group responds to findings.
Publish or preserve material dissent.
Reviewers may receive protected evidence under controls.
State whether review was:
A famous reviewer does not replace a defined mandate and method.
Required for standards that may affect:
Examine:
Consider whether a less restrictive or less burdensome standard could achieve the objective.
Include direct evidence where possible.
The Public Interest and Rights Council may:
Publish the opinion and response where safe.
Standards can shape market access.
A standard should not protect Standards Body's own services or partner revenues.
Include competition findings in the approval package.
Before approval, review:
Determine whether to:
Invite relevant cross-regional institutions.
Preserve legitimate local extensions.
Translate key public-review material for international candidates where resources permit.
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]
A liaison should have an authorized mandate.
Required when the standard concerns:
Use protected annexes where appropriate.
Publish enough for:
The Security Committee should approve restrictions, not the technical content as a whole.
Approval as a standard does not establish readiness for conformity assessment.
An assurance-ready standard should include or reference:
If external accreditation is contemplated, define the competence scope precisely.
Do not create an assurance scheme where conformance can be achieved through paperwork without meaningful outcomes.
The final package should include:
The Secretariat performs a process-completeness check.
The working group recommends approval.
The Standards Council determines:
The Governing Board should not ordinarily approve individual technical standards.
Board approval may be required where:
The standard meets the process.
Conditions may concern:
Use when urgent implementation is justified but evidence or consensus remains incomplete.
Material issues remain.
The content is useful but not ready for standards status.
Await:
The project should not advance.
No further active work is planned.
Publish reasons and status.
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.
First seek resolution within:
Unresolved procedural appeals go to the Appeals and Review Panel.
Approval may be paused when the appeal could materially affect validity.
Publish a reasoned decision or safe summary.
Internal appeal does not replace legal or contractual rights.
The Standards Council authorizes publication after approval and resolution of eligible appeals.
Publish:
Each standard should receive a persistent identifier.
Preferred pattern:
SB-STD-[DOMAIN]-[YEAR]-[SEQUENCE]
Use semantic or controlled edition numbering.
The effective date may follow publication to permit transition.
Core standards should be freely readable.
Publish where relevant:
Provide accessible HTML and downloadable formats.
Provide a canonical citation.
Explain:
Explain how qualified implementers or evaluators may access controlled components.
Preserve all public versions.
Every public page and file should display current status.
This label means only that the document completed the approved Standards Body process.
An organization may claim conformity only when:
Unless separately established, prohibit:
Membership does not establish conformity.
Participation in drafting does not establish endorsement.
Pilot participation does not establish certification.
Where a claim depends on current status, provide a public registry.
The standard should define:
Provide nonnormative guidance where useful.
Possible artifacts:
Training may support adoption.
Completion of Standards Body training should not be required where equivalent competence exists unless justified.
A support channel may answer implementation questions.
Responses that change normative meaning should enter the formal interpretation process.
Create forums for:
Provide:
Collect:
Adoption should not be measured solely by downloads, signatures, or public pledges.
Organizations may voluntarily adopt a standard.
A contract may incorporate the standard.
The contract should identify:
A purchaser may require conformity.
Procurement should permit equivalent evidence where appropriate.
A certification scheme may use the standard if assurance readiness is established.
A regulator or legislature may:
the standard through its own authority.
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]
When public authorities consider adoption, Standards Body should provide:
Automatic incorporation of future revisions can create accountability and delegation concerns.
External authorities should determine how updates take effect.
Standards Body should obtain qualified review before representing legal effect.
An interpretation clarifies existing meaning.
It does not create a new requirement.
An interpretation request should identify:
Determine whether the request is:
The responsible maintenance group prepares interpretations.
The Standards Council approves formal interpretations.
If the answer changes normative meaning, use amendment or revision.
Interpretations should display:
A formal interpretation may affect future conformity decisions.
Transition should be provided where reliance existed.
An erratum corrects a clear error without changing intended normative substance.
May use a streamlined approval process.
A change affecting normative meaning requires amendment or revision.
Publish:
A safety- or security-relevant error may require:
Preserve the original version and visible correction.
An amendment changes a bounded part of an approved standard.
Include:
A substantive amendment should ordinarily receive:
Publish a consolidated edition or clearly link the amendment.
Amendments should update the version.
State whether the amendment is:
A revision may replace the complete standard.
A major revision should follow the full standards process proportionate to changes.
Provide:
A new version does not automatically invalidate prior certificates or claims.
The scheme or adopting authority should define transition.
Preserve all editions.
Suggested default:
Request implementation and review evidence.
Confirmation should not be automatic after silence.
Publish the evidence and decision.
A new standard or version replaces the prior one.
Approval ends because:
Active maintenance ends.
A retired standard may remain historically relevant.
May arise from:
Where organizations rely on the standard, provide:
unless urgent harm requires immediate suspension.
Temporarily suspend status when:
Update status immediately.
Organizations should stop making current-conformity claims after withdrawal according to the transition rule.
A provisional specification may address urgent coordination or safety needs before the full evidence and consensus process is complete.
Use only when:
The Standards Council may approve under an urgent process.
C4 matters may require additional governance review.
Recommended maximum:
Renewal requires evidence and public review.
A provisional specification may become:
Repeated renewal should trigger governance review.
Avoid duplicating mature external work.
Consider:
Prestige of the external organization is not enough.
Define how later external revisions affect the Standards Body adoption.
If the external source is withdrawn or materially changed, review promptly.
Standards Body may develop work jointly with another institution.
Define:
The joint process should meet the stronger applicable due-process requirement.
State which organization approved the document and under which process.
Assign ownership and update procedure.
Define what happens if the partners disagree or withdraw.
A Standards Body document may be classified as an international candidate only after demonstrating:
Standards Body should cooperate with national standards bodies rather than claim to replace their representative role.
Possible pathways:
International candidates should support:
Preserve regional or national reservations.
No document should be described as universally accepted.
Translations may be:
State which version controls if differences arise.
A translation intended for conformity should preserve normative force.
A local profile may adapt:
It should not silently weaken the common core.
Do not require all participation to occur only in one language where an international process claims broad reach.
A voluntary standard and a binding regulation are distinct.
A public authority may request standards work.
The request should be public where lawful and should not eliminate the standards process.
Government representatives may:
Their role should be documented.
A harmonized or regulatory-support standard should map clauses to legal requirements where appropriate.
Qualified legal review is required for legal claims.
The authority determines whether the standard receives legal recognition.
Standards Body should remain able to identify technical deficiencies even when a public authority requested the work.
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]
Standards define criteria.
Conformity assessment determines whether criteria are fulfilled.
A certification or assurance scheme needs more than a standard.
It needs:
Standards Body may develop standards and scheme concepts.
It should not claim certification or accreditation merely through publication.
Conformity-assessment experience should inform revisions.
Auditors and certification bodies may contribute.
They should not dominate requirements that create demand for their services.
Evaluator and conformity-assessment standards should support external accreditation systems where appropriate.
Protocol standards should incorporate:
The public standard may govern protected task banks without publishing exact content.
Task and environment changes may use controlled protocol procedures without requiring full standards revision when the standard permits them.
Define how results remain comparable across protocol versions.
Protocol standards should maintain a validity case.
Define where professional judgment is allowed and governed.
Open-source developers and maintainers should have pathways to participate.
Standards should account for:
Avoid requirements that assume privileged provider access when alternatives exist.
Open reference tools can reduce barriers.
Open publication should not expose active dangerous details without review.
Assess whether required artifacts can be produced under common open-source licenses.
Estimate:
Possible approaches:
Small size alone should not waive a requirement necessary for severe risk.
Permit valid alternate evidence.
Include small organizations before requirements are fixed.
Standards quality depends on both:
The Secretariat should perform process checks at:
A formal standards program should receive periodic external process audit.
A process nonconformity may be:
Examples:
A nonconformity may require:
The publication package should include a statement of process completion.
Metrics should improve the process rather than reward document volume.
Do not optimize the process for:
Publish:
Characteristics:
Characteristics:
Characteristics:
Characteristics:
Characteristics:
Characteristics:
Standards Body should not describe its process at a higher level than actual practice supports.
Failure:
A weak or contested method becomes fixed.
Control:
Evidence maturity and pilot gates.
Failure:
Fragmentation and risk persist while the institution waits for certainty.
Control:
Provisional specifications with expiration.
Failure:
A frontier developer controls scope, evidence, and language.
Control:
Balance, public-interest review, independent technical review.
Failure:
Evaluators create requirements that require their own services.
Control:
Conflict review, competition analysis, alternate methods.
Failure:
A policy deadline forces technical approval.
Control:
Provisional status, explicit uncertainty, no false consensus.
Failure:
Majority voting is described as consensus despite ignored objections.
Control:
Consensus report and objection record.
Failure:
Anyone may participate in theory, but cost and expertise barriers exclude most interests.
Control:
Participation funding, remote access, outreach, support.
Failure:
The editor changes substance through drafting control.
Control:
Change log, issue approval, editor limits.
Failure:
A narrow project becomes a broad governance framework without renewed authorization.
Control:
Charter control and material-change review.
Failure:
Normative obligations appear in notes, examples, or guidance.
Control:
Normative-language audit.
Failure:
Different evaluators reach incompatible decisions.
Control:
Evidence, methods, decision rules, proficiency testing.
Failure:
Organizations generate records without improving outcomes.
Control:
Outcome evidence and operational review.
Failure:
One implementation becomes mandatory.
Control:
Performance-based requirements, patent review, equivalent methods.
Failure:
Only large organizations can comply.
Control:
Burden assessment, shared infrastructure, proportional pathways.
Failure:
Technical participants define social consequence without affected-party input.
Control:
Public Interest and Rights Council review.
Failure:
Restricted evidence prevents meaningful challenge.
Control:
Independent access, public minimum, review date.
Failure:
Sensitive tasks or vulnerabilities are released.
Control:
Protected annexes and security review.
Failure:
A frontier AI standard becomes obsolete before revision.
Control:
Shorter review cycles, dynamic annexes, incident triggers.
Failure:
Standards Body creates a competing standard without need.
Control:
Coherence review and liaison.
Failure:
A voluntary standard is presented as regulatory compliance.
Control:
Authority note and legal review.
Failure:
A standard becomes the basis of a badge before assessment validity exists.
Control:
Separate conformity-readiness decision.
Failure:
Signatures and downloads replace effectiveness.
Control:
Outcome metrics.
Failure:
Temporary status avoids full review indefinitely.
Control:
Automatic expiration and renewal limit.
Failure:
No owner responds to errors or incidents.
Control:
Maintenance assignment before approval.
Failure:
Institutional reputation prevents retirement of a failed standard.
Control:
Independent review and mandatory status triggers.
Some details change too quickly.
Standards can still define stable infrastructure for:
Dynamic components should be versioned separately.
Industry dominance is a real risk.
The process uses:
Industry expertise remains necessary.
Exact evidence may remain restricted.
The public process can still govern:
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.
Public review should be proportionate.
Urgent provisional routes can operate faster with expiration and later full review.
Participation support and modular implementation are required.
A process that is nominally open but practically inaccessible is not sufficiently open.
Consensus is not unanimity.
The process requires serious consideration, not universal agreement.
They should not claim to.
Public-interest governance should be a distinct institutional function.
Funding may come from:
Core public access should remain protected.
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.
Title: Frontier AI Evaluation Result and Evidence Reporting Specification
Create a common, machine-readable and human-readable result profile covering:
It is:
The pilot would not:
| 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? |
The following normally prevent approval as a consensus standard:
Do not average the scorecard into one overall rating.
A critical process failure should remain decisive.
Proposal ID:
Proposed title:
Proposer:
Date:
Document class:
Proposed maturity:
Consequence level:
Project ID:
Title:
Parent body:
Document class:
Version:
Effective date:
| Interest category | Need or impact | Participants | Voting share | Affiliations | Barriers | Support | Missing perspectives |
|---|---|---|---|---|---|---|---|
| Developers | |||||||
| Deployers | |||||||
| Evaluators | |||||||
| Public interest | |||||||
| Affected parties | |||||||
| Government | |||||||
| Small actors | |||||||
| International |
| Requirement ID | Responsible actor | Objective | Risk or need | Evidence | Implementation | Conformity evidence | Exceptions | Related requirements |
|---|---|---|---|---|---|---|---|---|
Before advancement, confirm:
Project:
Draft:
Version:
Document status: Public-review draft
Review opens:
Review closes:
Responsible working group:
Commenter:
Affiliation:
Interest category:
Draft version:
Clause:
Comment type:
Comment ID:
Draft:
Clause:
Commenter:
Responsible reviewer:
Objection ID:
Objector:
Affiliation and interest:
Draft:
Date:
Project:
Draft version:
Chair:
Date:
Pilot ID:
Draft:
Implementer:
System or organization:
Region:
Date:
Standard or draft:
Reviewer:
Qualifications:
Independence profile:
Access:
Date:
Standard ID:
Title:
Version:
Decision body:
Date:
Request ID:
Standard and version:
Clause:
Requester:
Date:
Proposal ID:
Standard:
Current version:
Proposer:
Date:
Standard:
Version:
Review period:
Maintenance body:
Standard:
Version:
Status:
Effective date:
Audit period:
Auditor:
Independence:
Scope:
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.
PROJECT_IDENTITY.mdDefines 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.mdDefines the deeper purpose of creating credible frontier AI infrastructure.
INSTITUTION_DESIGN.mdDefines the organizational ecosystem and separation among standards, evaluation, certification, accreditation, and enforcement.
GOVERNANCE_FRAMEWORK.mdDefines the Standards Council, decision rights, voting, conflicts, appeals, transparency, and institutional transition.
FOUNDATIONS.mdDefines the eight foundations from which standards topics arise.
FOUNDATIONS_APPENDIX.mdDefines the integrated lifecycle connecting evaluation evidence to standards maturity.
TERMINOLOGY.mdProvides the controlled vocabulary for standards, requirements, consensus, assurance, and status.
EVIDENCE_STANDARDS.mdDefines the evidence levels and quality used to justify standards requirements.
RESEARCH_METHODOLOGY.mdGoverns the preliminary research, pilots, implementation studies, and standards research.
TAXONOMY.mdClassifies document types, standards stages, requirements, actors, decisions, and statuses.
EVALUATION_PHILOSOPHY.mdDefines how evaluation methods should be interpreted before they become standardized.
EVALUATOR_ACCREDITATION_FRAMEWORK.mdWill define the competence and recognition system for evaluators using standards and protocols.
CONTRIBUTOR_FRAMEWORK.mdWill define contributor participation, conduct, credit, access, and removal.
TRANSPARENCY_FRAMEWORK.mdWill define public review, disclosure, protected comments, records, and access.
PARTNERSHIP_PRINCIPLES.mdWill govern joint standards work and liaison relationships.
LONG_TERM_ROADMAP.mdWill sequence the transition from research outputs to a formal standards-development program.
Standards are among the most durable ways an institution can shape a technical field.
They can outlive:
That durability makes standards valuable.
It also makes premature standards dangerous.
Frontier AI standards may influence:
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:
A credible standards process does not guarantee that every requirement is right.
It guarantees something more realistic and institutionally valuable:
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.
[^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
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.