Charter

Aeonite exists to preserve and publish neutral technical specifications and their conformance artifacts so that interoperable systems can be implemented independently of any particular vendor, implementation, or organisation.

Purpose

Its role is custodial rather than governing. Its function is definitional, not promotional. Aeonite exists so that specifications can outlive implementations, companies, and individuals.

What Aeonite Is

Aeonite is a technical specification ecosystem for meaning-aware data interchange. It is not a single product, runtime, or implementation.

The ecosystem is made up of related specifications that address different layers of the same problem: AEON for data description, AES for canonical event representation, AEOS for validation, and contract or tonic layers for downstream runtime selection and materialization.

This website is the official publication surface for that ecosystem. It defines the specifications, their boundaries, and the conformance materials needed for independent implementations to interoperate.

Normative publications

Aeonite publishes and reviews technical specifications and accompanying conformance materials.

A specification defines the expected behavior of a system in precise, implementation-independent terms. Where relevant, Aeonite also publishes canonical data models, test suites, and reference artifacts that define the observable behavior required for interoperability.

Normative documents describe what compliant systems must and must not do. Informative materials may accompany a specification but do not alter its requirements.

Conformance is established solely through the specification text and the associated test suite.

Ecosystem architecture

Aeonite specifications introduce a canonical semantic layer between text and runtime interpretation. This architecture enables multiple independent implementations to remain interoperable.

By separating description, validation, and interpretation, Aeonite specifications allow multiple independent implementations to remain interoperable.

Specification family

Aeonite publishes a family of related specifications for meaning-aware data interchange. These currently include:

• AEON — the data description language
• AES — the canonical assignment event stream data model
• AEOS — the structural schema and validation system
• Tonic contracts — interfaces for runtime materialization

Each specification is versioned independently and may evolve on separate timelines.

Understanding the architecture

Aeonite's architecture separates concerns into distinct layers, each with its own specification:

AEON

A human-readable notation for structured data that captures both content (names, values) and meaning (datatypes, attributes, references). AEON Core v1 is the canonical syntax and parsing layer.

AES (Assignment Event Stream)

The canonical output format produced by AEON parser. AES represents every binding, attribute, and value as a deterministic sequence of events. This enables consistent interpretation across implementations.

AEOS

A schema and validation layer that operates on AES output. AEOS allows you to define validation rules (type constraints, presence checks, value ranges) and validates whether AES conforms to those rules, producing a result envelope with success/failure information.

Tonics

Optional runtime materialization layer. Tonic contracts define interfaces that applications use to construct runtime objects from validated AES. Your application chooses which Tonic implementation to use (if any) based on your runtime needs.

For most use cases, you use AEON to write data and optionally validate it with AEOS. Tonics are useful for applications that require specific runtime representations. See the appendix glossary for more detailed terminology.

Specifications

View all specification sections Conformance matrix

Conformance

Conformance is test-defined. An implementation conforms to a specification if it passes the corresponding published test suite. Conformance is binary and version-scoped.

Test artifacts will be linked once the CTS surface and publication flow are ready.

How Aeonite operates

Aeonite follows a custodial publication model. There is no membership, voting, certification, or governance body.

How Aeonite Operates — Aeonite Organisation

Versioning and permanence

Once specifications and test suites are published as final, they do not change. New versions may be published alongside old ones.

Licensing

Aeonite specifications and test suites are published under permissive, irrevocable licenses. No permission, registration, or agreement is required to implement them.

Licensing Overview

Structural neutrality

Aeonite is structured so that no single implementation, organisation, or maintainer can acquire control over the meaning of its specifications.

The specification text and its conformance tests define the rules. Implementations may change ownership, transfer between organisations, or disappear entirely without affecting the specification itself.

Implementations are therefore treated as temporary participants in a longer-lived specification ecosystem.

Non-endorsement

Aeonite does not endorse, recommend, or rank implementations. References to implementations, where present, are informational only.