AEON is a layered declaration ecosystem.

A declaration is not a runtime object.

Most data formats begin by treating data as an object, tree, map, or document. Useful systems then grow around that foundation: schemas, serializers, runtime mappers, conventions, transforms, and execution surfaces.

Over time those layers can collapse into each other. Structure becomes mixed with meaning. Validation becomes mixed with execution. Metadata becomes mixed with content. Parsing becomes mixed with materialization.

AEON starts from a different premise: a declaration is not the same thing as a runtime object. From that distinction, the rest of the system follows.

AEON is not merely a serialization format. It is a layered declaration ecosystem built around deterministic assignment streams.

Rather than collapsing every concern into a single object model, AEON keeps identity, structure, metadata, relationships, validation, interpretation, and materialization as separate responsibilities.

Each phase moves forward. No layer quietly rewrites the meaning of an earlier layer.

Traditional formats often force identity, structure, metadata, and relationships into one structural model. AEON lets them coexist without collapsing into one another.

A binding is not just a surface convenience. It declares that a value is assigned to a canonical path.

That stable identity gives tools something precise to target: diagnostics, schema rules, references, canonical comparison, hashing, and audit output.

Objects, lists, and tuples provide hierarchical structure. They group values, preserve order where order matters, and give authors ordinary document shapes without requiring runtime materialization.

Structure and runtime meaning remain separate. A container can be valid AEON long before a consumer decides what it means inside an application.

Nodes let AEON represent ordered, nested, document-like structures without forcing them into map/list shapes. They are useful for templates, prose-adjacent data, and markup-like content.

AEON Core preserves the node tree as declared. A Tonic may later materialize it as HTML, Markdown, &ND, a UI component tree, or something domain-specific, but that materialization is an explicit consumer choice.

Attributes are hard metadata: inline, structured, and attached to the thing they qualify. Semantic comments are soft metadata: advisory, annotative, or workflow-oriented side channels that do not become ordinary data bindings.

This separation lets a document carry provenance, rendering hints, semantic labels, profile hooks, documentation, and governance metadata without flattening all of those roles into content.

Clone references express value intent. Pointer references express address or identity intent. Keeping that distinction visible lets tools preserve dependency relationships instead of collapsing every reference into a terminal value immediately.

Indirection itself can be meaningful. Runtime materialization can resolve it later under consumer policy.

The center of the AEON ecosystem is not a runtime object. AEON Core produces an ordered stream of assignment events that tools can inspect before meaning is accepted.

Each event can preserve canonical path, source order, spans, datatype hints, attributes, references, and original structure. That stream becomes the stable handoff point between tools.

AEOS answers structural questions: does this path exist, does the value have the expected literal family, does the representation satisfy the schema, and is the document shape acceptable?

It does not coerce values, resolve references, execute processors, or materialize domain objects. That restraint is what makes validation usable as a boundary.

After AEOS has accepted the representation, a consumer may still need to ask whether the claims make sense in the domain. This layer brings in context, policy, conventions, and application knowledge without making AEOS guess at meaning.

The value can be syntactically valid and structurally acceptable while still being wrong for the consumer. Meaning validation is where those domain contradictions are flagged before a Tonic creates runtime objects.

A Tonic is a deterministic materializer that consumes AES, optionally relies on AEOS and meaning-validation guarantees, and creates a chosen output: a runtime object, graph, UI tree, exported file, minimized form, domain class, or rendered document.

Transformation belongs at the edge of the system, not at the center.

The ecosystem has multiple contract types because not every promise is the same kind of promise.

A document can declare a schema, profile, or convention. The consumer still decides whether that declaration maps to something trusted.

For example, the temporal convention treats these attributes as a shared interpretation agreement. AEON Core keeps them as ordinary metadata; a trusted temporal-aware consumer decides whether and how to apply them.

AEON can permit multiple deterministic surface representations when they produce the same unambiguous structure.

But that tolerance stops before semantics. AEON rejects hidden coercion, runtime guessing, parser-specific repair heuristics, and invisible interpretation.