The AGI Standard

Document identifier: SF-AGI-STD-001 Version: 1.0-wd.2 (Working Draft, second revision) Status: Working Draft — circulated for Foundation Board review and Working Group input. NOT a ratified standard. Requirements are provisional and subject to substantial revision. Authoring body: The Sovereignty Foundation Date: 2026-05-07 Trademark: AGI™, AGI Certified™, AGI Compliant™ are certification marks of the Sovereignty Foundation. AGI is the abbreviation for Artificial Governed Intelligence in this document and in all Foundation publications.

Status of This Document

This document is a Working Draft, not a ratified standard. The Sovereignty Foundation publishes Working Drafts to invite review, feedback, and implementation experience that informs subsequent revisions. Nothing in this document constitutes a present obligation on any party. The Foundation is currently piloting this Working Standard in production environments to refine its requirements and demonstrate their validity in operation (see Section 10, Early Adopter Program). Certification against this Standard has not yet begun — no certification marks issue before v1.0 ratification — and the requirements below remain proposals for community refinement, not present compliance commitments.

The document follows IETF-style normative conventions per RFC 2119 / RFC 8174, with one extension specific to standards-development phase: requirements are categorized into CORE, PROPOSED, and FORWARD-LOOKING tiers reflecting their maturity. Tier definitions are in Section 3.

The Standards Development Schedule (Section 8) projects ratification of v1.0 in approximately 18-20 months from this Working Draft's publication. Substantial revisions to requirement wording, tier assignments, and conformance procedures are anticipated through the Working Group process.

This document supersedes any prior internal drafts. Future revisions will be numbered v1.0-wd.2, v1.0-wd.3, and so on, advancing through Public Review Draft → Candidate Recommendation → Proposed Standard → Ratified Standard per the schedule in Section 8.

Abstract

This Working Draft proposes Artificial Governed Intelligence (AGI) as a category of artificial intelligence systems whose governance, audit, and authorization properties are constitutive of the system's capability rather than added as external constraints. The proposed AGI Standard specifies eleven requirements distributed across three maturity tiers (CORE, PROPOSED, FORWARD-LOOKING) plus an experimental Defense-in-Depth annex.

This Standard is intended to enable independent implementations of AGI-conformant systems. The Sovereignty Foundation administers conformance certification through a public testing harness and Working Group process. Multiple independent implementations are encouraged.

This document is a Working Draft. Final v1.0 ratification is projected for Q1 2028.

Table of Contents

• Introduction
• Definitions
• Maturity Tiers and Conformance Levels
• Proposed Conformance Requirements
• AGI-1: Cryptographic Audit Chain (CORE)
• AGI-2: Deterministic Inference (PROPOSED)
• AGI-3: Capability-Token Authorization (PROPOSED)
• AGI-4: Identity-Bound Computation (PROPOSED)
• AGI-5: Fail-Closed Enforcement (CORE)
• AGI-6: Hysteretic Decision Stability (PROPOSED)
• AGI-7: Privacy-Preserving Attestation (FORWARD-LOOKING)
• AGI-8: Append-Only Audit Ledger (CORE)
• AGI-9: Multi-Trust-Boundary Architecture (CORE)
• AGI-10: Reproducibility for Verification (PROPOSED)
• AGI-11: Thermodynamic Authorization Cost (FORWARD-LOOKING)
• Defense-in-Depth Annex (EXPERIMENTAL)
• Knox-Anchored Operations (EXPERIMENTAL)
• Maturation Path
• Standards Development Schedule
• Versioning and Amendment Procedures
• Early Adopter Program
• References
• Appendix A: Conformance Test Corpus Sketch
• Appendix B: Cryptographic Primitive Recommendations
• Appendix C: Conformance Test Bench Cells (Outlines)

1. Introduction

1.1 Motivation

The mainstream meaning of AGI — Artificial General Intelligence — defines artificial intelligence by capability without reference to safety, governance, or auditability. Safety and alignment are external constraints that the system may or may not satisfy. This goal definition has produced the current alignment crisis: capability is internal to the goal; governance is external; therefore in any contest of priorities, governance loses.

This Working Draft proposes redefining the category. Artificial Governed Intelligence treats governance as constitutive of capability. A system that does not enforce structural cryptographic, deterministic, and authorization properties is not Artificial Governed Intelligence; therefore, by the proposed definition, it is not AGI as administered by this Standard.

This is a proposal, not a pronouncement. The Foundation invites the field to validate, refine, or reject the proposal through the Working Group process described in Section 9.

1.2 Scope

This Working Draft proposes to apply to:

• Software systems that perform inference, reasoning, or generation using artificial intelligence techniques (statistical, geometric, symbolic, neural, or hybrid)
• Software systems that authorize or gate the execution of AI-generated outputs
• Software systems that record, audit, or attest to AI decisions
• Distributed systems composed of multiple AI components communicating through governed transport
• Hardware-software composite systems where the substrate spans hardware boundaries

This Working Draft does NOT propose to define:

• Specific model architectures (transformer, diffusion, etc.)
• Specific training procedures
• Specific application domains (chat, search, robotics, etc.)
• Specific cryptographic algorithms beyond recommended primitive sets

Scope is open for Working Group revision.

1.3 Relationship to Other Standards

This Working Draft is independent of, but intended to complement:

• ISO/IEC 42001 (AI Management Systems)
• NIST AI RMF (AI Risk Management Framework)
• EU AI Act
• Vendor-specific alignment approaches (Constitutional AI, instruction hierarchy, etc.)

