Standards Body · Foundation paper, public edition · Released July 17, 2026

Canonical record: https://standardsbody.ai/library/foundation-paper/global-interoperability/

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.

FOUNDATION_08_GLOBAL_INTEROPERABILITY.md

Foundation 8: Global Interoperability

Series: Foundations for Frontier AI Evaluation Infrastructure
Version: 1.0
Status: Canonical working white paper
Project: Standards Body
Primary domain: standardsbody.ai
Core line: Foundations for Frontier AI
Research basis reviewed through: July 16, 2026
Document owner: Standards Body
Review cycle: Annual review, with event-triggered revision after material changes in international standards, evaluation networks, treaty systems, accreditation arrangements, model capabilities, or cross-border deployment practice


Document Purpose

This paper defines the Standards Body position on global interoperability for frontier artificial intelligence evaluation, assurance, standards, and governance.

It is intended to serve as:

This paper does not propose a single global regulator.

It does not claim that all jurisdictions should adopt identical laws, thresholds, risk tolerances, or institutional structures.

It does not authorize Standards Body to recognize governments, accredit evaluators, certify systems, or negotiate treaties.

It defines the infrastructure required for distinct institutions to exchange and interpret credible evidence without erasing legitimate differences.


Executive Summary

Frontier AI systems cross borders more easily than the institutions responsible for evaluating and governing them.

A model may be:

The evidence surrounding that system may also be distributed.

One institution may hold:

Another may hold:

Another may possess:

Another may assess:

Another may issue:

Another may possess:

Without interoperability, these institutions can produce a large quantity of evidence that does not combine into shared understanding.

The same term may have different meanings.

The same score may be produced under different conditions.

The same model name may refer to different configurations.

The same certification language may imply different levels of assurance.

A threshold in one framework may not correspond to a threshold in another.

An evaluator accepted in one jurisdiction may be unrecognized in another.

An incident category may not transfer across legal systems.

A confidential finding may be too sensitive for public disclosure but too important to remain isolated.

A requirement may be technically equivalent to another requirement while appearing different because the documentation and institutional form are different.

These failures create practical consequences:

Global interoperability is the discipline of making evidence, standards, protocols, qualifications, and institutional decisions usable across boundaries.

It does not require one universal test.

It does not require one legal system.

It does not require one threshold.

It does not require one definition of acceptable risk.

It requires enough shared structure that different institutions can answer:

Standards Body adopts the following core position:

Global frontier AI governance should pursue interoperable evidence, protocols, terminology, and assurance systems while preserving legitimate jurisdictional, cultural, institutional, and policy differences. The objective is shared understanding and portable trust, not forced global uniformity.

A mature interoperability system should operate across at least ten layers.

1. Semantic interoperability

Institutions use shared definitions or explicit mappings among terms such as:

2. Identity interoperability

Evidence refers to a verifiable model, system, configuration, protocol, evaluator, and date.

3. Protocol interoperability

Evaluation procedures can be compared, mapped, reused, or reproduced across institutions.

4. Measurement interoperability

Scores, uncertainty, baselines, task populations, and thresholds can be interpreted without false equivalence.

5. Metadata interoperability

Reports include a common minimum set of machine-readable and human-readable information.

6. Assurance interoperability

Evaluator qualifications, scopes, review levels, accreditation, certification, and result status can be understood across borders.

7. Incident interoperability

Organizations can classify, share, escalate, and learn from incidents using compatible structures.

8. Legal and policy interoperability

Institutions can map technical evidence into different legal regimes without pretending the regimes are identical.

9. Security interoperability

Sensitive evidence can be exchanged through trusted, tiered, and accountable channels.

10. Institutional interoperability

Governments, laboratories, standards bodies, auditors, developers, researchers, and open communities can cooperate without surrendering their respective authority.

Interoperability should be built through modular agreements.

A country may recognize another country's evaluator competence while retaining its own deployment decision.

A purchaser may accept an evaluation report while requiring additional local testing.

A standards body may map two protocols without declaring them equivalent.

A regulator may recognize an international standard as evidence without making it the only compliance route.

A confidential incident exchange may operate among trusted institutions while a public summary remains available.

A multilingual protocol may preserve a shared construct while allowing locally valid tasks.

The central institutional distinction is between:

These are not the same.

A result can be scientifically informative without being legally determinative.

An evaluator can be competent without being authorized by every jurisdiction.

A certification can be valid under one scheme without satisfying every local requirement.

Interoperability should therefore support graded outcomes:

The global landscape already contains important building blocks.

NIST has published a plan for global engagement on AI standards centered on cooperation, consensus standards, and information sharing.[^nist-global] The OECD's Hiroshima AI Process Reporting Framework provides a common voluntary reporting structure for advanced AI governance and risk-management practices.[^haip] The Council of Europe Framework Convention on Artificial Intelligence establishes a treaty-level framework focused on human rights, democracy, and the rule of law.[^coe-convention] The United Nations Global Digital Compact establishes a broad global framework for digital cooperation and AI governance.[^un-gdc] International accreditation arrangements such as the ILAC Mutual Recognition Arrangement demonstrate how testing and inspection results can gain cross-border acceptance through peer-evaluated accreditation systems.[^ilac-mra] The International Network for Advanced AI Measurement, Evaluation and Science has begun articulating areas of consensus and open questions for advanced AI evaluation across national institutes.[^aisi-network]

These initiatives are not interchangeable.

They operate at different levels:

Global interoperability should connect them without collapsing them.

The eighth foundation of Standards Body is therefore a shared evidentiary language for plural institutions.


1. Foundational Proposition

1.1 Core Thesis

Frontier AI evidence should be understandable and usable across institutional and jurisdictional boundaries without requiring every institution to adopt the same law, protocol, threshold, or policy judgment.

1.2 Pluralism Thesis

Interoperability should preserve legitimate diversity while making differences explicit.

1.3 Evidence Thesis

The first object of international alignment should be the structure and meaning of evidence, not immediate agreement on every policy outcome.

1.4 Identity Thesis

No evaluation, certification, or incident record is globally useful unless the system, configuration, protocol, evaluator, and time are identifiable.

1.5 Recognition Thesis

Recognition should be granular. Institutions should be able to recognize competence, process, evidence, or legal effect separately.

1.6 Capacity Thesis

Global interoperability is incomplete when only a small number of wealthy countries, companies, or laboratories can produce or interpret the required evidence.

1.7 Security Thesis

International evidence sharing should protect sensitive models, vulnerabilities, incidents, personal data, and dual-use information through proportionate access controls and accountable disclosure.

1.8 Revisability Thesis

Mappings, equivalence decisions, recognition arrangements, and shared schemas should change as standards, systems, and institutional capabilities change.


2. Scope and Boundaries

2.1 What This Foundation Covers

This paper covers interoperability concerning:

2.2 What This Foundation Does Not Establish

This paper does not establish:

2.3 Interoperability Versus Harmonization

