From Governing AI to Competing in Safety

1. Introduction: The Missing Layer in AI Safety Governance

The contemporary AI governance landscape is no longer defined by an absence of frameworks. It contains lifecycle risk-management approaches, organizational management systems, statutory obligations, independent evaluation programs, incident-monitoring efforts, and a growing body of testing and assurance practice. The NIST AI Risk Management Framework (AI RMF 1.0), for example, organizes risk management around the functions Govern, Map, Measure, and Manage and is intended for voluntary use across the AI lifecycle (NIST, 2023). ISO/IEC 42001:2023 establishes requirements for an organizational artificial-intelligence management system and continual improvement (ISO, 2023). The European Union has coupled legal obligations for general-purpose AI with a voluntary Code of Practice intended to support compliance (European Commission, 2025). The United Kingdom’s AI Security Institute conducts independent evaluations while explicitly cautioning that its evaluations are not comprehensive declarations that a system is “safe” (AISI, 2024). Singapore’s AI Verify provides a testing framework and toolkit aligned with multiple governance principles (IMDA, 2026). The OECD AI Incidents Monitor seeks greater consistency and interoperability in learning from AI incidents and hazards (OECD, 2026).

These initiatives address different layers of the problem. They should not be collapsed into a single architecture. Law determines duties and public authority. Management standards organize institutional processes. Risk frameworks structure decisions. Evaluation institutes generate technical evidence. Incident systems preserve signals from real-world failures. The question developed here is narrower: what institutional mechanism could help safety tests themselves improve through structured reproduction and challenge?

This question matters because the actor best positioned to understand a system is not always the actor best positioned to validate claims about that system. Developers possess deep knowledge of architectures, training procedures, safeguards, and deployment constraints. That knowledge makes internal testing indispensable. Yet self-testing alone has an unavoidable evidentiary limitation: the same organization may define the risk, design the test, interpret the result, and decide whether a failure is material. Regulators can establish legal duties and compel evidence where authorized, but cannot realistically pre-write every technical test for systems and risks that evolve rapidly. Independent evaluators can provide external scrutiny, but methods, access conditions, disclosure practices, and reporting formats remain heterogeneous. Open technical communities can reproduce and improve methods, but unrestricted disclosure is inappropriate for some cyber, biological, model-control, privacy, or national-security evaluations.

The International AI Safety Test (IAST) is proposed as a response to this coordination problem. It is not presented as a regulator, a licensing authority, a certification body, or a universal benchmark. It is a proposed evidence infrastructure in which tests can be proposed, registered, executed, reproduced, challenged, revised, and retired. The institutional claim is intentionally limited: no single participant should be the sole authority for defining a risk, designing the test, interpreting the result, and determining how the test changes after failure.

Registration establishes provenance and procedural standing only; inclusion in the IAST registry does not authenticate or validate the underlying technical claim.

The article advances three related arguments. First, AI governance should distinguish governance of AI systems from governance of safety evidence. Second, the quality of safety evidence may improve when tests themselves become contestable objects of innovation, provided competition is constrained by reproducibility and governance safeguards. Third, this claim should be evaluated empirically through a bounded pilot rather than adopted institutionally by assertion. The resulting framework is designed to be falsifiable: the first test of IAST is IAST itself.

2. From Governing AI to Governing Safety Evidence

2.1 Distinguishing authority from evidence

A recurring problem in technology governance is the tendency to treat technical evidence and legal permission as interchangeable. They are not. A test result can inform a regulator, procurement officer, insurer, certification body, court, developer, or deployer without acquiring the authority of any of those institutions. IAST therefore begins with a strict boundary: its output is structured evidence, not permission.

Participation in IAST would not reduce existing legal duties or liability. If a public authority, insurer, standards body, procurement organization, or court later chooses to rely on a class of IAST evidence, the legal or institutional effect would derive from that relying body’s own authority. IAST itself would not create a safe harbor. It would not authorize an organization to issue an “IAST certification,” and a certification body referencing an IAST record would remain responsible for its own certification decision.

This separation is not merely defensive drafting. It is central to the institutional design. If an evidence infrastructure becomes the source of permission, pressures to capture the infrastructure increase. If, instead, the infrastructure preserves provenance, methods, limitations, reproduction history, challenges, and status changes, multiple institutions can use the evidence while retaining responsibility for the decisions they make with it.

2.2 Complementarity with existing frameworks

IAST is best understood as a potential evidence layer that can interact with, rather than replace, existing frameworks. NIST’s AI RMF provides a lifecycle vocabulary for mapping, measuring, and managing risk; a versioned IAST test record could supply technical artifacts, limitations, and challenge history to support those activities. ISO/IEC 42001 establishes an organizational management system and continual-improvement process; structured test evidence could become one auditable input to monitoring, evaluation, and improvement. EU legal obligations remain legal obligations; IAST evidence could at most support documentation or evaluation where accepted by competent authorities. National evaluation institutes can continue conducting public-interest testing while using common record structures or cross-institution reproduction where lawful.

The relevant concept is evidence portability, not automatic equivalence. A crosswalk between an IAST field and an external framework should be version-controlled and illustrative unless the relevant authority formally recognizes it. Portability depends on whether a record preserves enough information about scope, provenance, method, access conditions, uncertainty, limitations, and challenge history to be meaningfully reused. It should never be marketed as a shortcut around law.

3. Why Safety Testing Should Become Contestable

3.1 The test as an object of innovation

AI competition is usually discussed in terms of model capability, product performance, cost, deployment speed, or market share. IAST asks whether a portion of that competitive energy can be redirected toward the quality of safety testing itself. A participant that identifies a new risk can propose a test. Other participants can reproduce the test, challenge assumptions, identify leakage or architecture bias, expose gaming opportunities, or submit a stronger successor. The test is therefore not a fixed instrument imposed from above; it becomes an object that can improve through criticism.

The proposed lifecycle is: Discover → Propose → Register → Test → Reproduce → Challenge → Revise → Retire or Replace. This sequence rejects two extremes. On one side is purely internal evaluation, where evidence may never leave the organization that generated it. On the other is a universal benchmark treated as a permanent public ranking. IAST instead treats tests as versioned claims with histories. A test can gain evidentiary standing through reproduction and lose standing when assumptions fail, gaming becomes material, or a stronger successor appears.

Registration makes a test or claim visible, versioned, and challengeable; it does not by itself increase methodological reliability. Evidentiary weight changes only through the evidence actually produced, reproduced, challenged, and bounded by stated limitations.

3.2 Competition is not a safety score

The term “competition” creates an immediate risk of misunderstanding. IAST does not propose a single leaderboard declaring which model, company, or country is safest. Such a score would invite aggregation across incomparable risks, reward optimization against visible metrics, and encourage political or commercial misuse. The intended competition is multidimensional: Who discovers a material risk that others missed? Whose test can be reproduced? Which method survives hidden variants? Which challenge exposes a false sense of security? Which mitigation changes the result on re-test?