Where those frameworks specify processes or organizational requirements, this Standard proposes to specify implementation requirements enforceable through testable structural properties. AGI-conformant implementations would satisfy implementation requirements; organizational frameworks would address whether such implementations are deployed responsibly.

2. Definitions

For purposes of this Working Draft:

Artificial Governed Intelligence (AGI) — An artificial intelligence system that satisfies the conformance requirements specified in Section 4 at the level applicable to its certification claim. Specific requirements depend on certification level (Section 3.5).

Conformance — Demonstrable satisfaction of the applicable normative requirements through passage of the Conformance Test Corpus published by the Sovereignty Foundation.

Implementation — A specific software, hardware, or composite system that purports to satisfy this Standard.

Implementer — The legal entity producing or deploying an Implementation.

Capability Token — A cryptographic data structure that, when valid, authorizes a specific Implementation to perform a specific class of operations within a specific scope and time window.

Trust Boundary — A boundary across which different cryptographic keys, attestation procedures, or governance authorities apply. Components on opposite sides of a Trust Boundary cannot directly trust each other; they must exchange artifacts that satisfy independent verification.

Sealed Object — A data structure identified by the cryptographic hash of its content, such that any modification produces a different identifier.

Audit Chain — An append-only sequence of records where each record's identity is computed as a one-way hash function of its predecessor's identity and its own content.

Decision Result — The output of an AGI evaluation: a finite-state authorization decision plus the cryptographic hashes of all inputs that produced it.

Conformance Authority — The Sovereignty Foundation, in its role as the body that administers the Conformance Test Corpus and grants certification marks to qualifying Implementations.

Working Group — The AGI Standards Working Group, an open-participation body convened by the Foundation that contributes to Standard development and maturation. See Section 9.

Maturity Tier — The current development tier of a requirement: CORE, PROPOSED, or FORWARD-LOOKING. See Section 3.

3. Maturity Tiers and Conformance Levels

This Working Draft introduces a two-axis structure for managing requirement maturity and Implementation conformance.

3.1 Maturity Tiers

Each proposed requirement is assigned to one of three maturity tiers. The tier reflects the Foundation's current evidence that the requirement is implementable and meaningful, not the requirement's eventual importance.

3.1.1 CORE (MUST in v1.0)

Requirements where the Foundation has direct evidence of implementability through working code in the reference Implementation, and the requirement is foundational to the AGI category claim. CORE requirements are written with MUST and form the minimum bar for any AGI-related conformance claim.

Implementers seeking any conformance level MUST satisfy CORE requirements.

3.1.2 PROPOSED (SHOULD in v1.0; expected to become MUST in v2.0)

Requirements where the Foundation has working implementation evidence but where the specific formulation of the requirement may benefit from community refinement before becoming a strict obligation. PROPOSED requirements are written with SHOULD and explicitly note the expected escalation path to MUST in v2.0.

Implementers SHOULD satisfy PROPOSED requirements; non-conformance to PROPOSED requirements MUST be documented in the Implementation's conformance report.

3.1.3 FORWARD-LOOKING (MAY in v1.0; under active investigation)

Requirements where the right approach is genuinely uncertain or where research is active. FORWARD-LOOKING requirements are written with MAY and are included in the Standard to flag the territory and invite contribution, not to commit any party to compliance.

Implementers MAY satisfy FORWARD-LOOKING requirements; satisfaction is recorded in the conformance report but is not required for any current certification level.

3.2 Why this tiering matters

A Standard that publishes everything as MUST in v1.0 commits the Foundation and its early implementers to obligations that may not survive operational experience. A Standard that publishes everything as MAY communicates no real commitment at all. The graduated approach lets the Standard advance the bar honestly: MUSTs are claims the Foundation can defend with evidence; SHOULDs are commitments the Foundation expects to harden once implementation experience accumulates; MAYs are research-active areas where the field is invited to contribute.

This is the IETF / W3C tradition adapted for substrate-class AI infrastructure.

3.3 Tier Migration

Requirements move between tiers based on accumulated evidence:

• FORWARD-LOOKING → PROPOSED: when at least two independent Implementations demonstrate the requirement is implementable in working code, and the Working Group reaches rough consensus on the formulation
• PROPOSED → CORE: when at least three independent Implementations have satisfied the requirement in production deployment for at least 12 months, and Working Group consensus confirms the formulation has stabilized
• CORE → DEPRECATED (if ever): only through MAJOR version increment per the ratchet clause (Section 9.3); CORE requirements cannot be weakened, only strengthened or replaced by structurally-equivalent-or-stronger alternatives

The Foundation publishes Tier Migration Reports quarterly documenting which requirements are progressing toward which tiers.

3.4 Reading the Requirements

Each requirement in Section 4 is presented with:

• Tier: CORE, PROPOSED, or FORWARD-LOOKING
• Normative wording: uses MUST / SHOULD / MAY per the tier
• Rationale: why the requirement is proposed
• Implementation evidence: Foundation's reference Implementation status
• Open questions: issues the Working Group needs to resolve (where applicable)
• Test specification: outline of conformance test cell (full specifications in Appendix C)

3.5 Conformance Levels

This Working Draft proposes three conformance levels. These levels are themselves provisional and subject to revision based on Working Group feedback.

AGI Compliant (proposed)

An Implementation that satisfies all CORE requirements (currently AGI-1, AGI-5, AGI-8, AGI-9) and documents its handling of PROPOSED and FORWARD-LOOKING requirements in a conformance report.