Interoperability enables systems or institutions to exchange and use information effectively.

Harmonization reduces differences among requirements, methods, or standards.

Interoperability can exist without full harmonization.

2.4 Interoperability Versus Equivalence

Two approaches may interoperate without being equivalent.

Equivalence is a stronger claim that outcomes or requirements are sufficiently comparable for a stated purpose.

2.5 Interoperability Versus Mutual Recognition

Mutual recognition is an institutional agreement to accept specified results, qualifications, certificates, or processes.

It normally depends on interoperability but adds legal or organizational commitment.

2.6 Interoperability Versus Uniformity

Uniformity requires sameness.

Interoperability requires understandable and manageable difference.

2.7 Technical Versus Political Agreement

Technical comparability does not automatically create political agreement.

A shared cyber capability result may support different national responses.


3. Canonical Definitions

3.1 Interoperability

The ability of distinct systems, organizations, protocols, or jurisdictions to exchange, interpret, and use information or evidence effectively.

3.2 Semantic Interoperability

Shared or mapped meaning among terms, classifications, and data elements.

3.3 Syntactic Interoperability

Compatibility in data structure, format, encoding, and transmission.

3.4 Procedural Interoperability

Compatibility among processes, workflows, responsibilities, and decision steps.

3.5 Technical Interoperability

Ability of technical systems, tools, APIs, schemas, and environments to work together.

3.6 Measurement Interoperability

Ability to interpret and compare measurements produced by different methods, instruments, task sets, or institutions.

3.7 Institutional Interoperability

Ability of organizations with different mandates and governance structures to coordinate and rely on one another's work.

3.8 Legal Interoperability

Ability to map or coordinate requirements and evidence across legal systems while preserving each system's authority.

3.9 Mutual Recognition

An arrangement through which parties accept specified results, qualifications, certificates, or decisions issued under another recognized system.

3.10 Unilateral Recognition

Acceptance by one party of another party's evidence or status without reciprocal obligation.

3.11 Equivalence

A determination that different requirements, methods, or systems achieve sufficiently comparable outcomes for a defined purpose.

3.12 Comparability

The degree to which results can be meaningfully compared.

3.13 Compatibility

The degree to which systems or requirements can operate together without unacceptable conflict.

3.14 Crosswalk

A structured mapping between terms, requirements, controls, classifications, or standards.

3.15 Concordance

A mapping showing relationships among multiple vocabularies or classification systems.

3.16 Reference Architecture

A common conceptual structure that supports implementation by different organizations.

3.17 Common Minimum

A baseline set of shared requirements or metadata accepted across participating systems.

3.18 Localization

Adaptation of a protocol, standard, or system to local language, law, culture, infrastructure, or professional practice.

3.19 Translation Validity

The degree to which a translated evaluation preserves the intended construct and interpretation.

3.20 Recognition Scope

The specific activities, methods, domains, systems, and conditions covered by a recognition arrangement.

3.21 Trust Anchor

An institution, credential, cryptographic root, registry, or assurance mechanism relied upon to establish identity or legitimacy.

3.22 Registry

A maintained record of protocols, systems, evaluators, certificates, incidents, mappings, or recognition status.

3.23 Evidence Package

A structured set of artifacts supporting a claim or decision.

3.24 Interoperability Profile

A declaration of the standards, schemas, protocols, identifiers, and recognition conditions supported by an organization or system.

3.25 Recognition Decision

A documented determination to accept, conditionally accept, partially accept, suspend, or reject external evidence or status.

3.26 Localization Layer

The part of a shared system that permits jurisdictional, linguistic, cultural, or domain-specific adaptation.

3.27 Core Layer

The shared components that should remain stable across implementations.

3.28 Bridge Study

An analysis that connects results across protocols, versions, languages, or task forms.

3.29 Technical Barrier

An unnecessary or disproportionate difference in requirements or procedures that impedes cross-border use or trade.

3.30 Regulatory Arbitrage

Movement of activity toward jurisdictions or institutional arrangements with weaker or more favorable requirements.

3.31 Data Sovereignty

The principle that data is subject to the laws, governance, and control arrangements associated with relevant jurisdictions or communities.

3.32 Federated Evaluation

Evaluation in which data, tasks, models, or evidence remain distributed while coordinated methods produce shared results.

3.33 Confidential Exchange Network

A governed network through which authorized institutions share nonpublic information under defined security, use, and accountability rules.

3.34 Interoperability Debt

The accumulated cost created by incompatible terminology, formats, identifiers, protocols, and institutional arrangements.

3.35 Recognition Drift

Deterioration in the validity of a recognition arrangement after methods, standards, institutions, or systems change.


4. Why Global Interoperability Is Necessary

4.1 AI Systems Are Transnational

Model supply chains, hosting, users, data, capital, and applications cross jurisdictions.

4.2 Evidence Is Fragmented

No single institution sees the entire system.

4.3 Duplicate Evaluation Is Expensive

Repeated assessments can consume:

Some duplication is valuable for independent replication.

Unnecessary duplication is not.

4.4 Incompatible Language Creates False Disagreement

Institutions may use different words for similar concepts or the same word for different concepts.

4.5 Incompatible Scores Create False Comparison

A score of 70 under one protocol may not be comparable with 70 under another.

4.6 Legal Fragmentation Creates Operational Burden

Organizations may need separate evidence packages for each market.

4.7 Incidents Cross Borders

Misuse, security failures, and model behavior can affect users in multiple countries.

4.8 Evaluator Capacity Is Uneven

Some regions have advanced laboratories and institutes.

Others do not.

4.9 International Trust Is Limited

Governments and organizations may distrust foreign evaluators, proprietary evidence, or politically influenced institutions.

4.10 Open Models Are Globally Distributed

No single developer can control all downstream versions or deployments.

4.11 Standards Can Reduce Barriers

Shared standards and recognition can reduce unnecessary repeated testing.

4.12 Coordination Can Create New Risks

Interoperability can also:

It requires governance.


5. What Should Be Shared and What Should Remain Local

5.1 Strong Candidates for Shared Foundations

5.2 Candidates for Shared Technical Methods

5.3 Candidates for Localization

5.4 Candidates for National or Institutional Authority

5.5 Shared Evidence, Local Judgment

The preferred model is:

Shared evidence structure, explicit local interpretation, accountable local or international decision authority.

5.6 No Hidden Localization

Local differences should be documented rather than silently embedded in test content or scoring.


6. Layers of Interoperability

Layer 1: Vocabulary

Can institutions understand each other's terms?

Layer 2: Identity

Can institutions verify the system, protocol, evaluator, and evidence source?

Layer 3: Data Format

Can reports and artifacts be exchanged?

Layer 4: Protocol

Can methods be reproduced or mapped?

Layer 5: Measurement

Can results be compared with appropriate uncertainty?

Layer 6: Assurance

Can evaluator competence and result status be recognized?

Layer 7: Security

Can sensitive information move safely?

Layer 8: Legal Mapping

