# Appendix — AEOS v1 Charter **AEON Schema Validation System — Version 1** **Scope:** AEOS v1 implementations and compatible third-party schema validators Canonical topic owner: AEOS Specification v1. This appendix summarizes AEOS boundary language and must not override the consolidated AEOS v1 specification. If this appendix conflicts with AEOS Specification v1, AEOS Specification v1 wins. ## 0. Purpose This charter defines the **constitutional constraints** under which **AEOS v1** operates. AEOS exists to provide **structural and representational validation** of AEON documents **without interpreting their meaning**. This document answers one question only: > [!NOTE] > What is AEOS v1 allowed to do — and what must it never do? Anything not explicitly permitted here is out of scope for AEOS v1. ## 1. Foundational Axioms ### 1.1 Single Source of Truth AEOS consumes the **Assignment Event Stream (AES)** as produced by AEON Core. - AES is **ordered** - AES is **immutable** - AES is **lossless** - AES is **uninterpreted** AEOS MUST treat AES as a **read-only ledger**. ### 1.2 Deferred Meaning AEOS does **not** assign meaning to values. AEOS validates **representations**, not **interpretations**. > AEOS answers: *“Is this representation acceptable?”* > AEOS does not answer: *“What does this value mean?”* ### 1.3 One-Way Pipeline AEOS participates in a strictly **one-directional pipeline**: ``` AEON Core → AES → AEOS → Processor / Tonic → Output ``` AEOS MUST NOT introduce backward dependencies or feedback loops. ## 2. Phase Authority AEOS implements **Phase 6 only** of the AEON conceptual model. | Phase | Authority | | :--- | :--- | | Parsing, Path Resolution, AES Emission | AEON Core | | **Schema Validation** | **AEOS v1** | | Profile Interpretation | Processors / Tonics | | Reference Evaluation | Processors / Tonics | | Materialization | Processors / Tonics | *AEON processing-phase authority* AEOS MUST NOT perform behavior belonging to any other phase. AEOS may perform bounded resolved-form validation only when the active schema explicitly enables it. That capability does not transfer Core reference-legality ownership, mutate AES, or authorize materialization. ## 3. Inputs ### 3.1 Required Input AEOS v1 MUST accept: - A complete **Assignment Event Stream (AES)** - Optional schema definitions AEOS MUST NOT operate on: - source text - ASTs - partially emitted event streams ### 3.2 Recovery Awareness If AES was emitted in recovery mode, this MUST be explicit via metadata: ```ebnf AES.meta.recovery_mode ::= "none" | "allow-duplicates" | "best-effort" ``` AEOS MUST NOT infer recovery intent implicitly. ## 4. Outputs ### 4.1 Validator Result Envelope AEOS v1 MUST emit a result object with the following minimum structure: ```json { "ok": true, "errors": [], "warnings": [], "guarantees": {} } ``` When validation fails, `ok` MUST be `false` and errors MUST be populated. ### 4.2 Error Requirements Each error MUST include: - `path` — canonical path - `span` — source span (when available) - `message` — human-readable description - `phase` — `"schema_validation"` - `code` — stable, machine-readable identifier AEOS MUST NOT emit modified AES as output. ## 5. Core Responsibilities (What AEOS v1 MAY Do) AEOS v1 MAY: 1. Validate **structure** - required bindings - allowed literal kinds 2. Validate **representation eligibility** - e.g. “string matches integer pattern” 3. Validate **cross-binding presence** - e.g. “if X exists, Y must exist” 4. Validate **annotation/datatype presence** 5. Validate **ordering constraints** (symbolically) 6. Emit **diagnostics** 7. Emit **guarantees** (see Section 6) All validation is performed against the **entire AES**. ## 6. Guarantees Guarantees are **advisory, non-semantic assertions** emitted by AEOS. They describe **representation properties only**. ### 6.1 Tier-1 Standard Guarantees AEOS v1 MAY emit the following standardized guarantees: | Guarantee | Meaning | | :--- | :--- | | `integer-representable` | Value can be parsed as integer | | `float-representable` | Value can be parsed as float | | `boolean-representable` | Value can be parsed as boolean | | `non-empty-string` | StringLiteral length \> 0 | | `regex:` | Matches named regex | | `present` | Binding exists | *AEOS Tier-1 standard guarantees* Processors MAY rely on Tier-1 guarantees. ### 6.2 Tier-2 Namespaced Guarantees (Non-Normative) AEOS MAY emit namespaced guarantees: ```json { "$.email": ["acme:corporate-email"] } ``` Rules: - MUST be namespaced - MUST NOT be relied upon by generic processors - MUST NOT affect AEOS conformance ## 7. Hard Prohibitions (Non-Negotiable) AEOS v1 MUST NOT: 1. Coerce values (`"42"` → `42`) 2. Resolve references (`~`, `~>`) 3. Inject defaults 4. Compute derived values 5. Compare interpreted magnitudes (`<`, `>`, arithmetic) 6. Materialize objects 7. Reorder Assignment Events 8. Mutate AES 9. Depend on processors 10. Assume downstream correction Any of the above disqualifies AEOS v1 conformance. ## 8. Uniqueness & Const Semantics - Each canonical path MUST appear at most once - Duplicate bindings MUST be treated as errors **unless** `AES.meta.recovery_mode` explicitly permits them Even in recovery mode: - AEOS MAY observe duplicates - AEOS MUST NOT reconcile or resolve them ## 9. Failure Model AEOS v1 is **fail-closed**: - All constraints are evaluated - Any failure results in `ok: false` - No partial acceptance - No speculative success Recovery behavior is observational only. ## 10. Canonical Validation Scenarios ### 10.1 Representation Eligibility ```aeon age = "42" ``` Valid if schema allows `integer-representable`. AEOS does **not** parse `"42"` into a number. ### 10.2 Cross-Binding Presence ```aeon tls.enabled = true ``` Valid only if: ```aeon tls.cert = ... ``` exists earlier or later in AES. ### 10.3 Reference Form Constraint ```aeon backup = ~primary ``` AEOS may validate that `backup` is a Core-emitted reference form or that its declared target path matches a schema pattern. AEOS does not decide whether the reference target is legal; Core owns missing-target, forward-reference, and self-reference legality. ## 11. Non-Goals of AEOS v1 AEOS v1 explicitly does **not** provide: - interpretation - evaluation - coercion - defaults - computation - reference resolution - runtime configuration - materialized output These are delegated to processors and tonics. ## 12. Versioning Commitment AEOS v1 behavior defined in this charter is **stable**. Any relaxation of prohibitions or expansion of authority constitutes a **new major version**. ## Closing Statement **AEOS validates form, not meaning. Meaning is deferred, never assumed. This separation is the foundation of AEON’s integrity.** --- ## Related documents - [AEOS Specification v1](./aeos-v1.md) - [AEOS v1 Compliance Specification](./aeos-v1-compliance.md) - [Appendix — Assignment Event Stream (AES)](./appendix-aes-v1.md) - [Appendix — Tonic Processor Governance](./appendix-tonic-v1.md) - [Appendix — Third-Party Validator Conformance](./appendix-validator-conformance-v1.md)