<!-- Explore -->
# Current implementation line and supporting repositories.
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.
[View npm packages](https://www.npmjs.com/search?q=%40altopelago%2Faeon)
[View Rust crate](https://crates.io/crates/altopelago-aeon)
[View Python package](https://pypi.org/project/altopelago-aeon/)
[Open implementation repo](https://github.com/AltoPelago/aeon)
<!-- Release Line -->
## 0.16.0 at a glance.
### AEON 0.16.0
_Current Version_
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.
[View releases](https://github.com/AltoPelago/aeon/tags)
### TypeScript packages
_Package Family_
Lexer, parser, AES, canonicalization, finalization, AEOS validation, runtime, SDK, CLI, Tonic, and WebAssembly package surfaces under the @altopelago scope.
[Open npm scope](https://www.npmjs.com/org/altopelago)
### altopelago-aeon
_Rust Package_
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.
[Open crates.io](https://crates.io/crates/altopelago-aeon)
### altopelago-aeon
_Python Package_
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.
[Open PyPI](https://pypi.org/project/altopelago-aeon/)
### Aeonite AEON specs
_Specification Target_
The implementation follows the public Aeonite specification and conformance repositories rather than treating implementation behavior as the authority.
[Open specs](https://aeonite.org/specifications.php)
<!-- 0.16.0 Migration -->
## Review canonical bytes, generic arguments and numeric clarifier ASTs.
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.
[Read 0.16.0 migration guide](https://github.com/AltoPelago/aeon/blob/main/docs/migration-0.16.0.md)
[Read changelog](https://github.com/AltoPelago/aeon/blob/main/CHANGELOG.md)
<!-- 0.15.0 Migration -->
## Review projected namespace changes before upgrading adapter consumers.
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.
[Read migration guide](https://github.com/AltoPelago/aeon/blob/main/docs/migration-0.15.0.md)
[Read changelog](https://github.com/AltoPelago/aeon/blob/main/CHANGELOG.md)
<!-- 0.14.0 Compatibility -->
## The 0.14.0 literal and temporal reader boundary still applies.
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.
- **Symbols** Pipe-delimited symbolic literals such as |approved| remain distinct from strings through parsing, AES projection, canonical output, and schema validation.
- **Trimticks** Trimticks 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 0000** Core 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 seconds** One 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 60** Core 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 -->
## Implementation repositories are split by language runtime.
These repositories are where AEON behavior becomes executable code. They track the Aeonite specs and CTS while exposing practical package surfaces for application builders.
- **TypeScript** AltoPelago/aeon contains the current npm package line: lexer, parser, AES, AEOS, canonicalization, finalization, runtime, SDK, CLI, LSP, WebAssembly, tests, and release plumbing.
- **Rust** The 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.
- **Python** The published altopelago-aeon package provides native CPython 3.12 through 3.14 bindings through the altopelago.aeon import path.
- **PHP** AltoPelago/aeon-php covers PHP lexer, parser, core behavior, AEOS, Tonic, CTS integration, and PHP application surfaces.
[TypeScript, Rust, Python](https://github.com/AltoPelago/aeon)
[Rust package](https://crates.io/crates/altopelago-aeon)
[Python package](https://pypi.org/project/altopelago-aeon/)
[PHP implementation](https://github.com/AltoPelago/aeon-php)
<!-- Helper Repositories -->
## Helper repositories support learning, authoring, and inspection.
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 -->
## AltoPelago/aeon-examples
Example projects show how AEON is used from application code and small demos.
- **Runtime examples** Small projects for TypeScript, Python, and Rust surfaces that demonstrate common parsing, validation, and runtime flows.
- **Schema examples** Shared schemas and validation fixtures for reference-safe documents and browser-facing demos.
- **Starter integrations** Compact examples intended to help a new adopter move from inspection to application code.
[Open examples](https://github.com/AltoPelago/aeon-examples)
<!-- Tooling Repo -->
## AltoPelago/aeon-tooling
Tooling helps people author, highlight, inspect, and package AEON outside the runtime itself.
- **Editor support** VS Code language extension, theme, grammar, diagnostics wiring, and bundled language-server packaging.
- **Grammar assets** Tree-sitter work and syntax grammar assets for editor and tooling integrations.
- **Web and conversion tools** Web highlighter, markdown-to-&ND converter, package scripts, and authoring utilities.
[Open tooling](https://github.com/AltoPelago/aeon-tooling)
<!-- Tonics Repo -->
## AltoPelago/aeon-tonics
Tonic work sits above transport-level AEON and explores consumer-authorized materialization conventions.
- **Materialization conventions** Conventions for turning validated AEON into accepted runtime or output forms under consumer policy.
- **Trusted output experiments** Experiments around how consumers accept, transform, and emit materialized data.
- **Examples above Core** Examples that deliberately sit above the core notation layer without redefining AEON itself.
[Open Tonic work](https://github.com/AltoPelago/aeon-tonics)
<!-- Conformance -->
## The specs and CTS define the shared target.
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-specs** Specification source for AEON, AEOS, NEON, &ND, contracts, conventions, drafts, and supporting language artifacts.
- **aeonite-org/aeonite-cts** Conformance test suite used to compare implementations and keep behavior aligned across runtimes.
[Open specs repo](https://github.com/aeonite-org/aeonite-specs)
[Open CTS](https://github.com/aeonite-org/aeonite-cts)