Can evidence be used under different legal systems?

Layer 9: Institutional Workflow

Can organizations coordinate review, escalation, and appeals?

Layer 10: Capacity

Can all participating regions meaningfully implement and use the system?

Failure at one layer can undermine the others.


7. Design Principles

7.1 Interoperability Before Uniformity

Begin with compatible evidence and explicit mappings.

7.2 Meaning Before Format

A common JSON field is not useful if institutions interpret it differently.

7.3 Identity Before Comparison

Confirm what was evaluated before comparing results.

7.4 Purpose-Bounded Equivalence

Equivalence should always state the purpose for which it is accepted.

7.5 Minimum Common Core

Share the smallest stable core necessary for cooperation.

7.6 Documented Localization

Allow local adaptation with a clear record.

7.7 No False Comparability

State when results cannot be compared.

7.8 Plural Trust Anchors

Avoid dependence on one institution, registry, cloud, country, or accreditation body.

7.9 Proportional Security

Share enough for coordination without unnecessary disclosure.

7.10 Capacity Inclusion

Interoperability should include funding, training, infrastructure, and translation.

7.11 Open Interfaces

Prefer documented interfaces and portable evidence.

7.12 Standards Neutrality with Mapping

Support multiple standards through crosswalks where appropriate.

7.13 Versioned Recognition

Recognition applies to identified versions and scopes.

7.14 Contestability

Mappings and recognition decisions should be appealable and reviewable.

7.15 Human Legibility

Machine-readable systems should have clear human explanations.

7.16 Dynamic Maintenance

Crosswalks, schemas, and recognition should update as the field changes.


8. Semantic Interoperability

8.1 The Vocabulary Problem

Terms such as "frontier model," "systemic risk," "critical capability," and "independent evaluator" vary across organizations.

8.2 Canonical Vocabulary

A shared vocabulary should include:

8.3 Term Mapping

Mappings may indicate:

8.4 Definition Governance

Definitions should be:

8.5 Legal Definitions

Legal definitions may need precise jurisdictional meaning.

Do not overwrite them with technical vocabulary.

8.6 Translation

Translate concepts, not only words.

8.7 Ambiguity Register

Maintain disputed terms and unresolved interpretations.

8.8 Standards Body Terminology Role

TERMINOLOGY.md should become the canonical project vocabulary, with Foundation 8 defining mapping requirements.


9. Model and System Identity

9.1 Why Identity Matters

A model name is often insufficient.

Systems can differ through:

9.2 Minimum Identity Record

9.3 Cryptographic Identity

Where feasible, use:

9.4 Closed Systems

Closed APIs may require developer attestation and evaluator verification.

9.5 Open-Weight Systems

Record:

9.6 Composite Systems

Identity should include all material components.

9.7 Identity Change Trigger

A material identity change should trigger re-evaluation or explicit inheritance analysis.

9.8 Global Identifier

A future system could assign persistent, non-proprietary identifiers for evaluated AI artifacts and configurations.

9.9 Privacy and Security

Identity systems should not disclose sensitive information unnecessarily.


10. Protocol Interoperability

10.1 Protocol Identity

Each protocol should have:

10.2 Protocol Profile

A profile should describe:

10.3 Common Execution Interface

Shared evaluation tools can support portability.

The UK AI Security Institute's Inspect framework demonstrates a modular approach to evaluation tasks, agents, tools, scorers, and model interfaces.[^inspect]

10.4 Reference Implementation

A reference implementation can clarify the protocol.

It should not become the only permitted implementation unless required.

10.5 Protocol Mapping

Compare:

10.6 Compatibility Levels

Level A: Directly Reproducible

Same protocol and materially equivalent execution.

Level B: Form-Equivalent

Different task forms with validated comparability.

Level C: Construct-Compatible

Different methods measuring substantially the same construct.

Level D: Supporting Evidence

Related but not directly comparable.

Level E: Incompatible

No defensible comparison.

10.7 Bridge Studies

Use shared systems, anchor tasks, human baselines, and statistical analysis.

10.8 Protocol Forks

Allow forks with explicit lineage and compatibility statements.

10.9 Protocol Retirement

Retired protocols should remain discoverable with status.


11. Measurement Interoperability

11.1 Score Meaning

A score requires context.

11.2 Minimum Measurement Metadata

11.3 Common Units

Use common units where valid.

Examples:

11.4 Local Metrics

Some domains require specialized measures.

Map rather than force conversion.

11.5 Threshold Mapping

Thresholds may be:

11.6 Human Baselines

Human comparisons require common definitions of:

11.7 Uncertainty

Interoperability should carry uncertainty, not only point estimates.

11.8 Statistical Equating

Use only when assumptions are defensible.

11.9 No Universal Score

Standards Body opposes a single global frontier safety score.

11.10 Measurement Registry

A future registry can document metrics, protocols, mappings, and limitations.


12. Common Metadata Architecture

12.1 Purpose

Metadata makes evidence discoverable and interpretable.

12.2 Core Record Categories

System

What was evaluated?

Protocol

How was it evaluated?

Evaluator

Who performed the work?

Evidence

What artifacts support the result?

Result

What was found?

Assurance

What review or recognition applies?

Status

Is the evidence current?

Jurisdiction

Where and how can it be used?

12.3 Required Fields

12.4 Machine-Readable Format

Use open, documented schemas.

12.5 Human-Readable Summary

Every machine record should have a plain-language explanation.

12.6 Provenance

Record:

12.7 Privacy

Minimize personal data.

12.8 Extensibility

Allow domain and jurisdiction extensions.

12.9 Schema Governance

Define:


13. Evaluator and Assurance Interoperability

13.1 Competence Recognition

An evaluator's competence should be tied to:

13.2 Accreditation

Accreditation can support recognition when accreditation bodies operate under shared requirements and peer evaluation.

13.3 ILAC Model

The ILAC Mutual Recognition Arrangement supports cross-border acceptance of results from accredited testing, calibration, inspection, proficiency-testing, and reference-material activities.[^ilac-mra]

Its general principle, accredited once and accepted across participating systems, is instructive.

Frontier AI will require narrower and more dynamic scopes.

13.4 Recognition Types

13.5 Conditional Recognition

Recognition may require:

13.6 Recognition Registry

Publish:

13.7 Peer Evaluation

Institutions recognizing evaluators should themselves be reviewed.

13.8 Government Institutes

National institutes may recognize each other's technical evidence while retaining independent conclusions.

13.9 No Recognition by Prestige Alone

Institutional reputation is not a substitute for scope and evidence.


14. Certification and Conformity Claims Across Borders

14.1 Certification Portability

A certificate may travel only if:

14.2 Management-System Certification

ISO/IEC 42001 provides requirements for AI management systems, and ISO/IEC 42006 provides requirements for bodies auditing and certifying those systems.[^iso-42001][^iso-42006]

These standards can support international consistency in organizational assurance.

They do not establish universal system safety.