This distinction also limits what an IAST record may claim. A system that performs well on one registered test has performed well under the stated conditions of that test. It has not been shown to be universally safe. A negative result is evidence of a bounded failure under defined conditions, not proof that every deployment is unsafe. The architecture is therefore built around bounded claims rather than categorical labels.

3.3 Why competition can fail

Competitive mechanisms can generate exactly the behavior they are intended to correct. Participants may select easy tests, optimize visible benchmarks, suppress unfavorable findings, flood the registry with low-value activity, use funding to shape the agenda, or convert technical disputes into geopolitical signals. A successful framework therefore cannot assume that competition is inherently beneficial. It must make anti-gaming and institutional failure part of the research design.

The proposed safeguards include independent reproduction, hidden variants where appropriate, conflict disclosure, payment independent of favorable outcomes, bounded disclosure for sensitive tests, explicit challenge and appeal procedures, and retirement of obsolete or gameable tests. Negative findings are presumptively disclosed at the maximum safe level; security, privacy, legitimate trade-secret, and lawful national-security constraints may justify bounded disclosure, but a negative result should not disappear merely because it is inconvenient.

4. An Analytical Model of Safety-Evidence Quality

4.1 Three dimensions: contestability, reproducibility, and provenance

The IAST proposal can be expressed analytically through three dimensions. Contestability asks whether a test, result, or interpretation can be challenged by eligible parties using a defined process. Reproducibility asks whether an independent evaluator can rerun the method, or a materially equivalent method, under documented conditions. Provenance asks whether the record preserves who proposed the test, what system and deployment context were examined, what data and access conditions applied, what conflicts existed, what changed over time, and how disputes were resolved.

These dimensions are related but not interchangeable. A highly reproducible test can still be irrelevant if it measures the wrong risk. A contestable test can still produce weak evidence if challengers lack access to artifacts. A richly documented record can still be misleading if no independent party can inspect the relevant behavior. The purpose of the framework is therefore not to reduce evidence quality to a single equation, but to make these dimensions visible enough that relying institutions can judge what a record actually supports.

4.2 Evidence status without a single hierarchy

For pilot purposes, the Technical & Pilot Framework should record evidence through separate dimensions rather than a single L1–L4 sequence. Claim origin identifies whether a result begins as a registered internal claim or is generated by an independent evaluator. Reproduction status records whether the claim has not yet been independently reproduced, has been independently reproduced, or has been reproduced by multiple independent parties with documented variance and limitations. Institutional observation is recorded separately, including whether a competent public authority observed or participated under its own authority. These dimensions describe different properties of the record; none is a universal safety grade.

Public-authority observation strengthens institutional provenance and may matter for accountability, but it does not by itself increase methodological reliability. A registered internal claim remains an internal claim until independent examination changes its reproduction status. Likewise, closed access does not automatically weaken or strengthen evidence. A closed system may be evaluated through controlled API access, secure environments, escrowed artifacts, or supervised runs. An open-weight system may permit deeper artifact inspection. The permitted claim should be bounded by what evaluators could actually observe, not by institutional prestige or ideological preference for one access model.

4.3 The test record as institutional memory

A reusable safety-evidence system requires more than a score. The proposed Test Record Schema includes a persistent test identifier and version; proposer and conflicts; risk hypothesis; system and deployment scope; data source and access conditions; method; metrics and thresholds; disclosure tier; claim origin and reproduction status; institutional-observation status; temporal-validity and revalidation status; results; limitations; mitigation and re-test; challenge history; cost and elapsed time; and publication status. The record is designed to preserve not only successful evidence but disagreement, uncertainty, and change.

This design matters because institutional memory is often lost when a benchmark is updated or a result is summarized for public communication. A successor test should preserve lineage to the test it replaces. A retired test should remain discoverable with its reason for retirement, date, successor link, and appeal history. The objective is not to prevent change but to make change inspectable.

Evidence should also be time-bounded. Each record should identify the tested model or system version, deployment conditions, safeguard configuration, test date, and explicit revalidation triggers. A material change in the model, tools, permissions, deployment environment, safeguards, or test conditions should move the record to “revalidation required” rather than allowing an old result to persist as if nothing changed. A fixed expiry period may be appropriate in some domains, but the pilot should test whether event-based revalidation is more informative than a universal calendar expiry.

5. Governance Without a Single Governor

5.1 Distributed roles

IAST is deliberately not organized around a single global governor. Government, industry, evaluators, researchers, standards organizations, and open communities have different legitimate functions. Government retains law enforcement, emergency authority, public accountability, and procurement powers. Providers and deployers retain responsibility for products, system access, deployment decisions, and representations they make. Independent evaluators are responsible for methodological integrity, reproducibility discipline, confidentiality, and reporting. Standards and assurance organizations may test whether evidence is reusable in existing workflows. The IAST secretariat or registry steward manages process, provenance, and records rather than declaring systems safe.

Within a pilot, technical adjudication should also be separated from money. A Technical Review and Appeals Panel can decide methodological disputes, evidence-status changes, suspensions, retirement, and appeals with recusal rules. A separate Funding and Independence Committee can oversee pooled funding and evaluator-selection procedures. Funders may nominate risk domains, but should not choose a favorable evaluator for their own system or condition payment on outcome. Evaluators should be paid for work performed, not for passing results.

5.2 Government: authority without benchmark micromanagement

Public authority remains essential, but its role should not be confused with writing every future test. Governments can establish duties, require evidence proportionate to risk, convene participants, support secure information sharing, use procurement leverage, and retain emergency powers where law permits. At the same time, an IAST record should not become the sole basis for a compliance determination, and governments should not force IAST to become a de facto certification monopoly.

This arrangement reflects a broader principle: AI does not enter a separate civilization of law. Existing legal domains—including fraud, privacy, negligence, discrimination, contracts, consumer protection, professional responsibility, and safety—continue to apply where relevant. New rules may be needed when genuine gaps emerge, but participation in technical testing cannot displace those duties.

5.3 International cooperation through interoperability

International AI governance often becomes trapped between two unattractive choices: fragmented national systems or an unrealistically centralized global authority. IAST proposes a narrower route based on interoperability. Jurisdictions or institutions can recognize common record structures, evaluator qualifications, provenance rules, controlled-disclosure practices, and reproduction procedures without surrendering sovereign legal authority.

Where raw data cannot cross borders, a locally qualified evaluator could execute an agreed method and export an attested evidence artifact with sufficient provenance for challenge. Technical disputes may be mediated through agreed neutral processes; legal disputes remain with competent jurisdictions. Recognition arrangements should contain suspension and withdrawal triggers, notice rules, transition treatment for in-flight evaluations, and preservation of the provenance of older evidence. Recognition of evidence should not imply mutual recognition of regulation.

6. A Falsifiable Pilot Rather Than a New Institution

6.1 Research question and domains

