AEOS v1 Charter

AEON Schema Validation System — Version 1

Status: decision-needed for consolidated v1 Scope: AEOS v1 implementations and compatible third-party schema validators

Canonical topic owner: ../AEOS-spec-v1.md

This appendix captures earlier AEOS boundary language and must not override the consolidated AEOS v1 specification. If this appendix conflicts with AEOS-spec-v1.md, AEOS-spec-v1.md 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:

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:

AEOS MUST NOT introduce backward dependencies or feedback loops.

2. Phase Authority

AEOS implements Phase 6 only of the AEON conceptual model.

AEOS MUST NOT perform behavior belonging to any other phase.

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:

AEOS MUST NOT infer recovery intent implicitly.

4. Outputs

4.1 Validator Result Envelope (Normative)

AEOS v1 MUST emit a result object with the following minimum structure:

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

1. Validate representation eligibility

• e.g. “string matches integer pattern”

1. Validate cross-binding presence

• e.g. “if X exists, Y must exist”

1. Validate annotation/datatype presence
2. Validate ordering constraints (symbolically)
3. Emit diagnostics
4. 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 (Normative)

AEOS v1 MAY emit the following standardized guarantees:

Processors MAY rely on Tier-1 guarantees.

6.2 Tier-2 Namespaced Guarantees (Non-Normative)

AEOS MAY emit namespaced guarantees:

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)

1. Resolve references

(~, ~>)

1. Inject defaults
2. Compute derived values
3. Compare interpreted magnitudes

(<, >, arithmetic)

1. Materialize objects
2. Reorder Assignment Events
3. Mutate AES
4. Depend on processors
5. 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 (Normative Examples)

10.1 Representation Eligibility

Valid if schema allows integer-representable. AEOS does not parse "42" into a number.

10.2 Cross-Binding Presence

Valid only if:

exists earlier or later in AES.

10.3 Ordering Constraint

Invalid — reference targets a later binding.

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.