14.3 Product and Capability Claims

More technical evidence may be needed for:

14.4 Recognition Statement

A recognition statement should identify:

14.5 Marks

Global marks risk oversimplification.

Prefer verifiable registry records.

14.6 Suspension Propagation

Material suspension should be communicated across recognition networks.

14.7 Certificate Translation

Translation should preserve legal and technical meaning.


15. Incident Interoperability

15.1 Why Incident Exchange Matters

Incidents can reveal:

15.2 Incident Categories

15.3 Minimum Incident Record

15.4 Severity Mapping

Different institutions may use different scales.

Provide crosswalks.

15.5 Public and Restricted Layers

Public

High-level incident and lesson.

Trusted Network

Detailed technical and operational evidence.

Restricted

Highly sensitive vulnerabilities, personal data, or national-security information.

15.6 Notification

Define:

15.7 Near Misses

Include near misses to improve prevention.

15.8 Duplicate Incidents

Use common identifiers and linkage.

15.9 Incident Feedback

Incidents should update:

15.10 International Confidential Network

A future network could support trusted exchange among qualified national institutes and evaluators.


16. Secure Evidence Exchange

16.1 Information Classes

16.2 Sharing Agreement

Define:

16.3 Technical Controls

16.4 Federated Analysis

Keep evidence local while sharing:

16.5 Confidential Computing

May support joint evaluation without full asset disclosure.

Limitations remain.

16.6 Legal Constraints

Account for:

16.7 Trust Framework

A secure exchange network needs:

16.8 No Automatic Sharing

Interoperability should not compel unsafe or unlawful disclosure.


17. Standards Crosswalks

17.1 Purpose

Crosswalks reduce duplication and clarify overlap.

17.2 Crosswalk Objects

17.3 Mapping Types

17.4 Evidence

Every mapping should include:

17.5 No Automated Equivalence by Keyword

Similar language does not prove equivalent requirements.

17.6 Control Inheritance

Evidence under one standard may support another requirement.

It should not be reused beyond its valid scope.

17.7 Crosswalk Governance

Use:

17.8 Crosswalk Expiration

Update after either source changes.

17.9 Legal Crosswalks

Require jurisdiction-specific legal expertise.


18. Legal and Regulatory Interoperability

18.1 Different Legal Objectives

Legal systems may prioritize:

18.2 Evidence Portability

Technical evidence can be portable even when legal consequences differ.

18.3 EU AI Act

The European Union AI Act creates a risk-based legal structure with differentiated obligations for AI systems and general-purpose AI models.[^eu-ai-act]

Technical evidence may support compliance, but local legal interpretation remains necessary.

18.4 Council of Europe Convention

The Council of Europe Framework Convention provides a treaty-level framework focused on human rights, democracy, and the rule of law and was opened for signature in September 2024.[^coe-convention]

It illustrates a rights-centered international layer distinct from technical evaluation standards.

18.5 United Nations Global Digital Compact

The Global Digital Compact provides a global framework for digital cooperation and AI governance, including capacity building and international cooperation.[^un-gdc]

18.6 Presumption and Recognition

Law may:

18.7 Regulatory Cooperation

Authorities can cooperate through:

18.8 Sovereignty

Interoperability should not obscure who has legal authority.

18.9 Conflict of Laws

A system may face incompatible requirements.

Use:

18.10 No Regulatory Laundering

Private standards should not acquire legal effect without accountable recognition.


19. Multilingual and Cultural Interoperability

19.1 Language Is Part of the Construct

Translation can change:

19.2 Translation Process

Use:

19.3 Language Coverage

Report:

19.4 Cultural Adaptation

Some tasks should be localized rather than literally translated.

19.5 Cross-Language Comparability

Require bridge studies.

19.6 Local Experts

Local professional and cultural expertise is essential.

19.7 Dominant-Language Bias

English-centered protocols can misrepresent global capability and risk.

19.8 Legal Translation

Use qualified legal translators and jurisdictional review.

19.9 Multilingual Incident Exchange

Maintain canonical codes with local-language descriptions.

19.10 Recognition

Translation work should receive professional credit and funding.


20. Open-Source and Open-Weight Interoperability

20.1 Global Distribution

Open-weight models are copied, modified, quantized, merged, and deployed across borders.

20.2 Identity Challenge

Record:

20.3 Evaluation Portability

Open models can support independent reproduction.

20.4 Decentralized Responsibility

No single organization may control downstream deployment.

20.5 Community Registries

Communities can maintain:

20.6 Recognition

Community evaluation should be recognized when methods and evidence are credible.

20.7 Security

Open access changes safeguard and threat assumptions.

20.8 Small-Actor Burden

Interoperability schemas should be implementable without large compliance teams.

20.9 Licensing

License terms affect use but should not be confused with evaluation evidence.

20.10 Open Interfaces

Open tooling and schemas reduce institutional dependence.


21. Capacity Building and Global Inclusion

21.1 Capacity Is Part of Interoperability

A standard that only a few countries can implement is not globally interoperable in practice.

21.2 Capacity Dimensions

21.3 Developing Countries

International systems should support meaningful participation, not only consultation.

The United Nations has emphasized capacity building, equitable access, and participation by developing countries in global AI governance and safe, secure, and trustworthy AI systems.[^un-resolution][^un-gdc]

21.4 Capacity Mechanisms

21.5 Regional Hubs

Regional centers can adapt methods and build local trust.

21.6 Avoiding Dependency

Capacity building should support autonomous local competence rather than permanent reliance.

21.7 Funding Governance

Local institutions should participate in priority setting.

21.8 Brain Drain

Programs should support careers and institutions in participants' regions.

21.9 Measurement

Track who can:


22. International Networks and Institutions

22.1 National AI Measurement and Security Institutes

National institutes can:

22.2 International Network for Advanced AI Measurement, Evaluation and Science

The network has articulated shared areas of consensus and open questions concerning advanced AI evaluation, including the need for common understanding across borders.[^aisi-network]

22.3 Bilateral Partnerships

Bilateral agreements can support:

22.4 OECD

The OECD supports:

22.5 United Nations

The UN provides broad global participation and development-oriented coordination.

22.6 Council of Europe

The Council of Europe provides a human-rights, democracy, and rule-of-law treaty framework.

22.7 ISO and IEC

ISO and IEC provide international consensus standards and conformity-assessment infrastructure.

22.8 Accreditation Networks

ILAC and related international accreditation systems demonstrate peer-evaluated recognition mechanisms.

22.9 Industry Forums

Industry groups can support technical coordination but require conflict controls.

22.10 Civil Society and Academia

Independent research and public-interest scrutiny are necessary counterweights.

22.11 Polycentric Governance

No single institution is likely to govern all layers effectively.

A polycentric system can distribute authority while sharing evidence.


23. Recognition Architecture

23.1 Four Recognition Objects

Evidence Recognition

Accepts an external result as informative.

Competence Recognition

Accepts that an evaluator is qualified within scope.