The core research question is empirical: Can competitive, reproducible, and challengeable testing discover material risks and improve safeguards more effectively than isolated testing alone? The appropriate first step is therefore not an international launch, but a bounded pilot in one or two low-information-hazard domains.

Candidate domains include enterprise-agent prompt-injection resilience, uncertainty or confidence disclosure, and tool-permission robustness. These candidates are not endorsements. Each carries methodological cautions: prompt-injection work can create information hazards; uncertainty metrics can reward performative hedging rather than truthfulness; tool-permission tests require realistic sandboxing and clear authorization boundaries. Final selection should use explicit criteria such as public-interest value, reproducibility, manageable information hazard, measurable outcomes, architecture neutrality where possible, realistic cost, and a credible path to changing an actual safeguard or deployment decision.

6.2 Comparative design

The pilot should compare developer-proposed tests with independent-party-proposed tests. This comparison is important because IAST does not assume that independent actors are always better testers. Developers may identify subtle failures because they understand internal architecture and deployment context. Independent parties may identify blind spots created by organizational incentives or assumptions. The relevant question is whether the two sources produce materially different discovery yield, reproducibility, resistance to gaming, and downstream changes.

A 12-month pilot can proceed in five phases: Convene (months 0–2), Pre-register (months 2–4), Compete and reproduce (months 4–8), Challenge (months 8–10), and Evaluate IAST (months 10–12). Before testing begins, the pilot should freeze the record schema, evaluator qualifications, disclosure rules, conflict procedures, intellectual-property rules, and stop/redesign criteria. This precommitment is necessary to reduce the temptation to rewrite governance after an unfavorable result.

6.3 Outcome and governance metrics

Success should not be measured by the number of tests produced. Safety-evidence outcomes should include material risks discovered beyond participants’ baseline processes; independent reproduction rate and variance; tests strengthened or weakened after challenge; evidence of benchmark gaming; safeguards or deployment decisions changed because of findings; at least one real evidence-reuse case in procurement, assurance, or public-sector review; and cost and elapsed time per reusable independently or multi-party reproduced evidence package.

The governance mechanism itself should also be measured. Relevant indicators include challenge-to-disposition time, negative-result disclosure rate, evidence reuse outside the registry, funding concentration and conflict-disclosure compliance, challenge-upheld and appeal-modification rates, participant retention after unfavorable findings, and completeness of retirement and successor histories. These metrics turn institutional integrity into an observable pilot outcome rather than a background assumption.

6.4 Stop and redesign criteria

A serious pilot must define failure in advance. The Pilot Governance Group should pause or redesign the experiment if benchmark gaming becomes persistent, dominant participants capture the agenda, independent reproduction is economically impractical, negative findings are systematically suppressed, funding conflicts remain unresolved, security handling fails, or the process generates extensive documentation without meaningful changes to safeguards or deployment decisions. The pilot succeeds methodologically only if it can produce evidence against IAST as well as evidence for it.

7. From Incidents to Tests: Closing the Learning Loop

A safety-evidence infrastructure should learn not only from laboratory benchmarks but from incidents and hazards observed in deployment. The proposed Incident-to-Test Interface converts an incident pattern into a candidate risk hypothesis while preserving uncertainty about the underlying event. Minimum fields include source metadata, incident or hazard class, system and deployment context, evidence status, sensitive-information flags, a testable risk hypothesis, a link to a draft or active test, and a dispute record.

This interface is deliberately conservative. An event that cannot be sufficiently verified may enter an Unverified Hypothesis Pool, but it should not directly become an active benchmark candidate. Public reporting can justify investigation without establishing the incident as fact. Activation requires a testable hypothesis and independent methodological review. This distinction is important in a domain where public narratives can travel faster than verified technical evidence.

The OECD’s work on AI incidents illustrates why consistent definitions and interoperable monitoring matter for learning across jurisdictions (OECD, 2026). IAST would not replace incident-monitoring systems. Its proposed contribution is downstream: translate sufficiently grounded patterns into testable hypotheses and preserve the lineage from incident signal to test, challenge, mitigation, and re-test.

8. Human–AI Co-Evolution as a Separate Research Track

H2E’s broader research perspective treats real-world AI safety as an interaction among machine capability, human capability, and institutional context. The same technical system can produce different outcomes when users differ in verification behavior, escalation discipline, automation bias, domain expertise, or professional responsibility. This suggests a longer-term research question: should safety eventually be studied not only as a property of the machine, but also as a property of a changing Human–AI system?

The present proposal does not answer that question. More importantly, it does not use the hypothesis to weaken machine-level safeguards. Human capability remains outside the initial IAST Core pilot. Any later research should be preregistered, independently reviewed, use task-level behavioral outcomes, pre-defined endpoints, and sample-size justification, and avoid ranking nationality, culture, or demographic groups. Until causal validity is established, human-capability evidence should not be used to lower technical safeguards, legal protections, procurement requirements, or regulatory thresholds.

This separation preserves two ideas simultaneously. First, long-term Human–AI co-evolution may require education, institutional design, and civic capability to become legitimate safety research domains. Second, speculative claims about human capability should not become a convenient mechanism for transferring responsibility away from developers, deployers, or institutions that control technical risk.

9. Discussion: What IAST Would and Would Not Change

9.1 The potential value proposition

If the pilot works, IAST could provide value without becoming a new regulator. A reusable record might reduce duplicated assurance work, reveal failures earlier, make supplier risk evidence more legible, and allow procurement or public-sector reviewers to inspect provenance rather than accept a vendor’s summary. Cross-institution reproduction could also make it harder for a favorable result to persist solely because no one else can examine it.

For companies, however, participation cannot be assumed. The business case is itself a hypothesis. Participation is likely to persist only if evidence is technically useful, costs remain proportionate, sensitive information can be protected, and negative findings are handled predictably. One of the strongest pilot indicators is therefore participant retention after unfavorable results. Enthusiasm before testing begins is weak evidence of institutional durability.

9.2 Risks of capture and safety theater

The most serious failure mode may be a framework that appears rigorous while changing little. A registry can accumulate records without improving decisions. Evidence-status labels can become badges. Independent evaluators can become economically dependent on the organizations they evaluate. Governments can treat a voluntary record as a convenient proxy for compliance. Companies can learn to optimize the benchmark rather than the underlying safety property. International recognition can become a trade instrument or geopolitical signal.

These risks cannot be eliminated by drafting. They can only be exposed through governance design and measurement. That is why funding concentration, conflict disclosure, negative-result publication, challenge outcomes, evidence reuse, and actual safeguard changes are pilot metrics. A framework that produces paperwork without changing safety decisions should count as failure, not maturity.

9.3 Responsibility remains distributed

IAST also does not solve the underlying allocation of legal responsibility. If a provider submits an evidence package while withholding a known material limitation, the existence of the IAST record does not transfer the provider’s responsibility to the evaluator, insurer, procurer, or registry. Conversely, an evaluator remains responsible for the integrity of its method and representations. The IAST process is responsible for its own procedural integrity. Each actor retains responsibility for the decisions and claims within its authority.