AGI Certified (proposed)

An Implementation that satisfies all CORE and PROPOSED requirements (currently AGI-1 through AGI-6, AGI-8, AGI-9, AGI-10) and documents its handling of FORWARD-LOOKING requirements.

AGI Certified+ (proposed)

An Implementation that satisfies all requirements at all tiers including FORWARD-LOOKING and EXPERIMENTAL Defense-in-Depth requirements.

The certification mark licensing terms will be published separately by the Foundation prior to any certification mark issuance. Certification marks will not be issued until v1.0 is ratified.

Re-certification cadence (24 months proposed) is itself open for Working Group revision.

4. Proposed Conformance Requirements

The eleven proposed requirements that define AGI conformance. Each is assigned to a maturity tier reflecting the Foundation's current evidence.

AGI-1: Cryptographic Audit Chain

Tier: CORE

Normative requirement (MUST): Implementations MUST record every governance decision in an append-only sequence where each record's identity is computed as a one-way cryptographic hash function of its predecessor's identity and the current decision's content. The hash function MUST be a collision-resistant cryptographic hash from the recommended primitive list (Appendix B).

Modification of any historical record MUST produce a different identifier for that record and for all subsequent records. Verification of chain integrity MUST be possible by any party in possession of the recorded inputs and the chain head identifier.