Process Recognition

Accepts that a protocol, audit, or certification process meets shared requirements.

Legal Recognition

Gives formal effect under a legal system.

23.2 Recognition Levels

R0: No Recognition

Evidence may be reviewed but receives no presumed weight.

R1: Informational Use

Evidence may support analysis.

R2: Conditional Technical Recognition

Evidence is accepted subject to conditions or supplemental work.

R3: Full Technical Recognition

Evidence is accepted for the defined technical purpose.

R4: Institutional Recognition

Evaluator, process, or certificate is recognized within scope.

R5: Legal Recognition

Evidence or status receives formal legal effect.

23.3 Recognition Criteria

23.4 Recognition Is Not Permanent

Use:

23.5 Recognition Decision Record

Document:


24. Dispute Resolution

24.1 Dispute Types

24.2 Technical Resolution

Use:

24.3 Institutional Resolution

Use:

24.4 Legal Dispute

Handled by competent legal institutions.

24.5 Dissent

Unresolved disagreement should remain visible.

24.6 Temporary Status

Use:

24.7 No Forced Equivalence

Failure to agree should not produce false compatibility.


25. Governance

25.1 Governance Functions

25.2 Distributed Governance

Different organizations can own different functions.

25.3 Standards Body Role

At its present stage, Standards Body should:

25.4 Balanced Participation

Include:

25.5 Conflict Controls

Disclose:

25.6 Decision Separation

Separate technical mapping from legal recognition where possible.

25.7 Public Records

Publish:

25.8 Emergency Change

Use narrow, temporary processes for:

25.9 Appeals

Allow challenge of recognition and mapping decisions.

25.10 Sunset

Governance bodies and arrangements should be reviewable.


26. Maturity Model

Level 0: Fragmented Evidence

Characteristics:

Level 1: Shared Vocabulary and Metadata

Characteristics:

Level 2: Protocol and Evaluator Compatibility

Characteristics:

Level 3: Conditional Recognition Network

Characteristics:

Level 4: Internationally Interoperable Assurance Regime

Characteristics:


27. Implementation Pathway

Phase 1: Vocabulary Inventory

Collect definitions across major frameworks and institutions.

Phase 2: Core Terminology

Publish a stable minimum and explicit mappings.

Phase 3: Metadata Schema

Create a machine-readable evaluation record.

Phase 4: Model Identity Pilot

Test identity records for closed and open systems.

Phase 5: Protocol Registry

Register protocol versions, owners, scope, and status.

Phase 6: Crosswalk Pilot

Map two evaluation protocols and two governance frameworks.

Phase 7: Bridge Study

Run common systems across protocols.

Phase 8: Evaluator Profile

Publish competence and recognition metadata.

Phase 9: Incident Taxonomy

Pilot public and restricted incident records.

Phase 10: Secure Exchange

Create a limited trusted network among qualified partners.

Phase 11: Recognition Pilot

Conduct a conditional technical-recognition decision.

Phase 12: Capacity Program

Support participation from underrepresented regions and smaller evaluators.

Phase 13: International Review

Invite external institutions to challenge the architecture.

Phase 14: Revise and Scale

Expand only after evidence.


28. Proposed Standards Body Pilot

28.1 Pilot Name

Global Frontier Evaluation Interoperability Profile

28.2 Purpose

Demonstrate that two independent institutions can exchange and interpret frontier AI evaluation evidence without using identical protocols or surrendering local decision authority.

28.3 Pilot Domain

Autonomous cyber capability.

This domain connects Foundations 1 through 7 and provides:

28.4 Participants

Target participation from:

28.5 Shared Core

28.6 Local Modules

Participants retain:

28.7 Evaluation

Each institution evaluates:

28.8 Bridge Study

Compare:

28.9 Recognition Exercise

Each institution decides whether the other's evidence is:

28.10 Incident Exchange Exercise

Simulate a cross-border safeguard failure and test:

28.11 Outputs

28.12 Success Criteria

The pilot succeeds if it:


29. Metrics for Evaluating Interoperability

29.1 Semantic Quality

29.2 Identity Quality

29.3 Protocol Quality

29.4 Measurement Quality

29.5 Data Quality

29.6 Recognition Quality

29.7 Security

29.8 Capacity

29.9 Efficiency

29.10 Governance

29.11 Decision Utility


30. Failure Modes and Safeguards

30.1 Uniformity Disguised as Interoperability

Failure: One institution's system becomes the global default without meaningful consent.

Safeguard: modular core, localization, plural governance, alternative mappings.

30.2 Lowest Common Denominator

Failure: Shared standards become too weak to matter.

Safeguard: common baseline plus higher-assurance profiles.

30.3 False Equivalence

Failure: Different protocols are treated as interchangeable.

Safeguard: purpose-bounded recognition and bridge studies.

30.4 Semantic Drift

Failure: Shared terms acquire different meanings.

Safeguard: versioned vocabulary and definition governance.

30.5 Model Identity Failure

Failure: Evidence is applied to a different model or configuration.

Safeguard: signed manifests, configuration metadata, re-evaluation triggers.

30.6 Score Portability Error

Failure: Numeric results travel without context.

Safeguard: required protocol, uncertainty, and task metadata.

30.7 Recognition Capture

Failure: Powerful jurisdictions or organizations control accepted evidence.

Safeguard: distributed recognition, peer review, appeals, capacity support.

30.8 Weak Standard Propagation

Failure: Mutual recognition spreads poor assurance.

Safeguard: surveillance, proficiency testing, suspension, limited scope.

30.9 Registry Monopoly

Failure: One registry controls legitimacy.

Safeguard: interoperable registries, open formats, mirrored records.

30.10 Sensitive Data Centralization

Failure: Global coordination creates a high-value breach target.

Safeguard: federation, compartmentalization, minimal disclosure.

30.11 Legal Overreach

Failure: Technical mapping is treated as legal equivalence.

Safeguard: separate technical and legal decisions.

30.12 Translation Error

Failure: Local-language evaluation changes construct meaning.

Safeguard: translation validation and local experts.

30.13 English Dominance

Failure: English performance and institutions define global capability.

Safeguard: multilingual task development, funding, and bridge studies.

30.14 Capacity Exclusion

Failure: Countries are expected to adopt standards they cannot implement.

Safeguard: capacity building, regional hubs, shared infrastructure.

30.15 Regulatory Arbitrage

Failure: Actors use interoperability to select the weakest regime.

Safeguard: recognition conditions and local minimums.

30.16 Duplicate Burden Persists

Failure: Institutions collect the same evidence in different formats.

Safeguard: common evidence package and crosswalks.

30.17 Incident Suppression

Failure: Legal or reputational concerns block sharing.

Safeguard: protected exchange, de-identification, corrective incentives.

30.18 Recognition Staleness

Failure: Institutions continue accepting obsolete scopes or methods.

Safeguard: expiry, surveillance, automatic status updates.

30.19 Geopolitical Fragmentation

