Skip to content

Latest commit

 

History

212 Commits

Folders and files

Repository files navigation

AIEN Architecture

The authority for how the AIEN project fits together: whole-system architecture, milestone status and what to do next. It holds documents, not product code.

AIEN is a sovereign computing stack being built in the open on an NVIDIA DGX Spark (Grace Blackwell GB10): its own operating system (AIENOS), its own reaction runtime and compiler (Omega), and its own machine realization layer (FORGE). Founding principle: closest to the metal, fastest wins. Mojo is a default, not dogma. Beat it if you can. Build what is missing.

Current state

Research-grade and pre-alpha. The AIENOS C kernel passes only some emulator gates and is not qualified; it has never been booted on the real machine (only an earlier first-boot test of the previous Rust kernel has run natively). The Omega runtime's R1 to R16 ladder was qualified on builds that predate the composition modules now in the living build, so that build is not qualified until re-run. R15 and R16 are historical passes only: requalification at omega 3108fc2 recorded R15 FAIL (14 of 16 gates) and R16 FAIL, and none of R1 to R16 is requalified on the current candidate (omega evidence/REQUAL-3108fc2/). Several programs (ARGUS, Physics Zero, DIRAC-0, the Evolution Arena) are specifications or plans with no qualified code. Nothing is described here as qualified unless a receipt says so. The live numbers are not repeated in this file because they change daily; read CURRENT_EXECUTION_PLAN.md and doctrine/ROADMAP.md.

Start here

Read in this order:

  1. Plan authority: which document wins
  2. Current execution plan: the one active cross-project plan, with receipts
  3. Canonical architecture: what the system is and who owns what
  4. Canonical milestone registry: milestone IDs and status
  5. Architecture decision records
  6. Implementation status snapshot and repository map
  7. Golden path

Superseded plans are kept only under docs/archive/plans. If two documents disagree, do not write another master plan: record the discrepancy and fix the authority. Code and reproducible evidence beat any plan.

How the repositories fit together

ATLAS AWAKENS.  AIEN PROPOSES.  OMEGA DEFINES.  FORGE REALIZES.
AEGIS VERIFIES.  HARDWARE ACTS.  EVIDENCE TEACHES.
Repository Role
aienos The trusted operating system: its own kernel replacing Linux on the DGX Spark
omega The C reaction runtime and compiler that defines computation
physics FORGE machine realization, plus historical Atlas/PHYSICS boot evidence
aien-protocols Versioned wire and state specifications
aien-sovereign-core Earlier Linux-hosted Rust runtime, legacy and being migrated

Historical PHYSICS_* milestone names stay unchanged in old milestones and evidence.

Standing rules

  • Language rule: Rust is scaffolding, Omega is the destination, C only where hardware-justified (ADR 0024, which supersedes the old Rust-to-C plan).
  • No Python, no CUDA toolkit, no systemd, no outside dependencies in the trusted base, offline builds.
  • Verdict words: PASS, FAIL, NOT_RUN, BLOCKED_HARDWARE, BLOCKED_OPERATOR, MISSING_IMPLEMENTATION. Emulator, host simulation and documents never count as hardware qualification.

Specifications and plans (not qualified code)

ARGUS-0/1, Physics Zero Atlas, DIRAC-0 and the Evolution Arena spec V1 are documents. Finite workstream plans under docs/plans/ are marked NOT A MASTER PLAN.

Building

There is nothing to build here. On main (protected as of 2026-10-01) a CI check named r16 verifies the R16 status wording against omega evidence and is required on main.

Contributing

Open a pull request against main with docs-only or doctrine changes, cite the receipt or code you are relying on, and state the external review you obtained. main is protected: no direct pushes. Questions and design ideas are welcome as issues.

License

Licensed under the GNU Affero General Public License v3.0 or later (AGPL-3.0-or-later). See LICENSE. Contact: aien@aienos.com.

About

Canonical architecture for the AIEN ecosystem: flows, boundaries, ADRs, and the map from design to implementation repositories.

Resources

Contributing

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages