Start typing to search the site.
Explore
AEON 0.16.0 is the current coordinated AltoPelago implementation line, published for TypeScript on npm, Rust on crates.io, and native Python on PyPI. The language remains AEON v1.
Use this page as a quick map for the public repositories around the implementation. The formal language specifications and CTS live with Aeonite; the implementation packages and learning surfaces live here.
Release Line
The coordinated release introduces reference-safe canonical ordering, type-only generic arguments, exact numeric clarifiers and radix checks, GP validation across metadata, and aligned Film depth accounting. Historical integrity verification bytes are unchanged.
Lexer, parser, AES, canonicalization, finalization, AEOS validation, runtime, SDK, CLI, Tonic, and WebAssembly package surfaces under the @altopelago scope.
Public Rust facade for compiling, validating, loading, materializing, and exchanging AEON. Supporting Core, Document, AEOS, and finalization crates share the 0.16.0 release line.
Native bindings for CPython 3.12 through 3.14, exposing compilation, canonical formatting, document loading, AEOS validation, file helpers, Telex, and metadata-preserving Pytonic views through altopelago.aeon.
The implementation follows the public Aeonite specification and conformance repositories rather than treating implementation behavior as the authority.
0.16.0 Migration
Canonical source output now uses reference-safe-v1: authored references are validated before sorting, and each sortable scope emits its smallest eligible decoded key. List, tuple and node-child positions are unchanged. Invalid authored references fail rather than being repaired by sorting; canonicalization is not GP or schema approval.
Generic arguments must be datatype descriptors, not bare numbers or strings. Numeric clarifiers follow value-number normalization without host-number rounding; TypeScript and pure-Python parser ASTs retain NumberLiteral nodes. GP and radix consumers validate bases exactly, including metadata and tag-head claims.
Stored canonical bytes must retain their original contract. Library callers can explicitly select lexical-v1 for historical source output; integrity event hashing and receipt verification keep their separate historical assignment projection. Source canonicalization, portable AES hashing and integrity event bytes are not interchangeable.
Independent providers remain SANSA 0.14.2 and AES Telex 0.3.1. The TypeScript Film surface remains reader-only, with logical depth accounting aligned to the shared AES contract.
0.15.0 Migration
The TypeScript SANSA adapter now uses portable node topology: $.value[0] identifies the first node head, and its first content item is $.value[0][0]. Representation names use normative PascalCase, reference payload paths are absolute portable addresses, and binding metadata is distinct from node-head metadata.
These adapter changes are breaking for consumers of the old projection. They do not change AEON source syntax or ordinary JSON-profile loader calls. Existing immutable CTS claims are not renamed for this implementation release.
In 0.15.0, SANSA 0.14.2 and AES Telex 0.2.0 were independently versioned providers. Reduced-date datetime and WTC forms remain accepted, but clock-bearing reduced-date temporal relations remain conservatively incomparable.
0.14.0 Compatibility
Introduced in 0.14.0 and retained in 0.16.0: writers must avoid emitting symbolic literals, reduced-precision dates, or the expanded temporal grammar to readers that have not declared support; specification promotion remains a separate Aeonite governance action.
SymbolsPipe-delimited symbolic literals such as |approved| remain distinct from strings through parsing, AES projection, canonical output, and schema validation.
TrimticksTrimticks now use one > marker and derive an exact space-or-tab gutter from their payload. Older width-bearing openers are no longer part of the 0.14.0 grammar.
Year 0000Core dates become exactly 0001 through 9999. Data using 0000 must be rejected, migrated to a domain-specific calendar object, or preserved as opaque source data rather than silently shifted.
Fractional secondsOne or more decimal digits may follow a complete seconds field. Core readers and writers preserve arbitrary accepted scale and trailing zeroes; the general-purpose schema admits at most nine authored digits, while higher-precision domains need an explicit schema and materialization policy.
Second 60Core preserves a structurally plausible positive leap-second claim. The general-purpose schema rejects it for typed and untyped temporal literals. Leap-aware consumers need pinned authority data and an explicit preserve, reject, fold, clamp, or named-smear materialization policy.
Timezone gaps, overlaps, named places, non-UTC timescales, and clock smears remain downstream resolution concerns. A lexical Z is an authored UTC anchor; it is not proof that the source clock was unsmeared or exactly aligned with UTC.
Implementation Repositories
These repositories are where AEON behavior becomes executable code. They track the Aeonite specs and CTS while exposing practical package surfaces for application builders.
TypeScriptAltoPelago/aeon contains the current npm package line: lexer, parser, AES, AEOS, canonicalization, finalization, runtime, SDK, CLI, LSP, WebAssembly, tests, and release plumbing.
RustThe published altopelago-aeon facade and its Core, Document, AEOS, and finalization crates provide the 0.16.0 Rust implementation, shared document navigation, and portable AES/Telex integration.
PythonThe published altopelago-aeon package provides native CPython 3.12 through 3.14 bindings through the altopelago.aeon import path.
PHPAltoPelago/aeon-php covers PHP lexer, parser, core behavior, AEOS, Tonic, CTS integration, and PHP application surfaces.
Helper Repositories
These repositories are not separate language definitions. They provide examples, editor support, grammar assets, converters, web highlighting, materialization experiments, and learning surfaces around the implementation line.
Example Repo
Example projects show how AEON is used from application code and small demos.
Runtime examplesSmall projects for TypeScript, Python, and Rust surfaces that demonstrate common parsing, validation, and runtime flows.
Schema examplesShared schemas and validation fixtures for reference-safe documents and browser-facing demos.
Starter integrationsCompact examples intended to help a new adopter move from inspection to application code.
Tooling Repo
Tooling helps people author, highlight, inspect, and package AEON outside the runtime itself.
Editor supportVS Code language extension, theme, grammar, diagnostics wiring, and bundled language-server packaging.
Grammar assetsTree-sitter work and syntax grammar assets for editor and tooling integrations.
Web and conversion toolsWeb highlighter, markdown-to-&ND converter, package scripts, and authoring utilities.
Tonics Repo
Tonic work sits above transport-level AEON and explores consumer-authorized materialization conventions.
Materialization conventionsConventions for turning validated AEON into accepted runtime or output forms under consumer policy.
Trusted output experimentsExperiments around how consumers accept, transform, and emit materialized data.
Examples above CoreExamples that deliberately sit above the core notation layer without redefining AEON itself.
Conformance
Conformance work lives under Aeonite so implementation behavior can be checked against an independent specification and test surface. AltoPelago implementations should follow these repositories rather than becoming the authority themselves.
aeonite-org/aeonite-specsSpecification source for AEON, AEOS, NEON, &ND, contracts, conventions, drafts, and supporting language artifacts.
aeonite-org/aeonite-ctsConformance test suite used to compare implementations and keep behavior aligned across runtimes.