AEOS Specification v1

Scope: AEOS validation contract, active schema model, result envelope, and phase authority boundaries for AEON v1.

1. What AEOS Is

AEOS is the schema and representation-validation layer for AEON.

AEOS operates on AES, not on raw source text. It validates representational form and schema-declared constraints after AEON Core has already completed:

• lexing

• parsing

• canonical path assignment

• reference legality

AEOS does not redefine Core behavior. It consumes Core output.

2. Authority Boundary

2.1 AEON Core Owns

AEON Core is authoritative for:

• lexical validity

• syntax validity

• canonical path assignment

• quoted-key and path disambiguation

• reference legality

  • missing targets

  • forward references

  • self-references

• mode/datatype enforcement at the Core layer

AEOS must not repeat or reinterpret those checks as if they were schema failures.

2.2 AEOS Owns

AEOS is authoritative for:

• rule-index validation

• presence checks

• representational type checks

• reference-form constraints on Core-emitted reference kinds

• reference-target constraints on Core-emitted target paths

• container-kind and arity checks

• numeric lexical-form checks

• string length and pattern checks

• datatype allowlist membership checks when configured in schema

• bounded resolved-endpoint validation when explicitly enabled by schema

• result-envelope emission

2.3 AEOS Does Not Own

AEOS must not:

• coerce values

• inject defaults

• mutate AES

• execute schema-side code

• impose domain/business semantics beyond the active schema constraint surface

Exception:

• when the active schema explicitly declares exact numeric bounds such as min_value or max_value, AEOS may compare numeric magnitudes to enforce those declared constraints.

• when a rule declares resolve_reference_form: true, AEOS may follow a bounded reference chain structurally in order to validate the terminal literal form against the referencing path. This does not transfer Core legality ownership, mutate AES, or authorize schema inheritance from the referenced path.

3. Inputs

AEOS validator input consists of:

• AES

• SchemaV1

• optional validator options

3.1 AES Input

AEOS consumes AES events keyed by canonical paths.

Relevant AEOS assumptions:

• canonical path is authoritative;

• datatype may be present or absent;

• value.type carries the Core-emitted literal/container/reference kind;

• span may be present as Core span data or tuple form.

Reference-bearing AES events may still be present in the stream, but AEOS treats their legality as already decided by Core. AEOS may validate schema constraints against the emitted reference kind, but it must not reinterpret missing-target, forward-reference, or self-reference conditions as schema failures.

3.2 Schema Contract Boundary

There are three schema layers to distinguish:

1. Contract document layer

   • used by CLI/runtime contract loading

   • canonical authoring form is an AEON .aeos document with top-level binding aeos:schema

   • canonical path for the contract object is $.aeos

   • the binding at $.aeos MUST carry datatype/type annotation schema

   • canonical document fields:

     • id

     • version

     • rules

     • optional world

     • optional reference_policy

     • optional resource_policy

     • optional datatype_allowlist

     • optional datatype_rules

   • authoring-oriented helper fields may also appear at this layer so long as they are projected away before validation

     • example: reference_target_path

2. Document header schema declaration layer

   • used by documents that declare intended schema contracts in aeon:header

   • canonical fields:

     • schema

     • optional schemas

   • schema is singular and identifies the primary schema id declared by the document producer

   • schemas is an optional object mapping named contexts to additional declared schema associations

     • recommended reserved keys:

       • authoring

       • validation

     • recommended custom keys use identifier-safe names with _ separators

       • example: vendor_acme

   • schemas entries are named associations, not cumulative instructions

   • header schema declarations are descriptive metadata only; they do not dictate consumer processing behavior

   • a consumer MAY choose to apply schema, MAY choose a context-specific entry from schemas, MAY ignore the declaration entirely, or MAY enforce a local schema instead

   • when a consumer does select among declared header schema ids, schema is the default fallback when no context-specific association is used

3. In-memory SchemaV1 validator layer

   • the object actually consumed by validate(aes, schema, options)

   • current shipped validator shape:

interface SchemaV1 {
  readonly rules: readonly SchemaRule[];
  readonly world?: 'open' | 'closed';
  readonly reference_policy?: 'allow' | 'forbid';
  readonly resource_policy?: ResourcePolicyV1;
  readonly datatype_allowlist?: readonly string[];
  readonly datatype_rules?: Readonly<Record<string, ConstraintsV1>>;
}

