Key Features

AEON Key Features

AEON is more than a notation language.

It is a deterministic, layered data transportation system designed to safely move structured information between systems while keeping structure, validation, and meaning clearly separated.

The individual features are useful on their own. The important part is how they compose.

1. Deterministic

AEON is designed to produce consistent results across implementations.

The specification prioritizes:

• predictable parsing
• deterministic processing
• stable canonical output
• reduced ambiguity

The goal is that the same document should produce the same structural interpretation regardless of platform or implementation.

2. Non-Executable

AEON is intentionally not a programming language.

AEON transports data:

• it does not execute logic
• it does not evaluate expressions
• it does not embed runtime behavior

This improves:

• security
• predictability
• portability
• validation safety

Runtime behavior belongs to consumers and Tonics after the relevant validation boundaries have been accepted.

3. Non-Coercive Core

AEON avoids implicit coercion inside the core transport layer.

The parser does not silently reinterpret values.

For example:

• strings do not automatically become numbers
• booleans are not inferred from arbitrary labels
• semantic interpretation is delegated downstream

This helps preserve author intent and reduce ambiguity.

4. Explicit By Design

AEON encourages explicitness rather than implicit interpretation.

Authors can explicitly define:

• types
• references
• structure
• constraints
• metadata
• conventions

The system avoids hidden behavior wherever possible.

5. Layered Validation

AEON separates validation into distinct processing phases.

Typical layers include:

1. Syntax validation
2. Structural validation
3. Schema/form validation
4. Meaning/domain validation
5. Materialization

This separation allows each stage to validate only what it is responsible for.

6. Typed Transport Language

AEON supports:

• untyped transport data
• explicit Core types
• custom type labels

This allows authors to progressively increase precision where required, while still supporting lightweight authoring workflows.

Custom types are intentionally transport-level declarations:

• the parser recognizes them structurally
• meaning is delegated to downstream consumers

7. Hybrid Structural Model

AEON supports multiple structural paradigms within a unified system.

These include:

• key/value bindings
• map-like objects
• ordered lists
• tuples
• tree-oriented document structures
• graph-style references

This allows AEON to model both:

• application data
• document-oriented structures

without forcing everything into a single abstraction.

8. Native Addressing System

AEON includes a DOM-like addressing model.

This enables:

• deterministic path resolution
• stable references
• structural navigation
• graph relationships
• canonical addressing

The addressing model unifies document, map, indexed-child, attribute, and graph traversal concepts.

9. Explicit Referencing

AEON supports explicit references between structures.

These references distinguish between concepts such as:

• clone/copy intent
• pointer/reference intent

This allows graph-style relationships while maintaining deterministic processing rules.

10. Canonical Representation

AEON supports canonical forms to ensure stable structural equivalence.

Canonicalization enables:

• deterministic hashing
• reproducible signatures
• reliable diffing
• transport normalization
• structural equivalence checking

Canonical form is separate from semantic interpretation.

11. Hard And Soft Annotation

AEON separates metadata into two distinct channels.

Hard Annotation

Implemented through attributes:

• structural
• deterministic
• part of the canonical data model

Soft Annotation

Implemented through semantic comments:

• documentation
• hints
• semantic guidance
• tooling metadata

Soft annotations are processed through a separate annotation stream and do not alter canonical data semantics.

12. Annotation Stream Architecture

Comments and semantic annotations are not discarded.

Instead, AEON can emit:

• a canonical event stream (AES)
• a parallel annotation stream

This allows tooling, documentation systems, and semantic processors to operate without mutating the core data model.

13. Platform Agnostic

AEON is designed as a cross-platform transport language.

It is not tied to:

• a specific runtime
• operating system
• programming language
• execution model

AEON documents can move between heterogeneous systems while preserving structure and intent.

14. Extensible Through Conventions

AEON supports conventions and profiles for domain-specific behavior without modifying the core language.

This enables ecosystems to define:

• domain contracts
• shared interpretation rules
• validation profiles
• temporal conventions
• collection conventions

while preserving interoperability at the transport level.

15. Separation Of Concerns

AEON separates:

• representation
• structure
• validation
• interpretation
• materialization

This layered architecture prevents semantic concerns from leaking into the transport layer.

16. Security-Oriented Design

AEON follows a zero-trust philosophy:

• transport is isolated from execution
• meaning is delegated
• validation is layered
• parsing is deterministic
• executable behavior is excluded from Core

This reduces entire classes of ambiguity and execution-related risks common in executable serialization systems.

The Sum Is The Feature

AEON's value is systemic.

Typed transport makes claims visible. Deterministic processing makes claims comparable. Canonical form makes them stable. AEOS validates form. Meaning validation belongs to the consumer. Tonics materialize only after those boundaries are accepted.

That is why AEON should be understood as a system, not only as syntax.