# Appendix — Glossary **Appendix to:** AEON Specification v1 This glossary defines core AEON terms. Terms are listed alphabetically. Entries marked **(v1 baseline update)** were introduced or revised during v1 consolidation. ## Annotation Stream **(v1 baseline update)** The **Annotation Stream** is the ordered sequence of structured comment records emitted by AEON Core in parallel to the AES. - Contains one record per structured comment (`doc`, `annotation`, `hint`, `reserved`) - Does NOT affect the AES - Is emitted in source order - Records include kind, form, raw content, span, and deterministic target binding See *Appendix: Annotation Stream*. ## Assignment Event An **Assignment Event** is the atomic semantic unit of an AEON document. - Emitted when a binding assigns a value to a canonical path - Immutable once emitted - Unique per canonical path (no duplicates allowed) Assignment Events are the basis for canonical hashing, schema validation, and reference resolution. ## Assignment Event Stream (AES) The **Assignment Event Stream (AES)** is the portable, transport-neutral event model shared by AEON-family producers and consumers. - Represents each structural occurrence as its own flat event - Preserves stream order; an explicit canonical-order projection may be selected where required - Carries recognized portable values rather than implementation-specific AST nodes - Is semantically lossless relative to the selected AES profile and projection, not necessarily to original source bytes - Uses explicit profiles to distinguish complete streams from partial streams AEON is one producer that projects valid source documents into AES. Telex and future Film encodings carry the same event model. See [Portable AES Event Contract v1](./aes-events-v1.md). ## Binding A **Binding** is a key-value assignment: `name = value`. ## Body The **Body** of an AEON document is the set of bindings that define its meaning. - Parsed after headers - Interpreted through AEON Core structure plus any applicable conventions, schemas, profiles, and consumer policy - Validated by schemas when validation is applied - Covered by canonical hashing The body MUST NOT include integrity material. ## Canonical Path A **Canonical Path** is the unique, fully-qualified identifier for a value. In v1, canonical path identity supports two segment kinds: - `member(key)` — printed `.key` - `index(i)` — printed `[n]` (v1) Examples: - `$.user.name` - `$.items[0]` Attribute selectors (for example `.@.meta`, `.@.["a.b"]`) are valid in addressing expressions but are not canonical path identity segments. ## Consumer A **Consumer** is any system that parses, validates, or interprets an AEON document. Consumers: - Select conventions, schemas, profiles, and processors by policy - Decide what processors are allowed - Define trust boundaries Documents do not control consumers. ## Contract A **Contract** is a published, versioned artifact that identifies a trusted profile or schema surface for AEON processing. Contracts: - are resolved through trusted registries or allowlists - do not self-activate from document claims alone - define stable identifiers such as `aeon.gp.profile.v1` and `aeon.gp.schema.v1` See *AEON v1 Contracts Specification*. ## Convention A **Convention** is a named interpretation agreement layered on top of AEON Core. Conventions: - define meaning, context, metadata, or interop labels - do not change AEON grammar - are declared by documents but interpreted by downstream consumers Examples include document metadata conventions, context conventions, temporal conventions, and security conventions. ## Conformance Test Suite (CTS) The **Conformance Test Suite (CTS)** is the published test surface used to verify claimed AEON conformance. CTS: - is organized into named lanes and suite files - covers normative behavior rather than general hardening - is the public conformance authority for the v1 line Stress or hardening workflows may exist separately and are not automatically part of CTS. ## Envelope An **Envelope** is a top-level object binding typed as `:envelope`. - In the baseline GP security model, `close:envelope` is the recommended conventional spelling - Appears only at document end when used for GP integrity/signature/encryption conventions - In the baseline GP security model, contains `integrity`, `signatures`, and optional `encryption` - Excluded from canonical hashing when selected as the document envelope - Inert and non-semantic ## Guarantee A **Guarantee** is an advisory, non-semantic assertion about a value's representation. Guarantees: - Are emitted by validators (AEOS or third-party) - Describe syntactic properties only (e.g., `integer-representable`) - Do NOT alter validation outcomes - MAY be observed by downstream processors Tier-1 guarantees are normative; Tier-2 guarantees are namespaced and vendor-specific. ## Header A **Header** is AEON metadata declared in the `aeon:` namespace. Headers express: - Document identity and versioning - Convention, contract, schema, and profile intent - Encoding Headers are inspectable before evaluation and advisory (not authoritative). ## Index Segment **(v1 baseline update)** An **Index Segment** is a positional canonical path segment of the form `[n]` that addresses an element of a list or tuple. - Zero-based - Decimal digits only - No sign prefix - No leading zeros unless index is `0` Malformed index forms produce `invalid_index_format`. ## Integrity Material **Integrity Material** includes: - Canonical integrity hashes - Cryptographic signatures - Optional encryption metadata when a security convention defines it Exists only to verify document integrity and authenticity. ## ListNode **(v1 baseline update)** A **ListNode** is the AES/AST value kind for `[...]` surface syntax. - Indicates homogeneous-element intent - Type constructor: `list` ## Instruction Comment An **Instruction Comment** is an advisory comment intended as side-channel guidance for downstream consumers. Instruction comments: - may suggest review, update, summarization, routing, or handling intent - do not alter AEON Core semantics - are preserved as comment-side context rather than treated as binding data - may be used by profiles, processors, or direct end consumers subject to trust policy Instruction comments are non-authoritative by default. ## Pattern Profile The **Pattern Profile** defines a deterministic DSL for validating `StringLiteral` values. Features: - Predicates: `length`, `contains`, `starts_with`, `ends_with`, `no_whitespace`, `charset` - Composition: `all`, `any`, `not` - Structure: `split`, `labels` See *Appendix: Pattern Profile*. ## Profile A **Profile** defines a policy bundle for how an AEON document should be processed once selected by trusted consumer policy. Profiles: - may enable or forbid processors or optional behaviors - may set default processing policy such as mode or datatype policy - do not override the zero-trust rule that consumer selection remains authoritative Exactly one profile may be active. Profiles are trusted, consumer-selected contract artifacts. ## Processor A **Processor** is a named downstream behavior or transformation function selected under consumer policy. Processors: - Are not defined inside documents - May be pure or capability-gated - May be enabled or constrained by profiles, schemas, or other external policy - Are distinct from conventions, which define interpretation rather than behavior Processors must be explicitly allowed by the consumer environment. ## Schema A **Schema** defines acceptability constraints over an AEON document. Schemas: - Validate structure and values - Do not execute logic - Do not by themselves define business meaning Schemas constrain; conventions describe meaning; profiles bundle policy. ## Schema Profile The **Schema Profile** defines the structure of AEON documents used as schemas. Components: - `rules` — binds SANSA path or selector targets to constraints - `patterns` — reusable pattern definitions - `charsets` — named character sets See *Appendix: Schema Profile*. ## Semantic Content **Semantic Content** is the meaning-bearing portion of an AEON document. Consists of: - Assignment Events from the body - Excluding headers and envelope Canonical hashing operates over semantic content. ## Side Channel A **Side Channel** is preserved document material that accompanies AEON Core output without changing the meaning-bearing AES. Examples include: - structured comment records in the Annotation Stream - spans - advisory instruction comments Side-channel material may be consumed by validators, processors, or end applications, but it does not alter Core semantic content by itself. ## Span A **Span** identifies a half-open byte range in the exact AEON source artifact from which a value originated. - Format: `[start, end]` using zero-based UTF-8 byte offsets - `start` is inclusive, `end` is exclusive - Offsets are measured before BOM removal, newline translation, or Unicode normalisation - Produced by AEON Core only - Validators propagate spans unchanged See *Appendix: Spans*. ## Tonic **(v1 baseline update)** A **Tonic** is the canonical downstream materialization processor that consumes AES and produces a domain-specific runtime representation. Tonics: - Receive AES from AEON Core - Optionally validate against an AEOS schema - Transform AES into domain objects Tonics are *not* AEON Core — they consume AEON output. See *Appendix: Tonic Processor Governance*. ## TupleLiteral **(v1 baseline update)** A **TupleLiteral** is the AES/AST value kind for `(...)` surface syntax. - Indicates positional/arity intent - Type constructor: `tuple` - Distinct from `ListNode` ## Validator Conformance **Validator Conformance** defines requirements for any third-party validation engine consuming AES. Conformant validators MUST: - Consume AES as read-only - Preserve event order - Not coerce, resolve, or materialize values - Emit diagnostics with path, span, and phase See *Appendix: Third-Party Validator Conformance*. ## Document Structure Summary | Component | Purpose | | :--- | :--- | | Header | Identity & intent | | Body | Meaning | | Envelope | Integrity | | Annotation Stream | Parallel structured comment records | *AEON document structure components* --- ## Related documents - [AEON Specification v1](./aeon-core-v1.md) - [AEOS Specification v1](./aeos-v1.md) - [Portable AES Event Contract v1](./aes-events-v1.md) - [Official v1 Index](./aeon-v1-official-index.md)