The .aeos contract wrapper is handled before AEOS validation begins. AEOS validation itself operates on the in-memory schema object. Loaders MUST parse the .aeos file as AEON, materialize the object at $.aeos, validate the document contract, and project it into SchemaV1 before invoking validate(aes, schema, options). Document header schema declarations are a separate concern from .aeos schema documents: they identify which schema id the document declares for a given context, but they do not change the runtime SchemaV1 shape and they do not prescribe how any consumer must process the document.

4. Active Schema Model

4.1 SchemaV1

Current normative validator model:

interface SchemaV1 {
  readonly rules: readonly SchemaRule[];
  readonly world?: 'open' | 'closed';
  readonly reference_policy?: 'allow' | 'forbid';
  readonly resource_policy?: ResourcePolicyV1;
  readonly datatype_allowlist?: readonly string[];
  readonly datatype_rules?: Readonly<Record<string, ConstraintsV1>>;
}

interface ResourcePolicyV1 {
  readonly max_events?: number;
  readonly max_rules?: number;
  readonly max_any_of_cases?: number;
  readonly max_schema_depth?: number;
  readonly max_path_length?: number;
  readonly max_reference_resolution_steps?: number;
  readonly max_selector_expansions?: number;
  readonly max_string_length_default?: number;
  readonly max_container_children_default?: number;
}

4.2 SchemaRule

interface SchemaRule {
  readonly path?: string;
  readonly selector?: string;
  readonly constraints: ConstraintsV1;
}

Rules target AES events by either exact SANSA path or by SANSA selector.

In programmatic schema payloads, path and selector are strings. In native AEON schema source, they SHOULD be encoded as SANSA literals:

path:sansa = $.contact.name
selector:sansa = $.items.*.name

Each rule MUST provide exactly one of:

• path

• selector

A rule with neither target field is invalid. A rule with both target fields is invalid.

path is an exact SANSA path target. It MUST NOT contain expansion, pattern, filter, or wildcard selectors.

Examples:

• $.contact

• $.contact.name

• $.items[0]

• $.items[0].name

• $.contact.@.unit

selector is a SANSA selector target. Selector strings are root-anchored and use SANSA selector syntax:

• .* matches exactly one structural segment.

• .** matches zero or more structural segments.

Examples:

• $.*.contact matches contact at exact depth 2 from root, such as $.app.contact.

• $.**.contact matches contact at any depth under root, including $.contact.

• $.*.**.contact matches contact at depth 2 or deeper.

• $.pages.*.title matches indexed or named direct children such as $.pages[0].title.

• $.width.*.@.unit matches attributes under direct children.

SANSA deliberately does not define [*] as a selector form. Schemas that need list/item expansion use selector with .*.

Selectors do not create virtual paths. They match against actual Core/AES event paths.

AEOS rule targets use SANSA for structural binding discovery only. AEOS remains responsible for schema-declared representation and structural validation, and meaning-validation consumers remain responsible for domain rules and diagnostics above AEOS.

An AEON document may contain SANSA literals as ordinary values, but those literals do not authorize the document to choose its schema, enable query extensions, select validation policy, or instruct AEOS how to interpret itself. Native AEON schema source gives SANSA literals rule-target meaning only because the schema loader and validator assign that role.

4.3 ConstraintsV1

Active shipped constraint surface:

interface ConstraintsV1 {
  readonly required?: boolean;
  readonly type?: string;
  readonly nullable?: boolean;
  readonly allow_infinity?: boolean;
  readonly allow_nan?: boolean;
  readonly null_value?: string;
  readonly null_values?: readonly string[];
  readonly toggle_pair?: 'any' | 'yes_no' | 'on_off';
  readonly reference?: 'allow' | 'forbid' | 'require';
  readonly reference_kind?: 'clone' | 'pointer' | 'either';
  readonly reference_target_pattern?: string;
  readonly resolve_reference_form?: boolean;
  readonly type_is?: 'list' | 'tuple';
  readonly length_exact?: number;
  readonly min_children?: number;
  readonly max_children?: number;
  readonly sign?: 'signed' | 'unsigned';
  readonly min_digits?: number;
  readonly max_digits?: number;
  readonly radix?: number;
  readonly allow_unspecified_radix?: boolean;
  readonly min_value?: string;
  readonly max_value?: string;
  readonly min_length?: number;
  readonly max_length?: number;
  readonly pattern?: string;
  readonly datatype?: string;
  readonly attributes?: Readonly<Record<string, ConstraintsV1>>;
  readonly closed_attributes?: boolean;
}