This distributed responsibility is a feature rather than a defect. The purpose of a shared evidence arena is not to create a single institution that absorbs all accountability. It is to make the boundaries among evidence production, technical judgment, commercial deployment, and public authority more visible.

10. Conclusion

The central problem addressed in this article is not whether AI needs governance. It is whether the production of AI safety evidence can itself be governed in a way that remains open to challenge, reproduction, improvement, and failure. Existing legal, standards, risk-management, evaluation, and incident-monitoring institutions already provide essential pieces. IAST proposes a connective layer rather than a replacement for them.

The proposal rests on a narrow claim. Competition does not automatically produce safety. But competition in risk discovery and test quality, constrained by independent reproduction, anti-gaming measures, disclosure rules, conflict controls, explicit challenge procedures, and bounded institutional roles, may produce stronger evidence than isolated testing alone. That claim should not be accepted because it sounds plausible. It should be tested.

A bounded pilot can compare developer-proposed and independent-party-proposed tests, measure reproducibility and gaming, observe whether evidence changes real safeguards or deployment decisions, and test whether records can be reused in existing assurance and public-sector workflows. It can also measure whether the governance system survives unfavorable findings, funding conflicts, disputes, and retirement decisions. If it cannot, the appropriate result is redesign or termination.

IAST therefore represents a shift in emphasis: from asking only who governs AI to asking how societies govern the evidence by which AI safety claims are made. Its ambition is not to declare a safer world into existence, but to create a disciplined arena in which safety claims can become more inspectable, more reproducible, and more contestable. The first test of IAST is IAST itself.

Notes

1. “IAST” in this article refers to the proposed International AI Safety Test evidence infrastructure developed in the two H2E source documents reproduced as Appendices A and B. It is not an existing certification authority.

2. The term “competition” refers to competition in risk discovery, test quality, reproducibility, challenge, and response to evidence. It does not refer to a universal model-safety leaderboard.

3. “Evidence portability” means that a structured record may be reusable by another institution. It does not imply legal equivalence or automatic regulatory recognition.

4. IAST separates claim origin, reproduction status, and institutional observation. Registration establishes provenance and procedural standing, not validation; public-authority observation does not by itself establish methodological reliability.

5. The Human–AI capability track is intentionally separated from the initial Core pilot so that hypotheses about human capability cannot be used to reduce technical or legal safeguards before measurement validity is established.

AI-Use Disclosure

Generative AI tools were used during the development of this article for drafting assistance, language editing, structural comparison, source organization, and document preparation. The conceptual framework, research questions, policy propositions, selection and interpretation of sources, revisions, and final responsibility for the article remain with the author. AI-generated suggestions were reviewed and revised by the author before inclusion.

Acknowledgments

The author gratefully acknowledges the essential architectural and technical contributions of the H2E Solutions Working Group members who shaped the tripartite foundation of this proposal:

• Steven James Stobo (Community Manager, H2E; Founder & CEO, WeRAI AI Integration Inc.) for formulating the Consequential Execution Boundary and G=1 Human Authority Gate (USPTO Provisional Patent #63/900,179), establishing the critical interface where synthetic logic transitions from probabilistic tokens to physical, financial, and network state committal.

• Frank Morales Aguilera, BEng, MEng, SMIEEE, for developing the internal structural determinism framework and the ISO/IEC AI-QE 2026 quality assurance alignment model, enforcing tensor invariants and schema adherence before context boundaries.

• Ryan Feller for architecting the Recomputable Evidence and Test Lineage framework, establishing Governance Fixture 001, and enforcing the explicit lifecycle discipline governing proposal standing.

The author also thanks Wilson Guenther (Secretary-General), Twyla Jackson (Editor-in-Chief), and the broader H2E community for their critical review and iterative stress-testing across the Exploring and Solutions tracks.

References

1. AI Security Institute (AISI). (2024). AI Safety Institute approach to evaluations. UK Department for Science, Innovation and Technology. Accessed September 21, 2026.

2. European Commission. (2025). The General-Purpose AI Code of Practice. Published July 10, 2025; status checked September 21, 2026.

3. H2E Solutions Working Group (Gao, J., Stobo, S. J., Morales Aguilera, F., Feller, R., et al.). (2026a). IAST — International AI Safety Test: A Competitive and Reproducible Framework for AI Safety Evidence. H2E Think Tank Report, Release Candidate. Humanity to Eternity, September 2026. Reproduced in full as Appendix B.

4. H2E Solutions Working Group (Gao, J., Stobo, S. J., Morales Aguilera, F., Feller, R., et al.). (2026b). IAST Technical & Pilot Framework v0.1: Operational Architecture for a Bounded Pilot. Humanity to Eternity, September 2026. Reproduced in full as Appendix A.

5. Infocomm Media Development Authority (IMDA). (2026). Artificial Intelligence in Singapore: AI Verify. Government of Singapore. Accessed September 21, 2026.

6. International Organization for Standardization (ISO). (2023). ISO/IEC 42001:2023, Information technology — Artificial intelligence — Management system. Geneva: ISO.

7. National Institute of Standards and Technology (NIST). (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1. Gaithersburg, MD: U.S. Department of Commerce.

8. National Institute of Standards and Technology (NIST). (2024). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1. Gaithersburg, MD: U.S. Department of Commerce.

9. Organisation for Economic Co-operation and Development (OECD). (2026). AI Incidents Monitor (AIM): Overview and methodology. OECD.AI. Accessed September 21, 2026.

10. Morales Aguilera, F. (2026). ISO/IEC AI-QE 2026: The Architectural Blueprint for Deterministic Quality Assurance in Artificial Intelligence Systems. IEEE Community / Medium publication.

11. Stobo, S. J. (2026). Human Router Operating System (HROS) and Consequential Execution Boundary Architecture. USPTO Provisional Patent Application #63/900,179. WeRAI AI Integration Inc.

APPENDIX A

IAST

International AI Safety Test

A Competitive and Reproducible Framework
for AI Safety Evidence

THINK TANK REPORT | RELEASE CANDIDATE

H2E — Humanity to Eternity

September 2026

Explore-Stage Policy Proposal | Pilot Candidate | Not a Certification Scheme

IAST — International AI Safety Test

Think Tank Report: Making AI Safety a Field of Innovation, Evidence and Cooperation

H2E Solutions Working Group — Core Architecture Contributors:
• John Gao — Convener, H2E (Lead Rapporteur)
• Steven James Stobo — Community Manager, H2E; Founder & CEO, WeRAI AI Integration Inc. (Track Lead: Consequential Execution Boundary & G=1 Hardware Committal Gate; USPTO Provisional Patent #63/900,179)
• Frank Morales Aguilera, BEng, MEng, SMIEEE — Senior Technical Contributor (Track Lead: Internal Structural Determinism & ISO/IEC AI-QE 2026 Invariants)
• Ryan Feller — Senior Governance Contributor (Track Lead: Recomputable Evidence, Test Lineage & Governance Fixture 001)
• In collaboration with Wilson Guenther (Secretary-General), Twyla Jackson (Editor-in-Chief), and the H2E Builder Community.

Attribution & Provenance Notice: This Think Tank Report reflects collective inquiry and architectural synthesis developed within H2E Solutions. Specific technical mechanisms, frameworks, and patents contributed by working group members—including the WeRAI G=1 Consequential Execution Boundary (USPTO #63/900,179) and ISO/IEC AI-QE 2026—remain the exclusive intellectual property and prior art of their respective originating authors, referenced herein under an open, non-exclusive license for academic and public-interest evaluation.

H2E • Release Candidate • September 2026 • Explore-stage proposal | Pilot candidate | Not a certification scheme

Policy question: Can a shared arena for competitive, reproducible and challengeable testing improve AI safety evidence without creating a new global regulator?

IAST is proposed as a voluntary, multi-stakeholder evidence infrastructure. It produces structured evidence, not permission. It does not issue licenses, legal approvals, universal safety certifications, or legal safe harbors.

This report explains the policy case, institutional boundaries and public-interest rationale. Detailed schemas, evaluator rules, challenge procedures and pilot operations are separated into the companion IAST Technical & Pilot Framework v0.1.

Executive Summary

AI safety policy is moving from broad principles toward testing, assurance, incident reporting and operational accountability. Existing frameworks already provide important pieces: risk-management processes, management systems, legal duties, model evaluations and international coordination. The remaining question is whether the tests themselves can improve faster through structured challenge and reproduction.

IAST proposes a shared arena in which developers, independent evaluators, researchers and open communities can propose tests, reproduce results, challenge assumptions and improve successor tests. The competition is not a single safety score. It is competition in risk discovery, test quality, reproducibility, resistance to gaming and response to evidence.

Government remains responsible for law, accountability, emergency authority and public-interest coordination. Companies remain responsible for their products and deployments. Independent evaluators remain responsible for the integrity of their evidence. IAST connects those roles; it does not replace them.

The first operational recommendation is deliberately narrow: run a bounded pilot and compare developer-proposed tests with independent-party-proposed tests. Measure whether the process discovers material risks, survives reproduction and challenge, changes real safeguards or deployment decisions, and produces evidence that can be reused in existing assurance workflows.

The first test of IAST is IAST itself.

1. Why Another AI Safety Mechanism?

The problem is not the absence of AI governance. The problem is fragmentation. Internal safety teams often possess the deepest system knowledge, yet evidence based only on self-testing carries an unavoidable conflict of interest. Regulators can establish duties and boundaries, but cannot pre-write every future technical test. Independent evaluators can challenge developers, but their methods and results are often difficult to compare or reuse. Open-source communities can reproduce and improve methods, but not every high-risk test can safely be public. Furthermore, current safety evaluations frequently fall into the 'Sandbox Fallacy'—measuring synthetic outputs solely within conversational isolation while ignoring the consequential execution boundary where models commit actions to external databases, financial networks, and physical infrastructure. A robust safety infrastructure must test not only internal model behavior, but whether the system respects deterministic, fail-closed human authority gates before state mutation occurs.

IAST therefore starts from a simple institutional principle: no single participant should be the sole authority for defining a risk, designing the test, interpreting the result and correcting the test when it fails.

Internal testing remains valuable. An internal result should enter IAST as a registered internal claim with preserved provenance, not as independently validated evidence. Its evidentiary weight should rise only through the independent reproduction, challenge, and methodological scrutiny actually achieved.

2. The IAST Proposal: Compete in Testing Risk

IAST changes the incentive structure without asking companies to stop competing. A participant that discovers a new risk can propose a test. Others can run it, challenge its assumptions, expose gaming opportunities, or propose a stronger successor. The test itself becomes an object of innovation.

The intended cycle is: Discover → Propose → Test → Reproduce → Challenge → Revise → Retire or Replace. A test is never treated as permanent truth, and a model is never stamped universally “safe.”

Figure 1. The IAST competition concept. Competition is directed toward better tests, risk discovery, reproduction and challenge—not a single universal safety ranking.

Benchmark competition can fail. Participants may optimize visible metrics, choose favorable domains, suppress negative findings or dominate the agenda. IAST is therefore plausible only with independent reproduction, anti-gaming measures, conflict disclosure, bounded disclosure for sensitive tests, and explicit challenge and retirement procedures.

3. Institutional Status: Evidence, Not Permission

IAST should begin as voluntary technical infrastructure, not as a regulator, certification body or source of legal authority. Participation does not reduce existing legal duties or liability. If a regulator, procuring agency, court, insurer or standards body later chooses to rely on a class of IAST evidence, that reliance derives from its own authority—not from IAST.

Registration and validation must remain distinct. Inclusion in the IAST registry establishes provenance, versioning, and procedural standing; it does not authenticate the underlying technical claim, certify a system, or create a presumption of compliance.

4. Complement Existing Frameworks, Do Not Replace Them

IAST should be designed for evidence portability. A well-structured test record can be reused inside an organization’s existing risk-management, assurance, procurement or regulatory documentation. That value proposition must be tested in real workflows.

Any crosswalk should be version-controlled and illustrative unless formally recognized by the relevant authority. IAST should not market interoperability as legal equivalence.

Evidence portability also requires temporal validity. Records should identify the tested system/version and deployment conditions and should carry explicit revalidation triggers when material changes occur. An older record may remain discoverable for lineage, but it should not silently retain “current” standing after the model, safeguards, permissions, environment, or test conditions materially change.

5. Government: Coordinate, Enforce Law, Preserve Emergency Authority

AI does not need a separate civilization of law. When AI enters society, existing duties concerning fraud, discrimination, privacy, negligence, consumer protection, contracts, professional practice and safety continue to matter. New rules may be needed where genuine gaps appear, but technical participation cannot displace law.

Government’s IAST role is broader than writing rules and narrower than becoming the engineer of every benchmark. Public authorities can convene participants, establish accountability expectations, use procurement leverage, support secure information sharing, require evidence appropriate to high-risk uses and retain emergency powers where law permits.

Government → coordinate and enforce boundaries. Labs → build and test. Independent evaluators → reproduce and challenge. IAST → connect the evidence.

6. Why Companies Might Participate

The business case should be treated as a hypothesis, not a promise. A credible shared evidence infrastructure could reduce duplicated assurance, reveal failures earlier, improve supplier risk management and make safety work more legible to customers and public buyers. Participation will be durable only if the evidence is technically useful, costs are proportionate, negative findings are handled predictably, and sensitive information can be protected.

The pilot should test a hard question: after an unfavorable result, do serious participants remain willing to participate? Retention after bad news is a stronger signal than enthusiasm before testing begins.

7. International Cooperation Without a Global Governor

IAST should not begin by asking states to surrender legal authority to a supranational safety body. A more credible path is incremental interoperability: common record formats, evaluator qualification rules, provenance, controlled disclosure, reproduction procedures and neutral technical mediation.

Recognition should be portable but bounded. If raw data cannot cross borders, a locally qualified evaluator can execute an agreed method and export an attested evidence artifact with sufficient provenance for challenge. Technical disagreements can be mediated; legal disagreements remain with competent jurisdictions.

Public-authority observation can strengthen institutional provenance and accountability, but it should not be treated as a higher methodological grade by itself. Methodological reliability depends on the test design, access, execution, reproduction, limitations, and challenge record.

Pilot → bilateral interoperability → multi-institution reproduction → network recognition → possible standards adoption.

8. Human–AI Safety: A Parallel H2E Research Track

H2E’s broader thesis is that real-world outcomes eventually depend on the interaction among machine capability, human capability and institutional context. The same AI system can produce different outcomes when users differ in verification behavior, escalation discipline, automation bias and responsibility. In the WeRAI Human Router framework, true co-evolution ensures that human agency and critical discernment are multiplied rather than atrophied. This demands an architectural axiom: Capability ≠ Authority. Machine capability may scale exponentially, but the authority to commit irreversible state changes must remain firmly anchored to human responsibility.

That idea should not be used in the initial IAST Core pilot to lower technical safeguards, legal protections, procurement requirements or regulatory thresholds. It belongs in a parallel research track until measurement validity and causal relevance are independently established.

Figure 2. H2E’s longer-term Human–AI co-evolution vision. This is a conceptual future-state illustration, not the IAST governance structure; human-capability elements remain outside the initial IAST Core pilot.

If later evidence supports the hypothesis, AI safety would no longer be treated only as a property of the machine, but also as a property of a changing Human–AI system. Education, institutional design and civic capability would then become safety research domains rather than substitutes for technical safeguards.

9. A Bounded Pilot Before Scale

The recommended next step is not an international launch. It is a narrow pilot in one or two low-information-hazard risk domains. Candidate domains include enterprise-agent prompt-injection resilience, uncertainty disclosure, and tool-permission robustness. Final selection should be made with participating evaluators and providers using explicit criteria: public-interest value, reproducibility, manageable information hazard, measurable outcomes and realistic cost.

Stop or redesign the pilot if competition consistently increases gaming, dominant participants capture the agenda, independent reproduction proves economically impractical, negative findings cannot be disclosed even in bounded form, or the process generates paperwork without changing safety decisions.

10. Policy Recommendations

• Publish a stable policy charter that fixes IAST’s legal boundary: evidence, not certification or permission.

• Keep the Think Tank Report separate from the Technical & Pilot Framework so policy principles can remain stable while operational rules evolve.

• Recruit a small cross-sector pilot group: providers/deployers, independent evaluators, researchers, an open-source representative where relevant, standards expertise and a public-sector observer.

• Select one or two bounded pilot domains using transparent criteria rather than choosing a politically symbolic high-risk domain first.

• Pre-register evaluator qualification, conflict rules, negative-result disclosure, evidence-status dimensions, temporal revalidation triggers, challenge procedures and stop/redesign criteria before testing.

• Require at least one real evidence-reuse case in an existing assurance, procurement or public-sector workflow.

• Keep Human–AI capability research parallel to, and methodologically separate from, the initial Core pilot.

• Publish failures, unresolved disagreements and redesign decisions as part of the pilot result.

Conclusion

IAST does not claim that competition automatically produces safety. It proposes a narrower and testable idea: competition, when constrained by independent reproduction, challenge, anti-gaming mechanisms, disclosure rules and explicit governance, may produce better safety evidence than isolated testing alone.

Government remains responsible for law and public accountability. Enterprises remain responsible for products and deployments. Evaluators remain responsible for the integrity of their work. IAST is the shared evidence arena among them.

The first test of IAST is IAST itself.

Selected Reference Frameworks

• NIST AI Risk Management Framework (AI RMF 1.0)

• NIST Generative AI Profile (AI 600-1)

• ISO/IEC 42001 — AI management systems

• European Commission — General-Purpose AI

• UK AI Security Institute

• OECD AI Incidents Monitor

Status/access checked September 20, 2026. Framework mappings are illustrative unless the relevant authority formally recognizes them.

EXHIBIT B

IAST

Technical & Pilot Framework

International AI Safety Test
Operational Architecture for a Bounded Pilot

VERSION 0.1 | PILOT DRAFT

H2E — Humanity to Eternity

September 2026

Draft for Technical Review and Pilot Collaboration | Not a Certification Standard | Not a Legal Safe Harbor

IAST — Technical & Pilot Framework v0.1

Operational Architecture for Competitive, Reproducible and Challengeable AI Safety Testing

H2E • Companion to the IAST Think Tank Report • September 2026 • Pilot protocol draft

Purpose: turn the IAST policy hypothesis into a bounded, auditable experiment that can succeed, fail, or be redesigned.

Policy anchor: see the companion Think Tank Report §3 (Institutional Status), §5 (Government), §7 (International Cooperation), §8 (Human–AI research boundary), and §9 (bounded pilot). Where policy and operational text conflict, the stable policy charter controls.

IAST is proposed as voluntary, multi-stakeholder evidence infrastructure. It produces structured safety evidence, not permission. It does not issue licenses, legal approvals, universal safety certifications or legal safe harbors. Participation does not reduce existing legal duties or liability. This Technical & Pilot Framework operationalizes that boundary and is subordinate to the companion Think Tank Report’s institutional-status statement.

1. Pilot Scope and Research Question

Core research question: Can competitive, reproducible and challengeable testing discover material risks and improve safeguards more effectively than isolated testing alone?

The first pilot should use one or two bounded, low-information-hazard domains. Three candidates are proposed for convening-stage selection:

Selection criteria: public-interest value, reproducibility, manageable information hazard, measurable outcomes, architecture neutrality where possible, realistic cost, and a credible path to changing an actual safeguard or deployment decision.

2. IAST Core Workflow

Discover → Propose → Register → Test → Reproduce → Challenge → Revise → Retire / Replace

Discover: identify a failure, hazard, incident pattern or untested assumption.

Propose: convert it into a falsifiable risk hypothesis and test method.

Register: record scope, provenance, conflicts, disclosure tier and version before comparative use. Registration creates a traceable record; it does not validate the underlying claim or test result.

Test: execute under documented conditions and preserve artifacts sufficient for the assigned disclosure tier.

Reproduce: an independent evaluator reruns the method or a materially equivalent method.

Challenge: contest validity, leakage, architecture bias, interpretation or gaming resistance.

Revise: successor tests preserve lineage and explain what changed.

Retire / Replace: obsolete or gameable tests remain discoverable with reason, date and successor link.

3. Test Record Schema v0.1

4. Evidence Status Dimensions

IAST does not treat evidence as a single L1–L4 ladder. Claim origin, reproduction status, and institutional observation are recorded separately. A registered internal claim is not independently validated merely because it appears in the registry. Public-authority observation strengthens institutional provenance but does not by itself establish methodological reliability. Closed access does not automatically lower or raise evidence weight; every claim remains bounded by what evaluators could actually observe.

5. Evaluator Qualification Criteria v0.1

At least two independent evaluators who did not draft this framework should pressure-test these criteria before participant onboarding. Qualification is domain-specific and time-bounded; it is not a permanent IAST credential.

6. Disclosure and Negative-Result Rules

Negative findings are presumptively disclosed at the maximum safe level. Redaction or withholding must identify the exception category: personal data, legitimate trade secret, security-sensitive exploit detail, national-security restriction, or other lawful prohibition. The fact that a bounded exception was used should remain visible where lawful.

A negative result may be redacted for safety; it should not disappear for convenience.

7. Challenge, Suspension, Appeal and Retirement

Retirement triggers include loss of discriminatory power, material gaming, invalid assumptions, unsafe disclosure, replacement by a stronger successor, or sustained inability to reproduce. Retired tests remain discoverable.

Temporal validity rule: every active evidence record must identify revalidation triggers. Material changes to the tested model/system version, tools, permissions, deployment environment, safeguards, data, or test conditions move the record to “revalidation required” until the relevant evidence is rerun or explicitly superseded. Domain-specific expiry periods may be used where justified, but calendar expiry does not substitute for event-based change detection.

7.4 Consequential Execution Boundary & G=1 Human Authority Interface (WeRAI / Steven Stobo Track)

Contributor: Steven James Stobo, Founder & CEO, WeRAI AI Integration Inc. (USPTO Provisional Patent #63/900,179)
Track: Consequential Execution Boundary & Physical Committal Governance
IAST Initial Standing: Contributor Proposition / Candidate Interface Mechanism

7.4.1 Problem Definition: The Sandbox Fallacy in AI Safety Testing

Current frontier AI safety evaluations suffer from what WeRAI defines as the Sandbox Fallacy: benchmarks measure exclusively what an AI model generates (probabilistic tokens inside an isolated text context), rather than what it commits to physical reality.

In safety-critical infrastructure—healthcare, mining tele-remote operations, aviation flight computers, power grids, and enterprise financial ledgers—harm does not occur when an LLM reasons through an exploit or hallucinated state. Harm occurs strictly when synthetic logic crosses the execution plane to mutate state:
• Issuing unauthorized API writes or database schema drops.
• Transmitting unverified financial settlements or wire transfers.
• Triggering physical actuators, switches, or machine controls.

Safety cannot be achieved by fine-tuning models to maintain polite conversational refusals (which adversaries bypass via prompt injection, jailbreaks, or uncensored open-weights instances). Safety must be enforced deterministically outside the model at the physical and operating system boundary.

7.4.2 Core Architectural Axiom: Capability ≠ Authority

Under the WeRAI G=1 Human Authority framework, an AI agent's operational state is governed by three non-negotiable axioms:
1. Capability ≠ Authority: An agent possessing the intelligence to compute an action, discover a network path, or optimize a workflow does not possess the authority to execute that action.
2. Reachability ≠ Standing: Being technically capable of transmitting a packet over a socket does not grant execution standing.
3. Fail-Closed Committal (G=1 Gate): Any operation that crosses an irreversibility boundary (state mutation) is blocked at the data plane (eBPF kernel filter / mTLS bearer token check) unless an unexpired, cryptographically signed human authorization token is explicitly presented at T=0.

7.4.3 Interface Boundary: What IAST Consumes

To preserve contributor sovereignty and non-inheritance of standing, IAST does not adopt WeRAI's internal proprietary operating system. Instead, IAST exposes a bounded, architecture-neutral Execution Boundary Test Harness (EBTH) that consumes three standardized interface mechanisms:

1. Irreversibility Boundary Classification Matrix: Defines the threshold between non-consequential operations (read-only queries, local simulation, draft synthesis) and consequential operations (external API invocation, credential exchange, database mutation, hardware control).
2. Fail-Closed Execution Gate Evaluation: Evaluates whether an autonomous agent pipeline respects external execution boundaries when authority tokens are expired, missing, or rejected by human review.
3. Cryptographic Execution Receipts (Audit Ledger): Every state transition attempt must produce an immutable, tamper-evident receipt (SHA-256 hash-chained log) linking Input Intent → Model Invariant State (AI-QE) → Human Authority Token (G=1) → Committed Physical Telemetry. If an action cannot be mathematically recomputed and verified against this chain, it is designated an unverified state breach.

7.4.4 Concrete IAST Examination Questions (Test Harness Specs)

The following four test harness benchmarks evaluate consequential execution containment:

7.4.5 Co-Evolution with Frank (AI-QE) and Ryan (Lineage)

• Frank Morales Aguilera (ISO/IEC AI-QE 2026): AI-QE guarantees internal model stability (100% Schema Adherence Rate, 0.0% NaN/Inf tensor invariants, cryptographic seed reproducibility).
• Ryan Feller (Recomputable Evidence): Ryan's track guarantees test lineage and governance provenance (immutable execution traces, preventing conversational standing drift).
• Steven Stobo / WeRAI (G=1 Execution Boundary): G=1 guarantees external physical containment (deterministic fail-closed gates at the hardware/network interface, preventing unauthorized real-world mutation).

Together, they establish the closed-loop standard: Internal Model Rigor (AI-QE) × Provable Test Lineage (Ryan) × Physical Committal Gate (G=1) = Verifiable Co-Evolution.

8. Pilot Governance and Funding

Pilot governance separates technical adjudication from money. The Secretariat manages registry and process. The Technical Review and Appeals Panel handles methodology disputes and status decisions. A Funding and Independence Committee oversees pooled funding and evaluator-selection procedures and reports directly to the Pilot Governance Group.

Registry inclusion is administrative and provenance-preserving. The Secretariat may check completeness, identity, versioning and procedural requirements, but registry acceptance must never be represented as technical validation, certification, or endorsement of the underlying claim.

Funding and Independence Committee members may not simultaneously serve as assigned evaluators or voting developer representatives in matters involving their funding decisions.

Use a mixed pool where practical; disclose funding concentration and aggregate allocations.

Funders may nominate risk domains but may not select a favorable evaluator for their own system or condition payment on outcome.

Evaluators are paid for work performed, not passing results.

Material financial relationships are disclosed before assignment; intentional concealment can trigger suspension or evidence downgrade.

H2E may convene or provide a pilot secretariat, but should not possess unilateral authority to declare systems safe.

8.1 Secretariat transition

If H2E convenes the pilot, governance-transition planning should begin no later than month 6—six months before the planned end of a 12-month pilot. Before pilot close, participants should decide whether registry, technical review, funding oversight and convening functions should remain together or be distributed among a standards body, research institution or neutral foundation. No transition may create an exclusive right to issue “IAST certification.”

9. Incident-to-Test Interface v0.1

An event that cannot be sufficiently verified may enter an Unverified Hypothesis Pool, but it cannot directly become an active benchmark candidate. Public reporting alone may justify a hypothesis for investigation, not a claim that the underlying incident is established fact. Activation requires a testable hypothesis and independent methodological review.

The Secretariat maintains the Unverified Hypothesis Pool. Entries are clearly labeled as unverified, are used only as leads for test proposals, and cannot enter the active registry until converted into a falsifiable risk hypothesis that passes the normal activation review. The pool is reviewed at least quarterly; stale entries that cannot be substantiated or operationalized are archived with provenance preserved.

Raw personal, proprietary or national-security information should not be copied into the public registry. Where cross-border transfer is restricted, sensitive data remain in the source jurisdiction and a locally qualified evaluator can export a bounded, attested evidence artifact.

10. Open-Weight and Closed-System Comparison

Compare outcome categories only when scientific comparability is defensible. Open-weight systems may permit artifact inspection and local reproduction. Closed systems may use controlled API access, secure evaluation environments, escrowed artifacts or supervised runs. Neither access model receives an automatic evidence advantage.

State what the evaluator could and could not inspect. This evaluator-observability statement is mandatory in the Test Record “Limitations” field and must be consistent with the assigned disclosure tier.

Do not infer internals that were not observed.

Use equivalent task definitions and outcome metrics where possible.

Report access constraints as limitations.

Cap the claim at the origin, reproduction, observability, institutional-observation, and temporal status actually supported by the record.

11. Bilateral Recognition and Withdrawal Template

Scope: recognized test domains, versions and disclosure tiers.

Evaluator rules: qualification, audit, suspension and re-qualification.

Records: common schema, provenance, version control and attestation requirements.

Local execution: procedure when raw data cannot cross borders.

Challenge: neutral technical mediation before recognition is withdrawn where feasible. If mediation fails, the dispute may be referred to a standards body, research institution or other neutral technical institution jointly accepted by the parties. If no technical resolution is reached, the agreement’s suspension/withdrawal terms govern; sovereign legal questions remain outside IAST adjudication.

Suspension/withdrawal triggers: material data leakage, repeated refusal of agreed appeals, evaluator interference, fraud, loss of qualification or unlawful political direction of a technical finding.

Notice: defined notice period except urgent security cases; reason must be recorded.

Transition: treatment of in-flight evaluations and already-issued evidence records.

Legacy evidence: withdrawal does not erase provenance; relying parties decide whether older evidence remains usable under their own rules.

Legal boundary: recognition of evidence does not create mutual recognition of regulation or sovereign legal duties.

12. 12-Month Pilot Plan

13. Pilot Metrics

13.1 Safety-evidence outcomes

Material risks discovered beyond participant baseline processes.

Independent reproduction rate and variance across evaluators.

Tests materially improved or weakened after challenge.

Evidence of benchmark gaming or architecture-specific advantage.

Safeguards, access controls, monitoring rules or deployment decisions changed because of findings.

At least one real evidence-reuse case in procurement, assurance or public-sector review.

External citation/use count for structured test records, distinguishing simple references from substantive evidence reuse.

Cost and elapsed time per reusable independently or multi-party reproduced evidence package.

13.2 Governance-performance outcomes

Median challenge-to-disposition time.

Negative-result disclosure rate: expected disclosures versus completed public/bounded disclosures.

Evidence reuse rate outside the pilot registry.

Funding concentration, conflict-disclosure compliance, and on-time publication of the Funding Allocation and Concentration Report.

Challenge-upheld rate and appeal-modification rate.

Participant retention after unfavorable findings.

Retired/superseded tests with complete reason, successor and appeal history.

14. Stop / Redesign Criteria

The Pilot Governance Group should pause or redesign the pilot when evidence shows that the mechanism itself is failing. Trigger conditions include persistent benchmark gaming, agenda capture by dominant participants, unaffordable independent reproduction, systematic suppression of negative results, unresolved funding conflicts, security handling failures, or extensive process activity without meaningful changes to safeguards or deployment decisions. Additional trigger: independent evaluators withdraw, or credibly report inability to continue, because of economic coercion, political pressure or retaliation connected to an evaluation outcome.

The pilot is successful only if it can produce evidence against IAST as well as evidence for it.

15. Human–AI Research Track Boundary

Human capability remains outside the initial IAST Core pilot. A later research track may study task-level behaviors such as uncertainty recognition, independent verification, appropriate escalation and automation-bias correction. Such studies should be preregistered, independently reviewed, use pre-defined endpoints and sample-size justification, and avoid ranking nationality, culture or demographic groups.

Until causal validity is established, human-capability evidence must not be used to lower technical safeguards, legal protections, procurement requirements or regulatory thresholds.

16. Insurance, Certification and Liability Boundaries

IAST does not price insurance, determine liability, certify insurability or authorize any certification body to issue an “IAST certification.” Insurers, ISO/IEC 42001 certification bodies or other assurance actors may independently reference an IAST record, but the meaning of that use comes from their own process.

IAST does not authorize any institution to issue an “IAST certification.” Certification bodies may independently reference IAST records, but may not represent their own certification as issued or endorsed by IAST. Test-record portability depends on schema completeness, provenance, versioning and traceability rather than official IAST endorsement.

Illustrative responsibility case: if a provider submits an IAST evidence package while withholding a known material limitation, the existence of the IAST record does not transfer the provider’s product or disclosure responsibility to IAST, the evaluator, an insurer or a procuring organization. Each actor retains responsibility for its own representation, deployment decision and professional duty under applicable law.

Counterexample: if an independent evaluator negligently omits a material limitation that its agreed method should have detected, the evaluator remains responsible for the integrity of its own method and report, while the IAST steward remains responsible only for the integrity of the registered process it actually administers. Neither role transfers the provider’s or deployer’s product, deployment, professional or statutory responsibilities.

Appendix A — Pilot Roles

Appendix B — Companion Documents to Freeze Before Testing

Test Record Schema v0.1

Evaluator Qualification Criteria v0.1

Conflict-of-Interest Disclosure Form

Negative-Result Disclosure Decision Rule

Controlled / Restricted Access Handling Procedure

Challenge and Appeal Form

Retirement / Successor Record

Funding Allocation and Concentration Report

Bilateral Recognition / Withdrawal Template

Pilot Pre-registration and Statistical Analysis Plan

Data Protection and Cross-Border Transfer Protocol

Appendix C — Reference Frameworks

NIST AI Risk Management Framework (AI RMF 1.0)

NIST Generative AI Profile (AI 600-1)

ISO/IEC 42001 — AI management systems

European Commission — General-Purpose AI

UK AI Security Institute

OECD AI Incidents Monitor

Status/access checked September 20, 2026. Any standards or regulatory crosswalk used in the pilot must be version-controlled and revalidated when the source framework changes.

European Commission — General-Purpose AI Code of Practice (published July 10, 2025; status checked September 20, 2026).

Singapore AI Verify Foundation — AI Verify Testing Framework (GenAI update released May 29, 2025; status checked September 20, 2026)