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, 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
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
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, while the public CTS manifests define the required executable conformance cases.

If this document, AEOS-spec-v1, and a published AEOS CTS manifest disagree, the canonical rule text in AEOS-spec-v1 controls the specification meaning and the CTS manifest controls the executable conformance obligation for its release lane.