Unknown constraint keys are schema errors.

Additional schema-surface notes:

• reference_policy?: 'allow' | 'forbid' is a schema-wide form control.

• resource_policy?: ResourcePolicyV1 is a schema-wide validation budget surface.

• .aeos is the canonical authoring extension for schema documents; SchemaV1 remains the canonical runtime object.

• reference and reference_kind constrain Core-emitted reference kinds without resolving them.

• reference_kind is valid only when reference: 'require'.

• reference_target_path is the preferred .aeos authoring constraint for target-domain matching.

• reference_target_pattern constrains the canonical target path declared by a reference.

• resolve_reference_form is boolean and opt-in.

• reference_target_pattern and resolve_reference_form are invalid when paired with reference: 'forbid'.

• resolve_reference_form is invalid when the rule still expects a reference type such as CloneReference or PointerReference.

• attributes defines recursive constraints over attribute-entry payloads carried on AES events.

• closed_attributes is local to the current attribute object and rejects unknown attribute-entry keys.

5. Constraint Semantics

5.1 required

For a path rule, required: true means the targeted canonical path must exist in AES.

For a selector rule, required: true means the selector must match at least one actual AES event path. If the selector matches one or more actual paths, the rule applies to each matched path.

Failure diagnostic:

• missing_required_field

Missing-path and missing-selector diagnostics use span: null. For a missing selector, the diagnostic path field is the selector string.

5.2 type

type checks Core-emitted value kind.

Representative accepted names include:

• StringLiteral

• BooleanLiteral

• NullLiteral

• NumberLiteral

• IntegerLiteral

• FloatLiteral

• ObjectNode

• ListNode

• TupleLiteral

• CloneReference

• PointerReference

Current aliasing behavior:

• NumberLiteral satisfies NumberLiteral

• IntegerLiteral and FloatLiteral are distinguished from the raw numeric lexical form

Failure diagnostics:

• type_mismatch

• tuple_element_type_mismatch for indexed tuple/list element paths

Reference-form notes:

• type: CloneReference requires a clone reference at the constrained path.

• type: PointerReference requires a pointer reference at the constrained path.

5.3 attributes

attributes applies nested ConstraintsV1 rules to attribute entries attached to the constrained AES event.

This applies equally to:

• ordinary binding attributes

• anonymous child attributes on indexed AES paths such as $.values[0] and $.page[0]

Example:

{
  "rules": [
    {
      "path": "$.values[0]",
      "constraints": {
        "type": "NumberLiteral",
        "attributes": {
          "unit": {
            "required": true,
            "type": "StringLiteral",
            "datatype": "string"
          }
        }
      }
    }
  ]
}

5.4 closed_attributes

closed_attributes: true means the current attribute object admits only the attribute keys named in the nested attributes map.

Unknown attribute-entry keys are validator failures.

5.5 Attribute datatype-rule inheritance

When an attribute entry carries a datatype label and the active schema defines datatype_rules for that datatype, those datatype rules apply to the attribute entry by default.

Nested attributes.<key> constraints remain authoritative when they are more specific than inherited datatype rules.

5.6 Reference Form Constraints

• reference: 'require' accepts either CloneReference or PointerReference.

• reference: 'forbid' rejects both CloneReference and PointerReference.

• reference_kind: 'clone' | 'pointer' | 'either' refines reference: 'require' without evaluating the target.

• reference_policy: 'forbid' rejects reference-bearing AES events schema-wide.

5.7 reference_target_pattern

Target-domain constraint for reference-bearing paths:

reference_target_pattern?: string

Behavior:

• applies only to Core-emitted CloneReference and PointerReference events;

• validates the canonical target path string declared by the reference;

• does not resolve the referenced value;

• uses canonical formatting for quoted members, indexes, and attribute segments before matching.

Failure diagnostic:

• reference_target_mismatch

Schema-validation failures:

• invalid_reference_constraint for non-string patterns, non-portable patterns, invalid pattern syntax, or contradictory combinations.

Authoring note:

• .aeos documents SHOULD prefer reference_target_path where the allowed target domain can be expressed as a SANSA selector such as $.ages.*.

• Loaders MUST project that selector into an equivalent internal target-matching form before AEOS validation.

5.8 resolve_reference_form

Opt-in resolved-endpoint validation:

resolve_reference_form?: boolean

Behavior:

• when true, AEOS may follow a bounded reference chain from the constrained path to its terminal literal endpoint;

• literal-form constraints such as type, min_value, max_value, min_length, max_length, pattern, and datatype-rule checks apply to the resolved terminal literal form;

• reference-form constraints such as reference, reference_kind, and reference_target_pattern continue to apply to the original reference event at the constrained path;

• AEOS does not mutate AES, inherit target-path schema obligations, or reinterpret Core legality failures.

Boundary notes:

• missing targets, forward references, self-references, and other Core legality failures remain Core-owned;

• cyclic or otherwise unresolvable chains do not become new AEOS schema errors merely because resolve_reference_form is enabled;

• resolved-endpoint validation is bounded and deterministic.

Schema-validation failures:

• invalid_reference_constraint for non-boolean values or contradictory combinations.

5.9 type_is

Container kind constraint:

type_is?: 'list' | 'tuple'

Behavior:

• list accepts ListNode / ListLiteral

• tuple accepts TupleLiteral

Failure diagnostic:

• wrong_container_kind

5.10 length_exact

Exact container arity constraint for tuple/list style containers.

Failure diagnostic:

• tuple_arity_mismatch

5.11 Container Cardinality Constraints

Container child-count constraints:

• length_exact

• min_children

• max_children

Behavior:

• applies to Core-emitted container forms with immediate children, including ObjectNode, ListNode / ListLiteral, TupleLiteral, and NodeLiteral;

• length_exact requires exactly the declared immediate child count;

• min_children requires at least the declared immediate child count;

• max_children requires at most the declared immediate child count.

Failure diagnostics:

• tuple_arity_mismatch for length_exact

• container_cardinality_mismatch for min_children and max_children

5.12 Type Widening and Literal Lexical Constraints

Nullable and special numeric widening constraints:

• nullable

• allow_infinity

• allow_nan

Behavior:

• when nullable: true, NullLiteral satisfies the declared type constraint;

• when allow_infinity: true, InfinityLiteral satisfies numeric type constraints (NumberLiteral, IntegerLiteral, FloatLiteral);

• when allow_nan: true, NaNLiteral satisfies numeric type constraints (NumberLiteral, IntegerLiteral, FloatLiteral);

• additional literal-form constraints apply only when they are meaningful for the actual literal form.

Null value constraint:

null_value?: string
null_values?: readonly string[]

Behavior:

• applies only when the matched AES event is a NullLiteral;

• null_value is shorthand for one accepted surfaced null value;

• null_values accepts any surfaced null value in the list;

• compares against the Core-surfaced null value, such as none, notApplicable, or a custom quoted null reason.

Toggle pair constraint:

toggle_pair?: 'any' | 'yes_no' | 'on_off'

Behavior:

• any accepts all toggle literals: yes, no, on, and off;

• yes_no accepts only yes and no;

• on_off accepts only on and off;

• omitted is equivalent to any.

Failure diagnostics:

• type_mismatch for missing widening flags;

• null_value_mismatch;

• toggle_pair_mismatch.

5.13 Numeric Form Constraints

Numeric lexical-form constraints:

• sign

• min_digits

• max_digits

• radix

• min_value

• max_value

Behavior:

• applies to numeric literal forms and radix-like symbolic literal forms;

• radix applies only to RadixLiteral and declares the exact accepted digit base;

• when radix is present, a RadixLiteral MUST declare the same radix in its datatype using radix[n] or radixn;

• allow_unspecified_radix: true permits legacy or transport-oriented RadixLiteral values whose datatype is omitted, while still checking the value against the schema radix;

• uses lexical representation for sign, digit-count, and radix digit checks;

• uses numeric magnitude only when min_value or max_value are explicitly declared;

• integer digit count excludes sign.

Failure diagnostic:

• numeric_form_violation

5.14 String and Pattern Form Constraints

String constraints:

• min_length

• max_length

• pattern

Length semantics:

• applies to normalized string-like literal values: StringLiteral, SeparatorLiteral, NullLiteral, EncodingLiteral, and temporal literal forms

• measured in UTF-16 code units (JavaScript string.length)

Pattern semantics:

• applies to normalized string-like literal values

• AEOS portable pattern strings

• full-string match semantics

• if anchors are omitted, AEOS adds ^ and $

• validators MUST NOT silently accept host-specific regular-expression features

Failure diagnostics:

• string_length_violation

• pattern_mismatch

5.15 AEOS Portable Pattern Profile

The pattern and reference_target_pattern constraints use the AEOS portable pattern profile. They are not host-language regular expressions.

The profile is intentionally small so schemas can move between TypeScript, Rust, Python, PHP, and other implementations without changing validation meaning or exposing validators to catastrophic backtracking behavior.

Supported syntax:

• literal characters

• escaped literal punctuation

• .

• ^ and $

• character classes such as [A-Z] and negated classes such as [^0-9]

• grouping with (...) and non-capturing grouping with (?:...)

• alternation with |

• quantifiers ?, *, +, {m}, and {m,n}

• common portable escapes: \d, \D, \w, \W, \s, \S, \b, \B, \n, \r, \t, \f, \v, and \0

Forbidden syntax:

• backreferences such as \1

• named backreferences such as \k<name>

• lookahead and lookbehind

• named captures

• inline regex flags

• Unicode property escapes such as \p{Letter}

• implementation-specific escape classes

• nested quantified groups that may cause catastrophic backtracking, such as ^(a+)+$

Validation requirements:

• A schema containing a pattern outside this profile is invalid.

• Implementations MUST reject unsupported pattern syntax during schema validation.

• Implementations MUST NOT reinterpret unsupported syntax through the host regex engine.

• Implementations MAY use a host regex engine after they have verified the pattern conforms to this profile.

Schema-validation failures:

• unknown_constraint_key for invalid pattern constraints.

• invalid_reference_constraint for invalid reference_target_pattern constraints.

5.16 datatype

Datatype constraint is an exact label-equality check. When a rule requests a datatype, the AES event MUST carry the same declared datatype string. A missing or different label fails with type_mismatch.

An AES datatype annotation remains declarative when no constraints.datatype rule applies. Exact label enforcement does not perform semantic subtype or value reasoning; those deeper semantics belong in datatype_rules.

5.17 datatype_allowlist

Optional schema-level allowlist:

datatype_allowlist?: readonly string[]

Behavior:

• if present, any rule using constraints.datatype must reference an allowed datatype string;

• this is membership checking only.

Failure diagnostic:

• datatype_allowlist_reject

5.18 world

Optional schema-level world policy:

world?: 'open' | 'closed'

Behavior:

• open is the default;

• open validates declared schema rules and ignores unexpected AES binding paths;

• closed rejects any non-header AES binding path not explicitly covered by schema.rules;

• exact path rules and selector rules both participate in closed-world coverage;

• rejection happens before downstream materialization is trusted.

Failure diagnostic:

• unexpected_binding

5.19 datatype_rules

Optional schema-level datatype semantics:

datatype_rules?: Readonly<Record<string, ConstraintsV1>>

Behavior:

• keys are datatype base labels such as uint, int32, or float64;

• when an AES event carries a matching declared datatype, the mapped constraints are applied in addition to any path rule;

• this is how aeon.gp.schema.v1 makes reserved numeric labels operational without moving those semantics into Core.

Typical uses:

• uint → type = "IntegerLiteral", sign = "unsigned"

• int32 → type = "IntegerLiteral", min_value = "-2147483648", max_value = "2147483647"

• float32 → type = "FloatLiteral"

5.20 resource_policy

resource_policy declares validator resource budgets. It exists to keep active schema evaluation bounded when schemas or AES streams are supplied by untrusted or semi-trusted parties.

Supported fields:

• max_events

• max_rules

• max_any_of_cases

• max_schema_depth

• max_path_length

• max_reference_resolution_steps

• max_selector_expansions

• max_string_length_default

• max_container_children_default

Policy values MUST be non-negative integers. A value of zero is valid and means no items in that category may be consumed or expanded.