Failure: Technical networks divide into incompatible blocs.

Safeguard: neutral interfaces, multilateral participation, scientific cooperation.

30.20 Authority Confusion

Failure: Standards Body or another technical institution is mistaken for a regulator.

Safeguard: precise public language and mandate boundaries.


31. Serious Objections

Objection 1: Global Interoperability Is Unrealistic During Geopolitical Competition

Competition creates distrust and strategic secrecy.

Response:

Begin with narrow technical artifacts:

Residual concern:

High-sensitivity domains may remain fragmented.

Objection 2: Different Values Make Shared Standards Impossible

Values differ.

Shared evidence does not require shared values.

Institutions can agree on what was measured while disagreeing on acceptable risk.

Objection 3: Interoperability Helps Regulatory Arbitrage

It can.

Response:

Recognition should preserve local minimum requirements and conditions.

Objection 4: Global Standards Favor Large Companies

They can.

Response:

Include small-actor pathways, open tools, capacity support, and competition review.

Objection 5: Mutual Recognition Spreads Weak Evaluations

Correct.

Response:

Use peer evaluation, narrow scopes, proficiency testing, surveillance, and suspension.

Objection 6: Common Metadata Creates Bureaucracy

It adds reporting burden.

Response:

Use a minimal core, reusable machine-readable records, and evidence portability.

Objection 7: Confidential Information Cannot Be Shared Internationally

Some information cannot.

Interoperability can still support:

Objection 8: Legal Systems Cannot Be Harmonized

Full harmonization is not required.

Technical and evidentiary crosswalks can coexist with legal difference.

Objection 9: Translation Makes Evaluation Incomparable

Translation creates real measurement challenges.

Response:

Validate translation, localize where necessary, and report comparability limits.

Objection 10: One Global Registry Would Be Efficient

It would also create:

Use interoperable registries.

Objection 11: National Institutes Should Trust Only Their Own Evaluations

Independent national testing is valuable.

Exclusive reliance creates duplication and limits learning.

Conditional recognition preserves sovereignty.

Objection 12: Open-Weight Systems Cannot Be Governed Through Institutional Recognition

Their decentralized nature changes responsibility.

Interoperable identity, evaluation, incident, and community-governance systems remain useful.


32. Evidence Gaps

32.1 Construct Mapping

How reliably can different frontier evaluation frameworks be mapped?

32.2 Score Comparability

Which bridge methods work across dynamic, agentic, and held-out protocols?

32.3 Model Identity

What identity mechanisms work for closed, continuously updated systems?

32.4 Recognition

Which recognition models preserve rigor without excessive duplication?

32.5 Incident Exchange

What information can be shared safely and usefully across borders?

32.6 Translation

Which methods preserve construct validity across languages and cultures?

32.7 Capacity

Which capacity-building models produce durable local institutions?

32.8 Legal Crosswalks

How should technical evidence be mapped into distinct legal systems?

32.9 Accreditation

Can existing international accreditation arrangements adapt to dynamic frontier AI evaluation?

32.10 Federated Evaluation

When can models and data remain local while evidence remains comparable?

32.11 Registry Governance

How can registries remain accurate, distributed, and politically legitimate?

32.12 Recognition Drift

How quickly do recognition arrangements become obsolete?

32.13 Geopolitical Resilience

Which technical layers can remain interoperable during political conflict?

32.14 Decision Impact

Does interoperability improve safety and efficiency enough to justify institutional cost?


33. Research Agenda

Priority 1: Canonical Vocabulary

Build and validate a multilingual frontier evaluation ontology.

Priority 2: System Identity

Develop portable identifiers and configuration manifests.

Priority 3: Evaluation Metadata

Create an open minimum schema for protocols and results.

Priority 4: Protocol Crosswalks

Develop methods for mapping constructs, tasks, scoring, and thresholds.

Priority 5: Bridge Studies

Test statistical and qualitative comparability across institutions.

Priority 6: Evaluator Recognition

Pilot scope-specific competence recognition.

Priority 7: Incident Taxonomy

Develop public and restricted international incident records.

Priority 8: Secure Exchange

Test federated, confidential, and tiered evidence sharing.

Priority 9: Translation Validity

Develop multilingual evaluation methodology.

Priority 10: Capacity Building

Compare regional hubs, fellowships, shared facilities, and twinning.

Priority 11: Legal Interoperability

Develop technical-to-legal crosswalk methods.

Priority 12: Registry Architecture

Design distributed, signed, machine-readable registries.

Priority 13: Mutual Recognition

Pilot conditional recognition in bounded domains.

Priority 14: Recognition Surveillance

Develop event-triggered updates and suspension propagation.

Priority 15: Interoperability Impact

Measure duplication, cost, safety, participation, and trust.


34. Near-Term Experiments

Experiment 1: Vocabulary Crosswalk

Map ten core terms across five major frameworks.

Experiment 2: Model Manifest

Create identity records for one closed and one open-weight system.

Experiment 3: Shared Metadata

Have three evaluators publish the same minimum result schema.

Experiment 4: Protocol Bridge

Run two protocols on common reference systems.

Experiment 5: Conditional Recognition

Have two institutions assess whether to recognize each other's evidence.

Experiment 6: Incident Simulation

Run a confidential cross-border incident exchange drill.

Experiment 7: Translation Study

Translate and validate an evaluation in three languages.

Experiment 8: Registry Federation

Synchronize signed records across two independent registries.

Experiment 9: Capacity Pilot

Support a regional evaluator to implement the common profile.

Experiment 10: Standards Crosswalk

Map NIST AI RMF, ISO/IEC 42001, and one frontier safety framework.

Experiment 11: Legal Evidence Package

Test one technical report against two jurisdictional requirements.

Experiment 12: Recognition Suspension

Simulate method invalidation and status propagation.


35. Implications for Future Standards

A future global interoperability standard could require:

35.1 Vocabulary

Canonical terms, mappings, and versioning.

35.2 Identity

Persistent identifiers for systems, protocols, evaluators, and reports.

35.3 Metadata

Minimum human-readable and machine-readable fields.

35.4 Protocol Profile

Construct, tasks, administration, scoring, security, and expiration.

35.5 Measurement

Units, uncertainty, baselines, and comparability statement.

35.6 Evaluator Profile

Competence, scope, independence, security, and recognition.

35.7 Result Status

Current, expired, suspended, corrected, withdrawn, or superseded.

35.8 Recognition

Purpose, scope, conditions, duration, and appeal.

35.9 Incident Exchange

Classification, minimum data, sensitivity, and notification.

35.10 Security

Access control, provenance, retention, onward disclosure, and incident response.

35.11 Localization

Language, cultural, legal, and professional adaptation.

35.12 Crosswalks

Methods for mapping standards and requirements.

35.13 Capacity

Minimum support and participation expectations.

35.14 Governance

Change control, conflicts, dissent, and public records.

35.15 Retirement

Deprecation, transition, suspension, and archive.