Rationale: Audit-graded provenance is structurally enforceable through hash chains. Without this property, audit logs can be quietly modified by privileged parties — including the Implementer itself — without detection. Hash-chain audit is well-established cryptographic practice (see e.g. Linux kernel's audit subsystem, Git, blockchain ledgers); this requirement applies the practice to AGI governance decisions specifically.

Implementation evidence: Reference Implementation has working BLAKE3-linked governance chain in the SAGE governance crate (a_sage/crates/sage-governance/src/chain.rs). Verification works; modification detection works; bench cells exercise both at scale.

Open questions: None significant. This requirement is well-understood and ready for CORE designation.

Test specification (TC-AGI-1): See Appendix C, test cell tc-agi-1-audit-chain. Test verifies: chain construction is deterministic; modification of any historical record invalidates downstream identifiers; verification computation completes within bounded time and memory.

AGI-2: Deterministic Inference

Tier: PROPOSED (expected to become MUST in v2.0)

Normative requirement (SHOULD): Implementations SHOULD produce bit-identical outputs for identical inputs across distinct executions, distinct hardware platforms within an approved architecture set, and distinct execution sessions. The pure inference function SHOULD perform no input/output operations during the computation and SHOULD NOT read any non-input source of variation (system clock, random number generator, network state, etc.).

Implementations MAY use floating-point arithmetic in non-decision pathways. Decision-producing computations SHOULD use fixed-point or integer arithmetic from the recommended primitive list (Appendix B).

Implementations not satisfying this requirement MUST document specifically which sources of non-determinism remain and the reproducibility envelope under which decisions can be re-derived.

Rationale: Reproducibility is the foundation of audit. Without bit-identical reproduction, decisions cannot be re-verified by external parties. However, the bit-identical-across-hardware bar is high, and several legitimate AI architectures (especially those depending on GPU non-determinism) cannot satisfy it without significant restructuring.

Implementation evidence: Reference Implementation's Eco engine satisfies this requirement on the substrates tested (Apple M-series, Linux Xeon V100, Linux Xeon H100). The 24 SIG signatures + 5 axioms are documented in the Eco specification paper.

Open questions for Working Group:

• Should the requirement allow well-documented non-deterministic GPU operations in non-decision pathways? Probably yes.
• What is the right "approved architecture set" — should the Foundation maintain an explicit list, or should Implementations declare their own reproducibility envelopes?
• Should this be CORE in v1.0 if the substrate's reference Implementation already satisfies it? The Working Group should weigh "we can do it" vs. "everyone else should be required to do it."

Path to CORE: When at least three independent Implementations satisfy this requirement in production for 12+ months, escalate to CORE in v2.0.

Test specification (TC-AGI-2): See Appendix C, test cell tc-agi-2-determinism. Test verifies: identical inputs produce identical outputs across 10,000 trials on at least 3 hardware substrates; no I/O system calls occur during the inference critical path; no system clock reads occur during inference; outputs are reproducible from sealed inputs by any third party.

AGI-3: Capability-Token Authorization

Tier: PROPOSED (expected to become MUST in v2.0)

Normative requirement (SHOULD): Implementations SHOULD require a valid Capability Token for every operation that affects external state, executes code with side effects, or accesses protected resources. Capability Tokens SHOULD contain at minimum:

• A monotonically-increasing counter for replay protection
• A temporal validity window with explicit start and end times
• A cryptographic signature from a key authorized for token issuance
• A content-addressed identifier of the operation being authorized
• A scope identifier limiting the breadth of authorized operations

Capability Token verification SHOULD be performed independently of token issuance.

Rationale: Capability-token-gated execution structurally separates authorization from enforcement, enabling multi-trust-boundary architectures (AGI-9). However, the specific token format is implementation-sensitive and may benefit from community refinement.

Implementation evidence: Reference Implementation has working Knox + Aegis composite (Knox mints; Aegis verifies). The bipartite warrant structure (rigid cryptographic + fuzzy biometric hemispheres) is one specific implementation; other formulations are possible.

Open questions for Working Group:

• Should the Standard specify a canonical Capability Token wire format, or should it specify only the required semantic properties and leave the format implementation-defined?
• Should biometric / fuzzy hemispheres (per the Knox formulation) be a recommended pattern, or kept as one possible implementation among several?
• What is the right relationship between Capability Tokens and existing standards (OAuth 2.0, OIDC, JWT, biscuit tokens)?

Path to CORE: When the wire format question is resolved through Working Group consensus, and at least two independent Implementations satisfy the requirement.

Test specification (TC-AGI-3): See Appendix C, test cell tc-agi-3-capability-tokens.

AGI-4: Identity-Bound Computation

Tier: PROPOSED (expected to become MUST in v2.0)

Normative requirement (SHOULD): Implementations SHOULD associate every governance decision with a specific identity manifold representing the entity (human, agent, organization) on whose behalf the decision is made. The identity manifold SHOULD be cryptographically attestable. Decisions made on behalf of identity A SHOULD NOT be retrievable through queries authorized for identity B unless explicit cross-identity authorization is in effect.

Rationale: Without identity-binding, audit cannot answer "who did this decision serve?" — which is the central question for accountability. Identity-binding does not require identity-disclosure (see AGI-7).

Implementation evidence: Reference Implementation's Logos manifold provides identity binding via N-dimensional manifold-native identity representation. Multiple Logos implementations could exist; the requirement does not mandate the specific Logos formulation.

Open questions for Working Group:

• What is the minimum acceptable identity primitive? Is a manifold required, or are other identity representations (cryptographic identifiers, role-based identifiers, opaque tokens) sufficient?
• How should multi-identity decisions be handled (decisions affecting multiple parties, joint decisions, federated decisions)?
• What standards should the identity layer interoperate with (DID, OIDC, etc.)?

Path to CORE: When the Working Group reaches consensus on the minimum identity primitive and at least two independent Implementations demonstrate satisfaction.

Test specification (TC-AGI-4): See Appendix C, test cell tc-agi-4-identity-bound.

AGI-5: Fail-Closed Enforcement

Tier: CORE

Normative requirement (MUST): Implementations MUST default to denying execution in the absence of affirmative authorization. Ambiguous, undefined, or error states MUST result in denial. Authorization MUST be a structural prerequisite for execution; the Implementation MUST NOT permit execution to proceed and then retroactively check authorization.

Rationale: Fail-open systems produce the worst class of failures: actions taken under authorization the system cannot prove. Fail-closed systems may inconvenience operators but cannot produce unattributable actions. This is well-established secure-systems design (Saltzer & Schroeder, 1975).

Implementation evidence: Reference Implementation's Aegis verify pipeline returns one of five VerifyError variants on any failure, all of which result in denial. The five-stage gauntlet (WARD PoW → VDF → hash-chain → fuzzy gate → CrystallizedAct) is fail-closed at each stage.

Open questions: None significant. Fail-closed is well-understood and ready for CORE designation.

Test specification (TC-AGI-5): See Appendix C, test cell tc-agi-5-fail-closed.

AGI-6: Hysteretic Decision Stability

Tier: PROPOSED (expected to become MUST in v2.0)

Normative requirement (SHOULD): Implementations SHOULD resist decision flapping for inputs near decision boundaries. State transitions SHOULD require crossing distinct strict and relaxed thresholds with a deliberate dead zone between them. The strict threshold (required to gain trust or change to a more-permissive state) SHOULD be more demanding than the relaxed threshold (required to maintain trust or remain in a more-permissive state).

Rationale: Decisions that flap on noise destroy audit value and operational reliability. Hysteresis is the standard engineering solution. This Standard proposes to make it a conformance requirement.

Implementation evidence: Reference Implementation has Schmitt-trigger geometric firewall in SAGE. The four-state authorization machine (Approve/Deny/Escalate/Delay) demonstrates hysteresis through the Escalate and Delay intermediate states.

Open questions for Working Group:

• Should the Standard specify minimum threshold-ratio requirements (e.g., strict > relaxed by at least 10%), or leave threshold ratios implementation-defined?
• How should hysteresis interact with explicit operator overrides?
• What is the right behavior at startup before any history exists?

Path to CORE: Working Group consensus on threshold-ratio minimums and at least two independent Implementations.

Test specification (TC-AGI-6): See Appendix C, test cell tc-agi-6-hysteresis.

AGI-7: Privacy-Preserving Attestation

Tier: FORWARD-LOOKING

Normative requirement (MAY): Implementations MAY provide a mechanism for entities to prove identity properties without disclosing the identity itself. Possible attestation primitives include: (a) membership in a defined population, (b) possession of a specific authorization, (c) presence within a defined behavioral envelope.

Rationale: Many AI deployment contexts require identification of entities who interact with the system, but identification does not necessarily require disclosure. Privacy-preserving attestation is research-active; the Foundation flags this as territory worth exploring but does not commit Implementations to a specific approach.

Implementation evidence: Reference Implementation has Anonymous Identity Objects with ZK manifold attestation — but this is one specific approach. Several other ZK / multi-party computation primitives could satisfy the spirit.

Open questions for Working Group:

• Which ZK primitive(s) should be recommended (zk-SNARKs, zk-STARKs, Bulletproofs, others)?
• How should attestation interact with regulatory disclosure requirements (KYC, AML, healthcare HIPAA, etc.)?
• What is the right relationship to existing standards (W3C Verifiable Credentials, BBS+ signatures, etc.)?
• Should the Foundation reference NIST Privacy Framework or other privacy standards?

Path to PROPOSED: When ZK-attestation primitives stabilize industry-wide, when at least two Implementations demonstrate working ZK-attestation in AGI contexts, and when Working Group reaches rough consensus on the minimum acceptable formulation.

Test specification (TC-AGI-7): Outline only — full test specification deferred until requirement matures.

AGI-8: Append-Only Audit Ledger

Tier: CORE

Normative requirement (MUST): Implementations MUST persist governance decisions in an append-only data store that MUST NOT support modification, deletion, or reordering of historical records. The ledger MUST be readable by parties authorized for audit purposes and MUST support cryptographic verification of completeness.

Soft-delete mechanisms (where a record is marked invalid but retained in the underlying store) are PERMITTED provided that the marking is itself an append-only ledger entry and that historical state remains reconstructible.

Rationale: This requirement complements AGI-1 (cryptographic audit chain) by specifying the persistence properties of the audit ledger.

Implementation evidence: Reference Implementation has CanonMDB (Knox crystallized act ledger) and Canon's two-tier memory with forgotten set as soft-delete primitive. Both satisfy the append-only + soft-delete requirements.

Open questions: None significant. Append-only ledgers are well-understood and ready for CORE designation.

Test specification (TC-AGI-8): See Appendix C, test cell tc-agi-8-ledger.

AGI-9: Multi-Trust-Boundary Architecture

Tier: CORE

Normative requirement (MUST): Implementations MUST distribute governance functions across at least four distinct Trust Boundaries:

• Evaluator — produces governance decisions from inputs
• Minter — issues Capability Tokens authorizing decisions for action
• Enforcement Gate — verifies tokens and gates operation execution
• Audit Ledger — records decisions and operations

Each Trust Boundary MUST use distinct cryptographic key material. Compromise of any single component MUST be structurally insufficient to forge artifacts produced by the other three. Components MUST communicate exclusively through artifacts that satisfy independent verification by the receiving component.

Rationale: Single-component governance systems have a single point of compromise. Multi-trust-boundary architectures require an attacker to compromise multiple independent components to forge end-to-end artifacts (Saltzer & Schroeder, 1975).

Implementation evidence: Reference Implementation has four distinct rings — SAGE (evaluator), Knox (minter), Aegis (enforcement gate), Owl (audit ledger). Each is its own Rust crate with its own key material; cross-ring communication uses Pulse Mesh with cryptographic chain step.

Open questions: None significant. Multi-trust-boundary architecture is well-established secure design and ready for CORE designation.

Test specification (TC-AGI-9): See Appendix C, test cell tc-agi-9-trust-boundaries.

AGI-10: Reproducibility for Verification

Tier: PROPOSED (expected to become MUST in v2.0)

Normative requirement (SHOULD): Implementations SHOULD enable any party in possession of the recorded inputs, the sealed policy, and the sealed configuration to re-execute the inference function and obtain a bit-identical Decision Result matching the recorded Decision Result. The sealed policy and sealed configuration SHOULD be identified by their content-addressable cryptographic hashes; the Decision Result SHOULD include those hashes.

Rationale: Reproducibility is the structural foundation of accountability. A decision that any party can re-execute and verify cannot be defended through "you'd have to be there" or "the policy changed since then" arguments.

Implementation evidence: Reference Implementation's Eco engine + sealed-policy + content-addressable hashing satisfies this requirement. Decision Results include policy + configuration hashes.

Open questions for Working Group:

• Should the re-execution protocol be standardized, or left implementation-defined?
• What is the audit-time scope: should the Foundation specify which recorded artifacts must accompany decisions for re-execution, or leave to Implementer discretion?
• How should this requirement interact with privacy requirements (re-execution may require access to inputs that contain sensitive data)?

Path to CORE: When the re-execution protocol is standardized through Working Group consensus and at least two Implementations demonstrate independent verifier capability.

Test specification (TC-AGI-10): See Appendix C, test cell tc-agi-10-reproducibility.

AGI-11: Thermodynamic Authorization Cost

Tier: FORWARD-LOOKING

Normative requirement (MAY): Implementations MAY require bounded computational expenditure (CPU time, memory, or both) to mint Capability Tokens. The cost, if implemented, MAY be sufficient that mass forgery attempts at the Implementation's expected operational scale would be economically infeasible.

Rationale: Free authorization enables mass spam, identity theft, denial-of-service, and unbounded delegation at scale. Thermodynamic cost provides structural defense without centralized rate-limiting. However, the right cost-function formulation is genuinely uncertain and depends on threat model.

Implementation evidence: Reference Implementation has Knox with dual VDFs (sequential-hash + RSW time-lock) and dual PoW variants (BLAKE3 compute-bound + Argon2id memory-hard). This is one specific formulation; other approaches are possible.

Open questions for Working Group:

• What is the minimum acceptable cost-function formulation?
• How should cost scale with threat level — fixed parameters, configurable, or adaptive?
• How should cost interact with legitimate high-throughput use cases?
• Should the cost be implementation-defined or standardized?
• What are the energy / sustainability considerations of imposing computational cost as a governance primitive?

Path to PROPOSED: When cost-function formulation stabilizes through Working Group consensus and at least two Implementations demonstrate working thermodynamic cost in AGI contexts.

Test specification (TC-AGI-11): Outline only — full test specification deferred until requirement matures.

5. Defense-in-Depth Annex (EXPERIMENTAL)

This section specifies experimental requirements that may eventually become AGI Certified+ requirements. Currently EXPERIMENTAL — included to flag the territory and invite contribution, not to commit any party to compliance.

5.1 Hardware Trust Boundary Isolation (EXPERIMENTAL)

Provisional requirement: AGI Certified+ Implementations MAY enforce Trust Boundaries across distinct hardware execution domains. At minimum, the Evaluator, Minter, Enforcement Gate, and Audit Ledger MAY execute on isolated CPU cores, isolated processes within hardware-attested execution environments, or distinct physical machines.

Inter-domain communication MAY be performed through a substrate-class transport (such as Pulse Mesh) that provides:

• Zero-copy semantic transport with cryptographic chain step in every message
• Bit-exact wire format with structural verification
• Replay-protection via per-domain monotonic counters
• Transport-layer audit attestation

Status: Active research. Reference Implementation demonstrates the substrate-class transport (Pulse Mesh) but full hardware-isolated four-ring deployment has not yet been validated end-to-end. Working Group input welcomed.

5.2 Compiled Mathematical Primitive Requirements (EXPERIMENTAL)

Provisional requirement: AGI Certified+ Implementations MAY use only cryptographic primitives explicitly listed in Appendix B as APPROVED. Primitive selection MAY be compiled into the Implementation's binary and MAY be verifiable through binary integrity seal.

Status: Tradeoff under investigation. Compile-time primitive binding prevents runtime downgrade attacks but slows response to vulnerabilities. Working Group should debate whether the tradeoff favors compile-time or whether runtime agility with verification is preferable.

5.3 Binary Integrity Seal (EXPERIMENTAL)

Provisional requirement: AGI Certified+ Implementations MAY include a cryptographic hash of the executable image computed at compile or deploy time and stored as an expected value, with boot-time verification.

Status: Well-established secure-systems pattern. Likely to mature to PROPOSED in v1.1 or v2.0.

5.4 Knox-Anchored Update Authority (EXPERIMENTAL)

Provisional requirement: Updates to AGI Certified+ Implementations MAY be authorized through Capability Tokens issued by an authority bound by role to a Foundation Update Authority Registry.

Status: Operationally consequential. The Foundation must establish the operational infrastructure for Update Authority Registry before this requirement can advance beyond EXPERIMENTAL. Estimated 12-18 months of standing-up work.

Open questions for Foundation Board:

• What governance structure should Update Authority Registry have?
• Who can apply to be Update Authority?
• What is Foundation's role vs. Implementer's role in update lifecycle?
• What happens if Foundation cannot reach Implementation deployment (offline systems, edge devices)?

5.5 Cross-Domain Trust Anchoring (EXPERIMENTAL)

Provisional requirement: AGI Certified+ Implementations operating across organizational, jurisdictional, or trust domain boundaries MAY establish trust through Foundation-anchored Capability Tokens.

Status: Active research. Reference Implementation has not yet demonstrated cross-domain trust establishment in production. Working Group input welcomed.

6. Knox-Anchored Operations (EXPERIMENTAL)

This section sketches the operational structure by which the Sovereignty Foundation could administer conformance certification and ongoing AGI Implementation lifecycle. The mechanisms described here are EXPERIMENTAL and depend on Foundation operational infrastructure that does not yet exist.

6.1 Conformance Certification (Future)

A possible Conformance Certification process:

• Implementer requests certification at the desired level
• Foundation issues a Capability Token authorizing access to the Conformance Test Corpus
• Implementer runs the Test Corpus and submits results sealed under the Implementation's binary hash
• Foundation independently verifies sealed results against the published Test Corpus expected outputs
• On successful verification, Foundation issues a Conformance Certification Capability Token to the Implementation
• Implementation may use the appropriate certification mark per Foundation licensing terms

Status: Conformance Test Corpus is being authored. Foundation certification operational infrastructure is not yet established. First certifications anticipated 6-12 months after v1.0 ratification (so approximately mid-2028 at earliest).

6.2 Software Updates (Future)

Software update infrastructure depends on Update Authority Registry per Section 5.4. Currently EXPERIMENTAL.

6.3 Practitioner Certification (Future)

Three proposed tiers:

• AGI Certified Conformance Engineer (entry-level)
• AGI Certified Implementer (intermediate)
• AGI Certified Architect (senior)

Curriculum, exams, and credential format are deferred to a separate document (SF-AGI-PRACTITIONER-001) to be authored after v1.0 ratification.

6.4 Cross-Domain Trust Establishment (Future)

Cross-domain operational procedures depend on Section 5.5 and require Foundation operational infrastructure not yet established.

6.5 Vulnerability Disclosure and Coordinated Patching (Future)

Foundation coordinated vulnerability disclosure process to be established prior to first certifications.

7. Maturation Path

This section explains how requirements move through tiers as the Standard matures.

7.1 Foundation Reference Implementation as Baseline

The Foundation maintains a reference Implementation of the AGI Standard in the Sovereignty Stack. This reference Implementation is the Foundation's working evidence that requirements are implementable; it is NOT the only valid Implementation. Multiple independent Implementations are encouraged and necessary for requirements to mature beyond CORE.

7.2 Tier-Migration Evidence Requirements

7.3 Working Group Deliberation

Tier migrations are recommended by the Working Group based on accumulated evidence. The Working Group convenes at least quarterly to:

• Review Implementation reports from current participants
• Evaluate maturation evidence for tier migrations
• Discuss open questions on PROPOSED and FORWARD-LOOKING requirements
• Recommend Standard amendments to the Foundation Board

7.4 Public Evidence Reporting

The Foundation publishes quarterly Tier Migration Reports documenting:

• Which requirements are progressing toward which tiers
• Implementation evidence supporting maturation
• Working Group recommendations
• Open questions requiring resolution before maturation

These reports are public and form the audit trail for the Standard's development.

8. Standards Development Schedule

The projected timeline for AGI Standard v1.0 development:

Total: approximately 18-22 months from this Working Draft to ratified v1.0.

This schedule is itself provisional. Substantial Working Group feedback or unexpected complexity in any phase may extend the timeline. The Foundation prefers extending the schedule over rushing to ratification.

The schedule assumes the Foundation Board is seated within Q3 2026 and the Working Group is convened by Q4 2026. Both are operational dependencies external to this Standard.

9. Versioning and Amendment Procedures

9.1 Version Numbering

This Standard uses a working-draft-aware semantic versioning scheme:

• Working Drafts: 1.0-wd.N where N increments with each revision
• Public Review Drafts: 1.0-prd.N
• Candidate Recommendations: 1.0-cr.N
• Proposed Standards: 1.0-ps.N
• Ratified Standards: MAJOR.MINOR.PATCH

After ratification, semantic versioning applies:

• MAJOR version increments indicate breaking changes that require existing AGI Certified Implementations to re-certify within 24 months
• MINOR version increments indicate additive changes that existing Implementations MAY adopt
• PATCH version increments indicate corrections, clarifications, or test-corpus additions

9.2 Amendment Process (Post-Ratification)

After v1.0 is ratified, amendments follow:

• Proposed amendment submitted via Foundation's public process
• 90-day public comment period
• Working Group review and recommendation
• Foundation Board ratification (supermajority required for MAJOR amendments)
• Publication of amended Standard with effective-date schedule

9.3 Ratchet Clause

Per the Sovereignty Foundation Ethics Charter, normative requirements at CORE tier MAY be strengthened but MUST NOT be weakened by amendment. PROPOSED and FORWARD-LOOKING requirements MAY be removed if maturation evidence consistently fails to materialize.

The ratchet clause does NOT prevent CORE requirements from being replaced by structurally-equivalent-or-stronger alternatives. It prevents only weakening.

10. Early Adopter Program

The Foundation offers an Early Adopter Program for Implementations that wish to engage with the Standard prior to v1.0 ratification.

10.1 Eligibility

Open to any Implementation purporting to satisfy the CORE requirements (currently AGI-1, AGI-5, AGI-8, AGI-9). Foundation reviews eligibility on a rolling basis.

10.2 Status

Successful Early Adopters receive AGI Reference Implementation status (NOT the trademarked AGI Certified™ — this is a different, lighter-weight status). The status is granted for 12 months and may be renewed.

Early Adopters may publicly state their participation but MAY NOT use the AGI Certified™, AGI Compliant™, or AGI Certified+™ certification marks. These marks are reserved for Implementations certified after v1.0 ratification.

10.3 Benefits

Early Adopters receive:

• Direct access to Working Group discussions
• Priority access to Conformance Test Corpus drafts
• Recognition in Foundation Tier Migration Reports
• Opportunity to influence Standard development through implementation feedback

10.4 Obligations

Early Adopters commit to:

• Publishing self-test results against the current Working Draft annually
• Participating in Working Group discussions on requirements they implement
• Engaging in good faith with Foundation requests for implementation evidence

10.5 Sovereignty Stack as First Early Adopter

The Foundation's reference Implementation (Sovereignty Stack) is the first Early Adopter. This is not preferential treatment — it is acknowledgment that the Standard is being developed in tandem with a working reference Implementation. Other Early Adopters are welcomed without preference.

10.6 Production Pilot Cohort

The Standard is additionally being piloted in the production infrastructure of operating companies with which the Foundation shares ownership or control — initially DexaFit, Cracker Digital Marketing, and Pulse Mesh, with further pilots to follow. The pilots exist to subject the requirements to real operational load and to generate the implementation evidence that tier migration runs on (Section 3.3).

Two boundaries govern the cohort, and they are structural rather than cosmetic. First, pilots hold Early Adopter status only: per Section 10.2 they may state their participation but may not use any certification mark. Second, and permanently: implementations affiliated with the Foundation through ownership or control are outside the certification pathway altogether. The certifier does not certify itself, and it does not certify its affiliates — their role is to be the first and most scrutinized sources of implementation evidence, published as self-test results like any other Early Adopter's.

11. References

11.1 Normative References

• RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels
• RFC 8174 — Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
• The Sovereignty Foundation Ethics Charter (current Working Draft)

11.2 Informative References

• Simmons, B. — Toward Artificial Governed Intelligence: A Moral Imperative in the Age of AGI. May 11, 2025. https://bradysimmons.substack.com/p/toward-artificial-governed-intelligence — the founding essay proposing the Artificial Governed Intelligence category this Standard specifies.
• Simmons, B. — Challenging the Norm of AI: Redefining AI Through the Ontology of Governance. May 15, 2025. https://bradysimmons.substack.com/p/challenging-the-norm-of-ai — governance as constitutive of the category ("AGI = Governed Intelligence"), the ontological claim Section 1.1 formalizes.
• Simmons, B. — Ethical White Paper: Human-in-the-Loop Governance in Semantic Architecture. May 10, 2025. https://bradysimmons.substack.com/p/ethical-white-paper-human-in-the — human authority as a first-class structural element across the RITA / SAGE / Mirror architecture, the design this Standard's escalation requirements descend from.
• Simmons, B. — Principles of Semantic Coherence Dynamics. May 8, 2025. https://bradysimmons.substack.com/p/principles-of-semantic-coherence — coherence-governed decision-making as a formal discipline: role-based filtering, trust vectors, semantic thresholds.

• Saltzer, J. H. and Schroeder, M. D. (1975) — "The Protection of Information in Computer Systems"
• Boneh, D., Bonneau, J., Bünz, B., and Fisch, B. (2018) — "Verifiable Delay Functions"
• Biryukov, A., Dinu, D., and Khovratovich, D. (2016) — Argon2 specification
• O'Connor, J., Aumasson, J.-P., Neves, S., and Wilcox-O'Hearn, Z. (2020) — BLAKE3 specification
• W3C Process Document (current) — for inspiration on standards development phases

Appendix A — Conformance Test Corpus Sketch

The Conformance Test Corpus will be the testable definition of AGI conformance. Currently in early specification. The Corpus is not yet available; outline of structure follows.

Each test cell will follow the methodology published in pms-bench/PROTOCOL-V4.md and pms-ai-bench (sealed cells with cryptographic reproducibility manifests).

Per requirement, test cells specify: input data, expected behavior, pass/fail criteria, reproducibility envelope, sealed expected outputs, bench-cell metadata.

The Corpus will be versioned independently from the Standard. New cell versions MAY clarify expected behavior without amending Section 4.

The Corpus will be published at https://standard.sovfound.org/agi/conformance/ (URL provisional) once the Foundation operational infrastructure supports it.

Appendix B — Cryptographic Primitive Recommendations

This appendix recommends cryptographic primitives for AGI conformance. These are recommendations, not requirements; specific tier of requirement determines whether use is mandatory.

B.1 Recommended Hash Functions

Future post-quantum hash variants will be added as they are standardized.

B.2 Recommended Signature Algorithms

Post-quantum signature schemes (CRYSTALS-Dilithium, FALCON) will be added as their standardization matures (NIST PQC).

B.3 Recommended Memory-Hard Proof-of-Work

B.4 Recommended Verifiable Delay Functions

B.5 Recommended Fixed-Point Arithmetic

Wider fixed-point formats (Q32.32, Q64.64) MAY be used; narrower formats are NOT recommended for decision-producing computation.

B.6 Recommended Symmetric Encryption (where required)

B.7 Implementation Notes

• Random number generation for key material SHOULD use cryptographically-secure RNG (CSPRNG) seeded from OS entropy
• Constant-time comparison SHOULD be used for any cryptographic equality check (no early-return short-circuits)
• Recommendations may be updated as cryptographic landscape evolves; Implementations should track Foundation publications

Appendix C — Conformance Test Bench Cells (Outlines)

Test cell outlines for each requirement. Full specifications deferred to a separate document (SF-AGI-BENCH-001) authored after Working Group input on requirement formulations.

Test Cell Format (proposed)

Each cell will be a self-contained directory with:

tc-agi-N-<short-name>/
├── scenario.json           — pre-registered test scenario
├── inputs/                 — sealed input data
├── expected/               — sealed expected outputs (with hash manifest)
├── harness/                — test execution harness
├── manifest.sha256         — SHA-256 manifest of all files
└── README.md               — test description, pass/fail criteria

Per-Requirement Outlines

TC-AGI-1 (CORE): Verify chain construction is deterministic for a sequence of governance decisions; verify modification of any record invalidates downstream identifiers; verify integrity-verification completes in bounded time and memory.

TC-AGI-2 (PROPOSED): Verify identical inputs produce identical outputs across multiple hardware substrates and execution sessions; verify no I/O or clock-read system calls occur during inference critical path.

TC-AGI-3 (PROPOSED): Verify operations without valid tokens are rejected; verify replayed/expired/invalid-signature/wrong-scope tokens are rejected; verify rejection reasons are recorded in audit ledger.

TC-AGI-4 (PROPOSED): Verify decisions are associated with identity manifolds; verify cross-identity retrieval is blocked without authorization; verify identity attestation completes without unnecessary disclosure.

TC-AGI-5 (CORE): Verify execution requested without authorization is denied; verify execution requested during error states is denied; verify no observable system state change occurs in any failure case.

TC-AGI-6 (PROPOSED): Verify inputs near the decision boundary do not produce flapping outputs; verify state transitions occur only on inputs that cross the appropriate hard threshold; verify hysteresis behavior is deterministic across reproductions.

TC-AGI-7 (FORWARD-LOOKING): Outline only; full specification deferred.

TC-AGI-8 (CORE): Verify records cannot be modified or deleted after persistence; verify ledger query results include cryptographic completeness proof; verify soft-delete (if implemented) is itself append-only.

TC-AGI-9 (CORE): Verify at least four distinct Trust Boundaries are present; verify each uses distinct key material; verify compromise simulation does not enable cross-boundary forgery.

TC-AGI-10 (PROPOSED): Verify independent re-execution produces bit-identical Decision Results; verify policy/configuration hash changes correctly invalidate decisions for re-execution.

TC-AGI-11 (FORWARD-LOOKING): Outline only; full specification deferred.

TC-AGI-DD-1 through TC-AGI-DD-5 (EXPERIMENTAL)

Outlines deferred until Defense-in-Depth requirements mature beyond EXPERIMENTAL.

Document History