Resource-policy values are validator budgets, not AEOS language ceilings. The default values chosen by an implementation are implementation policy. A schema or host may configure lower budgets for stricter resource control or higher budgets for larger documents, subject to the implementation's platform and runtime capacity. If an implementation rejects a configured budget because it exceeds platform limits, that rejection is a resource-policy diagnostic rather than a change to AEOS schema semantics.

When a schema or host configures a resource-policy budget above a documented portable floor, implementations with warning support SHOULD emit AEOS_NON_PORTABLE_RESOURCE_POLICY. The warning should identify the policy key, configured budget, and portable floor so authors do not mistake a locally accepted schema for one that will run unchanged everywhere.

max_string_length_default is reserved as the default string-like payload budget. Explicit min_length and max_length constraints remain the normative way to validate string, trimtick/prose, separator, encoding, WTC, and custom null payload lengths.

Validation failures emit:

• invalid_schema_policy

6. Validation Phases

Current shipped validator phases:

1. Envelope plumbing

2. Baseline invariants

3. Rule-index build / schema-shape validation

4. Resource-policy budget checks

5. Selector rule expansion

6. Presence checks

7. Type and reference checks

8. Container-kind checks

9. Numeric form checks

10. String form and pattern checks

11. Datatype allowlist enforcement during rule indexing

12. World-policy enforcement

13. Datatype-rule enforcement

14. Guarantees emission

6.1 Baseline Invariants

Active baseline checks include:

• duplicate AES binding paths

• invalid index segment shape in canonical paths

• optional trailing separator-delimiter policy

Active baseline checks do not include reference-legality validation. Missing targets, forward references, and self-references remain Core-owned even when reference events are present in AES.

Failure diagnostics include:

• duplicate_binding

• invalid_index_format

• trailing_separator_delimiter

7. Result Envelope

AEOS produces exactly one output shape.

interface Diag {
  readonly path: string;
  readonly span: [number, number] | null;
  readonly message: string;
  readonly phase: 'schema_validation';
  readonly code: string;
}

interface ResultEnvelope {
  readonly ok: boolean;
  readonly errors: readonly Diag[];
  readonly warnings: readonly Diag[];
  readonly guarantees: Readonly<Record<string, readonly string[]>>;
}

Normative rules:

• ok is true only when errors.length === 0

• warnings do not flip ok to false

• envelope must not include AES input

• diagnostics use canonical path strings

• phase is currently fixed to schema_validation

7.1 Tooling Metadata Is Separate

Consumer tools may wrap AEOS results in larger command or editor payloads. Those wrappers are not part of the core ResultEnvelope contract.

In particular:

• CLI or editor output may expose declared contract metadata read from aeon:header

• runtime bind flows may expose both declared and applied contract ids

• such metadata is consumer/tooling provenance, not AEOS validator state

One valid tooling pattern is:

{
  "document": { "...": "..." },
  "meta": {
    "errors": [],
    "warnings": [],
    "contracts": {
      "declared": {
        "profile": "aeon.gp.profile.v1",
        "schema": "altopelago.main_schema.v1",
        "schemas": {
          "authoring": "altopelago.authoring_schema.v1"
        }
      },
      "applied": {
        "profile": "core",
        "schema": "altopelago.main_schema.v1"
      }
    }
  }
}

Interpretation:

• declared reflects producer-declared header metadata only

• applied reflects the contract ids actually selected by the consumer

• inspect-style read-only surfaces may expose only declared

• bind-style runtime surfaces may expose both declared and applied

8. Guarantees

AEOS guarantees are advisory representation tags keyed by canonical path.

Current shipped guarantees include tags such as:

• present

• integer-representable

• float-representable

• boolean-representable

• non-empty-string

Guarantees are emitted only on passing envelopes.

9. Validator Options

Current shipped validator options:

interface ValidateOptions {
  readonly strict?: boolean;
  readonly trailingSeparatorDelimiterPolicy?: 'off' | 'warn' | 'error';
}

9.1 strict

Reserved for future AEOS-specific behavior.

Current validator does not materially change rule semantics based on this flag.

9.2 trailingSeparatorDelimiterPolicy

Optional policy for separator literal payloads ending in a declared separator.

Modes:

• off (default): ignore

• warn: emit warning

• error: emit error

This policy does not change Core parsing semantics.

10. Diagnostics

Current standard AEOS diagnostic codes include:

10.1 Baseline / Schema

• duplicate_binding

• rule_missing_path