Such a standard should be developed through STANDARDS_DEVELOPMENT_PROCESS.md with international participation.


36. Relationship to the Other Foundations

Foundation 1: Dynamic Evaluation Protocols

Interoperability must preserve protocol versioning, bridge studies, and explicit discontinuity.

Foundation 2: Held-Out Evaluations

Cross-border use of protected evidence requires secure custody, access, and compromise response.

Foundation 3: High-Stakes Capability Evaluation

Capability evidence should be comparable enough to support coordinated preparation without forcing one global threshold.

Foundation 4: Independent Expert Review

Reviewer access, independence, competence, and findings need portable profiles.

Foundation 5: Third-Party Auditor Ecosystem

Accreditation, proficiency, registries, and mutual recognition are central interoperability mechanisms.

Foundation 6: Progressive Standards and Requirements

Voluntary frameworks, standards, procurement, and law require crosswalks and recognition.

Foundation 7: Incentives and Prestige

International recognition can reward interoperable evidence, while prestige competition can fragment it.


37. Canonical Standards Body Positions

Standards Body adopts the following working positions.

  1. Global interoperability is necessary because frontier AI systems, evidence, and deployment cross borders.

  2. Interoperability should not be confused with global uniformity.

  3. Shared evidence structure should generally precede attempts to impose shared policy outcomes.

  4. Technical comparability does not require identical legal consequence.

  5. Evidence recognition, competence recognition, process recognition, and legal recognition should remain distinct.

  6. Every interoperable evaluation record should identify the model or system, configuration, protocol, evaluator, date, uncertainty, limitations, and status.

  7. A model name alone is not adequate system identity.

  8. Numeric scores should never travel without protocol and measurement context.

  9. Protocol equivalence should be demonstrated for a stated purpose, not assumed.

  10. Noncomparability is a legitimate and important result.

  11. Shared terminology should include explicit mappings and disputed-term records.

  12. Global metadata should use a stable common core with local extensions.

  13. Evaluator recognition should be scope-specific and versioned.

  14. Accreditation and mutual-recognition systems should be adapted carefully rather than copied mechanically.

  15. Certification issued under one scheme should not automatically satisfy every jurisdiction.

  16. Incident reporting should support public, trusted, and restricted disclosure layers.

  17. International evidence sharing should be secure, purpose-limited, and auditable.

  18. Interoperability should not compel unlawful or unsafe disclosure.

  19. Legal crosswalks require jurisdiction-specific expertise.

  20. Multilingual evaluation requires construct validation, not literal translation alone.

  21. English-language performance should not define global AI capability by default.

  22. Open-weight model lineage and configuration should be recorded through portable identity methods.

  23. Capacity building is part of interoperability, not a separate charitable addition.

  24. Developing countries and underrepresented regions should participate in technical design and governance, not only implementation.

  25. Recognition networks should use plural trust anchors and avoid one global monopoly.

  26. Interoperable registries should be portable, signed, and independently governable.

  27. Recognition should expire or suspend after material changes or loss of confidence.

  28. International cooperation should preserve national and institutional decision authority.

  29. Shared minimums should not prevent stronger local safeguards.

  30. Global interoperability should be evaluated by whether it improves evidence, reduces unnecessary duplication, broadens participation, and strengthens real decisions.


38. Decision Rules

A protocol should be considered interoperable when:

Two results should be treated as directly comparable only when:

A result may receive conditional recognition when:

Recognition should be suspended when:

A global common requirement should not be proposed when:

A cross-border incident should be shared through a trusted channel when:


39. Interoperability Profile Template

A. Organization

B. Supported Standards

C. Supported Protocols

D. Vocabulary

E. Identity

F. Metadata

G. Evaluation

H. Evaluator Recognition

I. Incident Exchange

J. Security

K. Localization

L. Recognition


40. Protocol Crosswalk Template

Protocol A:
Protocol B:
Purpose of mapping:
Date:
Reviewers:

Construct

Scope

Evaluated Object

Task Population

Sampling

Tools and Scaffolds

Administration

Scoring

Uncertainty

Baselines

Security

Reporting

Versioning

Thresholds

Local Modules

Compatibility Assessment

Conditions

Evidence Needed

Expiration


41. Recognition Decision Template

Recognizing body:
External body or evidence:
Recognition object:
Purpose:
Date:

Identity

Scope

Competence

Method

Accreditation or Review

Security

Version

Local Requirements

Gaps

Supplemental Work

Conflicts

Decision

Conditions

Duration

Surveillance

Appeal

Suspension Triggers


42. International Incident Exchange Template

Incident identifier:
Reporting organization:
System:
Date:
Jurisdictions affected:

Category

Severity

Impact

Detection

Technical Summary

Capability Implication

Safeguard Implication

Evaluation Implication

Root Cause

Response

Current Status

Information Classification

Authorized Recipients

Onward Disclosure

Legal Constraints

Requested Action

Public Summary

Follow-Up


43. Translation and Localization Validation Template

Source protocol:
Target language or region:
Version:
Date:

Construct

Source Material

Translation Team

Domain Review

Cultural Adaptation

Legal Adaptation

Back Translation

Pilot Systems

Human Baselines

Difficulty Analysis

Bias Analysis

Comparability

Non-Equivalent Items

Local Additions

Limitations

Approval

Review Date


44. Registry Record Template

A. Record Identity

B. Subject

C. Scope

D. Status

E. Evidence

F. Recognition

G. Security Classification

H. Jurisdiction

I. Related Records

J. Correction History

K. Expiration

L. Public Summary


45. Global Interoperability Scorecard

Dimension Core Question
Purpose Is the intended cross-border use defined?
Vocabulary Are terms shared or explicitly mapped?
Identity Is the model, system, protocol, evaluator, and date identifiable?
Metadata Is a common minimum record available?
Protocol Can methods be reproduced, mapped, or bridged?
Measurement Are scores, uncertainty, and baselines interpretable?
Comparability Is equivalence demonstrated rather than assumed?
Noncomparability Can the system clearly state when comparison fails?
Evaluator competence Is scope-specific qualification legible?
Recognition Are purpose, conditions, duration, and status explicit?
Accreditation Are recognizing bodies competent and peer reviewed?
Certification Are claims limited to scheme and scope?
Incidents Can material incidents be classified and exchanged?
Security Can sensitive evidence move under accountable controls?
Provenance Can evidence history and modification be traced?
Localization Are language, culture, law, and professional context addressed?
Legal mapping Are technical and legal equivalence kept distinct?
Open-source fit Can distributed model lineage and evidence be represented?
Capacity Can smaller and underrepresented institutions participate?
Registry Are records portable, current, and independently verifiable?
Governance Are changes, conflicts, appeals, and dissent managed?
Resilience Does the system avoid one trust anchor or registry monopoly?
Efficiency Does interoperability reduce unnecessary duplication?
International utility Can evidence support real cross-border decisions?
Adaptation Can mappings and recognition evolve as AI changes?

