# AEOS v1 Compliance Specification Scope: normative conformance requirements for AEOS-specific behavior layered on top of AEON core. This document is intentionally introduced as a separate compliance line so AEON core compliance and AEOS compliance are not treated as the same surface. ## 1. Compliance Philosophy AEOS compliance measures validator behavior, not implementation strategy. Conforming implementations may differ internally, provided they preserve the externally observable behavior defined by this specification, [`AEOS-spec-v1`](./aeos-v1.md), and the associated CTS manifests. AEOS compliance therefore attaches to the validator contract: accepted inputs, ResultEnvelope shape, diagnostic categories, authority boundaries, and observable pass/fail behavior. It does not require a particular storage model, rule engine, traversal algorithm, cache strategy, or programming-language architecture. ## 2. Conformance Target An implementation claiming AEOS v1 conformance SHALL satisfy: - language and authority-boundary requirements in [`AEOS-spec-v1`](./aeos-v1.md) - AEON Core prerequisites required by the AEOS surface - `cts.protocol.v1` runner and AEOS lane requirements in `cts/protocol/v1` - the published AEOS validator manifest: - `cts/aeos/v1/aeos-validator-cts.v1.json` AEOS conformance is validator-surface conformance. It does not replace or weaken AEON Core conformance requirements. ## 3. AEOS Behavior Families AEOS compliance SHALL be evaluated against validator behavior families, not only by isolated suite success. The current AEOS behavior families are: - result-envelope and validator output contract - schema rule-index integrity - SANSA path and selector rule targeting, plus closed-world coverage - presence and forbid semantics - representational type and datatype-label constraints - attribute-payload and attribute-closure constraints - reference-form, reference-target, and resolved-reference constraints - numeric lexical-form constraints - string length and pattern constraints - guarantee emission - container-kind and tuple-arity constraints - indexed-path validation and tuple positional checks - separator-literal policy enforcement - structural container item validation - Core-versus-AEOS authority boundary preservation The current anti-drift coverage accounting for these families is tracked in `aeonite-cts/CONFORMANCE-COVERAGE.md`. ## 4. Authority Boundary An AEOS-conforming implementation MUST: - consume Core/AES output rather than redefining Core legality - preserve the ResultEnvelope contract - preserve canonical-path diagnostics within the AEOS validator surface - support exact `path` rules and `selector` rules according to [`AEOS-spec-v1`](./aeos-v1.md) - avoid treating Core-owned legality failures as schema-validation failures - preserve bounded, deterministic behavior for opt-in resolved-reference validation - treat `resource_policy` values as validator budgets rather than AEOS language ceilings; implementation defaults may vary, and larger configured budgets are implementation/platform dependent AEOS conformance is not satisfied by passing only representative examples if validator behavior drifts across one of the AEOS behavior families listed above. ## 5. Compliance Boundary This document defines the AEOS conformance surface at the behavior-family level. Detailed rule semantics remain owned by [`AEOS-spec-v1`](./aeos-v1.md), while the public CTS manifests define the required executable conformance cases. If this document, [`AEOS-spec-v1`](./aeos-v1.md), and a published AEOS CTS manifest disagree, the canonical rule text in [`AEOS-spec-v1`](./aeos-v1.md) controls the specification meaning and the CTS manifest controls the executable conformance obligation for its release lane. --- ## Related documents - [AEOS Specification v1](./aeos-v1.md) - [AEON Core v1 Compliance Specification](./aeon-core-v1-compliance.md) - [AEON v1 Conformance Matrix](./aeon-v1-conformance-matrix.md) - [AEON v1 Release Governance](./aeon-v1-release-governance.md)