• duplicate_rule_path

• unknown_constraint_key

• invalid_reference_constraint

10.2 Presence / Type / Container

• missing_required_field

• type_mismatch

• wrong_container_kind

• tuple_arity_mismatch

• tuple_element_type_mismatch

• invalid_index_format

• reference_forbidden

• reference_required

• reference_kind_mismatch

• reference_target_mismatch

10.3 Numeric / String / Datatype

• numeric_form_violation

• string_length_violation

• pattern_mismatch

• datatype_allowlist_reject

• trailing_separator_delimiter

• constraint_inapplicable

• invalid_schema_policy

Vendor-prefixed diagnostics may use:

vendor:code

Reference-legality diagnostics such as missing-target, forward-reference, and self-reference failures belong to Core/AES, not to AEOS.

11. CLI / Runner Adapter

The shipped AEOS CTS adapter:

• reads JSON from stdin

• expects { aes, schema, options }

• writes ResultEnvelope JSON to stdout

The adapter is read-only and must not mutate validator behavior.

12. CTS Mapping

AEOS conformance should be reviewed by behavior family rather than by isolated test file.

Current v1 behavior-family anchors:

• result-envelope and validator output contract

  • cts/aeos/v1/suites/00-envelope.json

• baseline invariants and Core-versus-AEOS authority boundary

  • cts/aeos/v1/suites/01-baseline.json

• schema rule-index integrity

  • cts/aeos/v1/suites/02-schema-rules.json

• SANSA path and selector rule targeting, plus closed-world coverage

  • cts/aeos/v1/suites/22-selector-paths.json

• presence and forbid semantics

  • cts/aeos/v1/suites/03-presence.json

• representational type and datatype-label constraints

  • cts/aeos/v1/suites/04-type.json

  • cts/aeos/v1/suites/08-datatype-labels.json

• reference-form, reference-target, and resolved-reference constraints

  • cts/aeos/v1/suites/16-reference-forms.json

  • cts/aeos/v1/suites/17-reference-targets.json

  • cts/aeos/v1/suites/18-resolved-reference-form.json

  • cts/aeos/v1/suites/19-reference-security.json

• numeric lexical-form constraints

  • cts/aeos/v1/suites/05-numeric-form.json

• string length and pattern constraints

  • cts/aeos/v1/suites/06-string-form.json

  • cts/aeos/v1/suites/07-pattern.json

• guarantee emission

  • cts/aeos/v1/suites/09-guarantees.json

• container-kind and tuple-arity constraints

  • cts/aeos/v1/suites/10-container-kinds.json

  • cts/aeos/v1/suites/11-tuple-arity.json

• indexed-path validation and tuple positional checks

  • cts/aeos/v1/suites/12-tuple-positional.json

  • cts/aeos/v1/suites/13-indexed-path-validation.json

• separator-literal policy enforcement

  • cts/aeos/v1/suites/14-separator-literal-policy.json

• structural container item validation

  • cts/aeos/v1/suites/15-structural-container-items.json

• resource-policy budget validation

  • cts/aeos/v1/suites/23-resource-policy.json

Protocol governance:

• cts/protocol/v1/runner-contract.md

• cts/protocol/v1/lane-aeos.md

12.1 Mapping rule

When AEOS CTS grows, new suites should strengthen one of the behavior families above or introduce a newly documented AEOS behavior family explicitly.

AEOS CTS should not expand as an unclassified test pile.

13. Conformance Notes

A conforming AEOS v1 implementation must:

• consume canonical Core/AES output rather than redefining Core semantics;

• support the active SchemaV1 constraint surface documented here;

• emit the canonical ResultEnvelope shape;

• preserve deterministic canonical-path diagnostics;

• fail closed on validation errors.

13.1 Anti-drift requirement

AEOS conformance is not satisfied by passing only representative examples.

An implementation must preserve behavior across the AEOS validation families defined in this document and their corresponding CTS lanes, especially:

• schema rule validation

• SANSA path and selector rule targeting

• presence checks

• type and datatype-label enforcement

• reference-form, reference-target, and resolved-reference enforcement

• numeric and string-form constraints

• container and indexed-path validation

• separator policy enforcement

• result-envelope and guarantee behavior

Core-owned semantics must remain Core-owned. AEOS must not reinterpret Core legality failures as schema-validation failures.