46. Final Perspective

Global AI governance is often discussed as a choice between two extremes.

One extreme is fragmentation.

Every country, company, evaluator, and standards body creates its own:

Evidence becomes difficult to combine.

Organizations repeat the same work.

Smaller countries and institutions become dependent on dominant actors.

Incidents fail to travel.

The other extreme is forced uniformity.

One framework, one registry, one evaluator network, one risk model, or one political bloc becomes the global default.

Local law, culture, language, professional context, and institutional legitimacy are treated as obstacles rather than sources of knowledge.

Neither extreme is sufficient.

Frontier AI requires shared evidence and plural authority.

The shared layer should make it possible to know:

The plural layer should preserve the right of institutions and communities to decide:

Interoperability is the bridge.

It does not eliminate disagreement.

It makes disagreement more precise.

It does not eliminate duplication.

It distinguishes independent replication from administrative repetition.

It does not eliminate national authority.

It allows national authority to use evidence produced elsewhere without surrendering judgment.

It does not eliminate confidential information.

It creates controlled pathways for information that should not remain isolated.

It does not guarantee trust.

It provides the infrastructure through which trust can be earned, limited, reviewed, and withdrawn.

The eighth foundation of Standards Body is therefore portable evidence across plural institutions.

The future international system should not require every institution to speak with one voice.

It should make it possible for different voices to understand the same evidence.


References and Research Basis

[^nist-global]: National Institute of Standards and Technology, A Plan for Global Engagement on AI Standards, NIST AI 100-5, released 2024 and updated in 2025. https://www.nist.gov/publications/plan-global-engagement-ai-standards

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

[^nist-rmf]: National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023. https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf

[^haip]: OECD, Hiroshima AI Process Reporting Framework. https://oecd.ai/en/hiroshima

[^haip-overview]: OECD, HAIP Reporting Framework Overview. https://oecd.ai/en/transparency/overview

[^haip-insights]: OECD, How Are AI Developers Managing Risks? Insights from Responses to the Reporting Framework of the Hiroshima AI Process Code of Conduct, 2025. https://oecd.ai/en/ai-publications/how-are-ai-developers-managing-risks-insights-from-responses-to-the-reporting-framework-of-the-hiroshima-ai-process-code-of-conduct

[^coe-convention]: Council of Europe, Framework Convention on Artificial Intelligence and Human Rights, Democracy and the Rule of Law. https://www.coe.int/en/web/artificial-intelligence/the-framework-convention-on-artificial-intelligence

[^coe-treaty-status]: Council of Europe Treaty Office, Chart of Signatures and Ratifications of Treaty 225. https://www.coe.int/en/web/conventions/full-list/?module=signatures-by-treaty&treatynum=225

[^un-gdc]: United Nations, Global Digital Compact, 2024. https://www.un.org/global-digital-compact/sites/default/files/2024-09/Global%20Digital%20Compact%20-%20English_0.pdf

[^un-gdc-site]: United Nations Office for Digital and Emerging Technologies, Global Digital Compact. https://www.un.org/digital-emerging-technologies/global-digital-compact

[^un-resolution]: United Nations General Assembly, A/RES/78/265, Seizing the Opportunities of Safe, Secure and Trustworthy Artificial Intelligence Systems for Sustainable Development, 2024. https://digitallibrary.un.org/record/4043244/files/A_RES_78_265-EN.pdf

[^un-ai-report]: United Nations Secretary-General's High-level Advisory Body on Artificial Intelligence, Governing AI for Humanity: Final Report, 2024. https://www.un.org/sites/un2.un.org/files/governing_ai_for_humanity_final_report_en.pdf

[^aisi-network]: UK AI Security Institute, International Consensus and Open Questions in AI Evaluations, February 12, 2026. https://www.aisi.gov.uk/blog/international-ai-network-consensus-and-open-questions

[^aisi]: UK AI Security Institute. https://www.aisi.gov.uk/

[^inspect]: UK AI Security Institute, Inspect AI. https://inspect.aisi.org.uk/

[^iso-ai]: International Organization for Standardization, Artificial Intelligence Standards. https://www.iso.org/sectors/it-technologies/ai

[^iso-sc42]: International Organization for Standardization, ISO/IEC JTC 1/SC 42 Artificial Intelligence Catalogue. https://www.iso.org/committee/6794475/x/catalogue/

[^iso-42001]: International Organization for Standardization, ISO/IEC 42001:2023, Artificial Intelligence Management Systems. https://www.iso.org/standard/42001

[^iso-42006]: International Organization for Standardization, ISO/IEC 42006:2025, Requirements for Bodies Providing Audit and Certification of Artificial Intelligence Management Systems. https://www.iso.org/standard/42006

[^iso-23894]: International Organization for Standardization, ISO/IEC 23894:2023, Artificial Intelligence, Guidance on Risk Management. https://www.iso.org/standard/77304.html

[^iso-42005]: International Organization for Standardization, ISO/IEC 42005:2025, AI System Impact Assessment. https://www.iso.org/sectors/it-technologies/ai

[^ilac-mra]: International Laboratory Accreditation Cooperation, ILAC Mutual Recognition Arrangement and Signatories. https://ilac.org/ilac-mra-and-signatories/

[^ilac-about]: International Laboratory Accreditation Cooperation, About ILAC. https://ilac.org/about-ilac/

[^ilac]: International Laboratory Accreditation Cooperation. https://ilac.org/

[^eu-ai-act]: European Union, Regulation (EU) 2024/1689 Laying Down Harmonised Rules on Artificial Intelligence. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng

[^eu-summary]: EUR-Lex, Rules for Trustworthy Artificial Intelligence in the European Union. https://eur-lex.europa.eu/EN/legal-content/summary/rules-for-trustworthy-artificial-intelligence-in-the-eu.html

[^oecd-principles]: OECD, OECD AI Principles. https://oecd.ai/en/ai-principles

[^oecd-observatory]: OECD.AI Policy Observatory. https://oecd.ai/

[^iso-casco]: International Organization for Standardization, CASCO Conformity Assessment Toolbox. https://casco.iso.org/

[^iso-recognition]: International Organization for Standardization, Recognition of Conformity Assessment Bodies. https://casco.iso.org/recognition-of-cabs.html


Revision Record

Version 1.0

Date: July 16, 2026

Change type: Complete foundational edition

Summary: Establishes the fully developed canonical working white paper for Foundation 8. Defines the global interoperability problem, shared and local layers, terminology, system identity, protocol and measurement interoperability, metadata, evaluator recognition, certification portability, incident exchange, secure evidence sharing, standards and legal crosswalks, multilingual evaluation, open-weight systems, capacity building, international institutions, recognition architecture, dispute resolution, governance, maturity, implementation, a Standards Body pilot, metrics, failure analysis, objections, evidence gaps, research agenda, standards implications, operational templates, scorecard, and current primary-source research basis.

Status: Ready for internal review and future expert critique.