AEON is a system of boundaries, not just a file format.

The language is the portable center, but the larger AEON idea includes contracts, profiles, validators, conformance suites, implementations, security conventions, and authoring tools that all respect the same boundary model.

That is what makes the ecosystem useful: separate tools can parse, validate, render, test, or explain the same document without quietly taking over the meaning of it.

AEON tools are expected to respect the processing phases. The parser produces an Assignment Event Stream. AEOS validates form. Tonics and host tools may interpret meaning only after the earlier phases have produced explicit, auditable output.

This lets tools compose without merging their authority. An editor can highlight syntax, a validator can reject form, and a renderer can materialize output without pretending those are the same responsibility.

source.aeon
  → lexer
  → parser
  → AES
  → AEOS validation
  → Tonic materialization

Contracts give the ecosystem a way to name expected behavior. A document can declare a target profile or schema, but that declaration is a routing hint, not a command. Consumers verify it against their trusted registry and local policy.

This is how AEON can support specialized domains without making every extension part of the core language.

aeon:mode = "strict"
aeon:profile = "aeon.gp.profile.v1"
aeon:schema = "aeon.gp.schema.v1"

document:object = {
  title:string = "Release notes"
}

The playground exercises parser and mode behavior. The schema page demonstrates AEOS validation. The templating demo shows how AEON-shaped data and node-shaped templates can produce HTML while keeping the template language custom and explicit.

Those tools should feel different because they have different jobs. Their common ground is the document model, not a shared runtime trick.

document:object = {
  title:string = "Release notes"
  tags:list<string> = ["public", "draft"]
}

template:node = <article (
  <h1(~document.title)>
)>

AEON is implemented across languages, so conformance cannot rely on informal agreement. The CTS splits behavior into lanes: core parsing, AES output, canonical form, annotation streams, and AEOS validation.

That makes the ecosystem testable. Implementations can claim the exact surfaces they support, and tools can depend on those claims when they are backed by the shared suites.

core → parsing, paths, modes, references
AES → assignment event stream
AEOS → schema validation
canonical → stable representation
annotations → structured side channels

The Assignment Event Stream is the stable handoff point. A tool can consume the same stream and become a document model, a programming object, a domain-specific class, a minimizer, a meaning validator, or a signature and audit surface without changing what the source document claimed.

That is the practical advantage of the layered design: tools can be specialized, swapped, chained, or ignored while the original text and its assignment stream remain inspectable.

AES
  → document model
  → programming object
  → domain-specific class
  → minimizer
  → meaning validator
  → signature and audit tool