AI-Native Linux (AIOS) is an open specification for an AI-native Linux distribution — a real Linux distro whose distinguishing layer is a cognitive core, a policy kernel, and an evidence log built on top of the standard Linux substrate.
It is a Linux distribution, not "Linux + an AI assistant bolted on." Humans express goals, the system translates those goals into typed actions, the policy kernel decides what is allowed, runtime adapters execute only approved operations, and verification produces append-only evidence. Linux remains the trusted execution substrate (kernel, drivers, scheduler, syscalls); the AIOS layer is what makes the distribution AI-native.
Public site: https://ai-os.net
Canonical repository: https://github.com/ai-os-dot-net/AI-Native-Linux
GitHub organization: https://github.com/ai-os-dot-net
| Metric | Value | Where it lives |
|---|---|---|
| Architectural layers | 11 (L0–L10 + XX cross-cutting) | Rev.2 master index |
| Contract sub-specs | 52 | one folder per layer |
| Constitutional invariants | 24 | L0 invariants |
| Typed Record types | 427 (closed enum) | L9 evidence log master enum |
| Verification properties | 32 (closed enum) | L9 verification grammar |
| INV-002 enforcement | 6 mechanical sites | "AI proposes, never executes" — wired into the IDL, not stated as a maxim |
| Wave consolidations | 13 closed (W1–W13) | last sweep: IDL roll-up of 22 → 428 RecordType entries |
| Tier 5 audit | Near-converged, SIM-D zero-findings | 9 read-only audit/simulation agents over the constitutional core |
| Total spec mass | 70 markdown files, 52,000+ lines | English artifacts, agent-readable |
Modern operating systems still treat users as command dispatchers. AI assistants can understand intent, but most current integrations collapse back into unsafe shell execution or isolated chat interfaces.
AI-Native Linux proposes a safer operating model:
- AI plans, but does not directly run arbitrary shell commands.
- System actions are typed, policy-checked, executed by capability runtimes, and verified.
- Evidence logs make system changes auditable and reproducible.
- Linux remains the trusted execution substrate.
- KDE, Web, CLI, voice, and mobile become renderers over the same cognitive core.
This matters for open source because the next generation of developer and operator tooling needs a shared safety architecture: intent, policy, typed execution, verification, recovery, and auditability.
AIOS is being built as a real Linux distribution, not a userspace add-on. The distribution components mapped onto the layer model:
| Distribution component | Where it lives in AIOS |
|---|---|
| Boot + recovery | L1 Kernel & Bootstrap — fallback kernel, recovery without LLM |
| Filesystem layout | L2 AIOS-FS — /aios semantic object store + recovery-safe / and operator /root |
| Service / package management | L3 SGR + L6 Apps/Packages |
| Authentication / identity | L4 Policy/Identity/Vault |
| Default desktop | L7 Renderers — KDE Plasma + Qt/QML; Web/CLI/Voice/Mobile as siblings |
| Networking + drivers | L8 Network/Hardware |
| Telemetry / admin | L9 Observability/Admin/Ops |
| Repos + marketplace | L10 Distribution/Ecosystem — signed bundles, three-tier trust chain (S11.1) |
| Distinguishing AI layer | L5 Cognitive Core + XX Action Envelope |
What is locked: the distribution exposes a typed action surface over Linux; AI is a first-class subject with mechanically restricted authority (INV-002 at six sites); evidence is append-only; recovery never depends on LLMs.
What is intentionally open at this stage: base distribution lineage (Debian / Arch / Fedora / from-scratch), installer ISO format, packaging format, and dedicated kernel pipeline shape. These are deliberate decisions left for the implementation phase so the constitutional contracts settle first.
This repository is currently specification-first.
There is no production runtime yet. The active work is the Rev.2 contract pack, which defines the layers, boundaries, safety model, and first implementation targets for the AI-native Linux distribution.
The project is intentionally public early so security engineers, Linux operators, AI agent builders, and open-source maintainers can review the architecture before privileged distribution code exists.
Human Goal
|
v
┌──── AIOS distribution layer ─────────────┐
│ Cognitive Core (L5) │
│ Policy Kernel (L4) │
│ Capability Runtime (L3) │
│ AIOS-FS (L2) │
└──────────────────────────────────────────┘
|
v
Linux substrate (kernel, drivers, scheduler, syscalls — L1)
|
v
Verified Evidence (append-only, L9)
Correct execution model:
AI -> Action Plan -> Policy Check -> Typed Runtime -> Verified Result
Rejected execution model:
AI -> sudo bash
.
├── 001.AI-OS.NET--SPECREV.1/ # Frozen Rev.1 vision and specification
├── 002.AI-OS.NET--SPECREV.2/ # Active Rev.2 layered contract pack
├── 003.GRANT_APPLICATIONS/ # Public grant application records
├── site/ # Public Astro site for ai-os.net
├── CODE_OF_CONDUCT.md # Community standards
├── CONTRIBUTING.md # Contribution guide
├── GOVERNANCE.md # Decision process and project rules
├── MAINTAINERS.md # Maintainer ownership
├── SECURITY.md # Security reporting and scope
├── SUPPORT.md # Support and discussion channels
├── LICENSE # Apache-2.0
└── README.md
- Rev.1 frozen — initial architecture vision (do not edit).
- Rev.2 active — layered, agent-readable distribution contract.
Rev.2 is organized as L0–L10. A layer may depend on its own layer and lower-numbered layers; it must not require a higher-numbered layer for correctness.
| Layer | Folder | Owns |
|---|---|---|
| L0 | Governance, Evidence, Safety | Status taxonomy, evidence grades, invariants, gates |
| L1 | Kernel, Bootstrap, Recovery | Linux substrate, host bootstrap, fallback kernel, recovery path |
| L2 | AIOS-FS | Semantic object filesystem at /aios, versions, views, transactions |
| L3 | SGR — Service Graph Runtime | Desired-state service graph, typed action lifecycle, adapter model |
| L4 | Policy, Identity, Vault | Policy Kernel, identity, Vault Broker (secrets-as-capabilities) |
| L5 | Cognitive Core | Intent translation, planning, memory, model routing, agent coordination |
| L6 | Apps, Packages, Compatibility | Sandboxed runtimes for Linux/Windows/Android apps and packages |
| L7 | Interaction Renderers | KDE Plasma, Web, CLI, Voice, Mobile over a shared UI schema |
| L8 | Network, Hardware, Devices | Network policy, hardware graph, drivers |
| L9 | Observability, Admin, Operations | Evidence log, verification grammar, telemetry, recovery operations |
| L10 | Distribution, Ecosystem, Marketplace | Distribution, ecosystem, marketplace, signed bundles |
| XX | Cross-cutting contracts | Action envelope lifecycle, ProxGuard reference, contracts shared across layers |
If you have 15 minutes:
- Executive summary
- Architecture overview
- L0 invariants — the constitutional core
- XX action envelope lifecycle — how a goal becomes a verified system change
- L4 policy kernel — how the system says no
- L9 evidence log — append-only audit trail with the 427-entry RecordType enum
If you have an afternoon: walk the Rev.2 master index top-to-bottom; every sub-spec is contract-grade.
ProxGuard is documented as the first candidate AIOS system app.
It can become an optional infrastructure app under:
/aios/apps/proxguard
It should expose typed service, DNS, gateway, and audit capabilities while AIOS keeps authority in policy, vault, sandboxing, verification, and evidence.
This project is a strong fit for Codex-assisted open-source development because it needs:
- large specification maintenance
- cross-layer consistency checks
- threat-model review
- Rust/Python reference implementation work
- policy and sandbox contract generation
- documentation automation
- release and audit workflow automation
See OpenAI Codex OSS application notes for the submitted application record.
The application repository URL is:
https://github.com/ai-os-dot-net/AI-Native-Linux
Public grant application records are kept under 003.GRANT_APPLICATIONS:
Contributions are welcome, but the project is still in specification phase. Start with CONTRIBUTING.md before opening an issue or pull request.
Security-sensitive findings should follow SECURITY.md.
Project governance is described in GOVERNANCE.md. Maintainer ownership is listed in MAINTAINERS.md.
Licensed under the Apache License, Version 2.0. See LICENSE.