Ecosystem

Documentation, packages, and a rule about who writes them

AEL is planned as three hosts. One of them is this site. The other two have addresses and owning repositories, and neither has been deployed.

The three hosts, and the state of each as of 19 September 2026.
Host What it is for State
ael.openeng.ai The AEL product site. You are reading it. This site
docs.ael.openeng.ai Language reference, tutorials, package guides, and the schema namespace. Not deployed
pack.ael.openeng.ai Package discovery, metadata and artifact delivery. Not deployed

Documentation

Language documentation belongs at docs.ael.openeng.ai, and the compiler's JSON schemas will carry $id values under docs.ael.openeng.ai/schemas. That is the intended home and the link is recorded here for that reason.

It does not resolve yet. The Docs repository's own README says there is no documentation server, site generator or deployment there yet. This site will not say “browse the docs” until there is something to browse.

In the meantime the concrete material lives here: the language page shows every construct AEL 0.1 admits, with programs that were compiled and run, and the CLI page lists every command the driver accepts.


Packages

pack.ael.openeng.ai is the intended home for package discovery and delivery. It is a planned service: no server, database, package store, registry API, package installer or deployment is implemented.

What does exist today

The compiler can install, remove and repair packages against a local offline catalog directory, behind a synchronized crash journal that all three operations recover. That part is real and you can run it.

Network acquisition is refused outright: the compiler answers “network acquisition is unavailable; supply every missing archive in the offline catalog”. There is nothing to acquire from, because there is no registry. The commands are on the CLI page.


The AEL-only package requirement

The authorship boundary AEL is aiming at is short to state: the compiler and the general language and runtime primitives are Rust; every installable AEL package is written in AEL — including HTTP and MCP servers, cloud and model adapters, and any robotics or scientific library that follows.

This is a requirement. It has not been delivered.

Both the migration and the enforcement are pending. The project's own package validation record states the limitation in as many words: no package implementation changed; the Rust HTTP prototype still needs AEL replacement. The Pack repository records that enforcement is planned and has not been implemented.

So there is no compliant package set today, and this site does not name one.

What does not satisfy the requirement

  • A package implemented in Rust — including the existing Rust HTTP prototype, which is a prototype awaiting replacement, not a compliant package.
  • A foreign SDK wrapper.
  • A native or FFI shim standing in for the package body.
  • A required package worker in another language.

The distinction the requirement turns on

An AEL-written adapter may reach an external service or device, and may reach an explicitly user-selected process workload. That is access, and it is allowed. What is not allowed is outsourcing the package implementation to that external thing. The package body has to be AEL.

Nothing about this requirement is implied by the language today, and it should be read alongside what the language currently admits: no heap, no dynamic strings, no network and no file I/O. An HTTP server cannot be written in AEL 0.1. The requirement describes where packages must end up, and the compiler work that would make it possible is the work recorded on the status page.


A note on prerequisites

The intent is that a user of a supported AEL program needs no manual Python, Rust, external compiler, assembler or linker installation. Today that intent holds for the compiled output — a linux-x86_64 image is a static ELF that needs only the kernel, and a build invokes no external tool — and does not yet hold for obtaining the compiler, which currently means cloning the Rust source and building it with the pinned toolchain.

That gap closes when there is a published artifact. There is not one yet, and this site has no downloads page for that reason.