Roadmap

Target-state roadmap. Current repository evidence is narrower than the full milestone set below.

Overview

This roadmap outlines the development path from project inception (January 2026) to the production release of AnvayaOS 1.0 (December 2030). The plan spans five years with annual milestones and quarterly deliverables.

Status Note

• Current release line: Anvaya 1.8.3 ("Interrupt-delivery repair"). It fixes the intermittent qemu-virt boot hang present since before 1.8.2 and requires the complete five-group local capture at its tag; see the 1.8.3 acceptance contract.
• Anvaya 1.8.2 ("SHAKTI boot readiness"). It adds the shakti-cclass kernel target, proven on QEMU shakti_c under OpenSBI and under Anvaya's own M-mode resident monitor, and a loading kit for a SHAKTI C-class board. SHAKTI is Buildable; physical boot stays with the 1.9 physical gate. See V1_8_2_GOAL.md, SHAKTI_HARDWARE_READINESS.md and STATUS.md. 1.8.1 was the release validation and firmware maintenance patch to 1.8.0 ("Intelligence and verification maturation"); see the 1.8.1 closure.
• Anvaya 1.7.2 ("Audit repairs and native intelligence"). The F01–F19 repair retains the complete 135-harness capability-refinement inventory and native intelligence recovery. Its acceptance uses five source-bound local gate records; see the F01–F19 closure record. This remains a QEMU-proven research release without a physical-hardware or external-audit claim. The prior stable v1.7.1 was released 2026-09-05.
• Anvaya 1.7.0 ("Capability Sockets"), 2026-08-27 — a socket is a capability with kind, resource identity, rights, and generation, and the TCP/UDP/IP/ARP/ICMP/DNS stack runs in a hybrid-signed U-mode task with its own pid, CSpace, and address space. Extraction #5 leaves zero network-service names in product core (core 20,757 → 20,740; privileged TCB 22,379 → 22,362), frames the task composes transit a real device interrupt-driven, and mesh object sync crosses those sockets. Manifesto M8 advances DEBT → PARTIAL — socket payloads still reach their reader through the service's own receive queue rather than the wire, and TCP/UDP over the wire, DNS over the wire, ICMP echo, congestion control, IPv6, and TLS remain planned areas of accepted RFC 0032.
• An earlier release, Anvaya 1.6.0 ("Content-Addressed Storage"), 2026-08-21, made durable content a userspace service and advanced M6 from DEBT to PARTIAL. The 1.x line since 1.0.0 (1.1 north-star realignment, 1.2 scheduling/IPC to spec, 1.3 proof-body dissolution and honest core/harness accounting, 1.4 the real launcher and verify-only kernel, 1.5 driver domains, 1.6 content-addressed storage, 1.7 capability sockets) continues the QEMU-proven scope below; see STATUS.md and CHANGELOG.md for the authoritative per-release detail.
• As of 2026-07-16, Anvaya 1.0.0 ("QEMU-Proven Milestone") is released — the terminal, feature-complete milestone of the 0.x line (not a production-deployed release). All five 1.0 gates (A-E) are closed to their QEMU/software scope (Gates B and D PARTIAL — external audit and physical A/B open): formally verified accepted Nucleus invariants (bounded-exhaustive proofs plus Kani harnesses, unsafe-Rust TCB 0.44%), a reviewed threat model and design-time negative-test regression suite (external audit pending), post-quantum crypto demonstrated across every trust surface with no demonstrated classical-only path (ML-KEM/ML-DSA/SLH-DSA KAT-verified against the NIST ACVP vectors; operational package sig still Ed25519), a published emulated benchmark suite, and a fully evidenced acceptance matrix. This builds on 0.5 (native AI agents), 0.6 (constitution & human override), 0.7 (post-quantum & hardware-anchored), 0.8 (device mesh), and 0.9 (usable & sustainable). Everything is proven under QEMU — no physical hardware exists yet. A physical-hardware boot, an external third-party security audit, and a hardware root of trust remain documented open items; the FML13V01 port stays Buildable, not physically boot-verified. Every milestone has an auditable goal document in the anvaya repo (V0_5_GOAL.md, V0_5_5_GOAL.md, … V1_0_GOAL.md).
• This roadmap is a planning document, not an implementation ledger.
• The current repository contains published docs, RFC-backed design contracts, an executable RISC-V/QEMU nucleus proof, bounded SDK/service/runtime/driver crates, a signed WASM proof-app catalog, and reproducible v0.3 proof scripts.
• Milestones are not considered complete until they have matching code, tests, and demonstrable evidence.
• The RFC repo now carries a mixed accepted/draft vision/spec blueprint suite. Accepted RFCs define the current design contract; draft RFCs remain direction-setting inputs, not implementation parity.

2026          2027          2028          2029          2030
  │             │             │             │             │
  ▼             ▼             ▼             ▼             ▼
┌─────┐      ┌─────┐      ┌─────┐      ┌─────┐      ┌─────┐
│ 0.1 │      │ 0.3 │      │ 0.5 │      │ 0.8 │      │ 1.0 │
│     │      │     │      │     │      │     │      │     │
│Found│      │User │      │ AI  │      │Dist │      │Prod │
│ation│      │Space│      │Native│     │ribut│      │uction│
└─────┘      └─────┘      └─────┘      └─────┘      └─────┘
Nucleus      WASM         Agents       Mesh         Release
Boots        Apps         Run          Works        Ready

2026: Foundation Year

Theme: Build the core kernel and prove it can work

Q1 2026 (Jan-Mar): Project Setup

Key Outcome: Project is publicly launched and accepting contributions.

Q2 2026 (Apr-Jun): Nucleus Prototype

Key Outcome: First-light Nucleus runs on the emulator, consumes boot metadata, proves request/reply handoffs, exercises a bounded object/task capability table, proves a staged capability-backed memory-isolation slice with owned page-table frames, inactive Sv39 satp context encoding, materialized page-table entries, one-shot satp activation/restore, U-mode page-fault capture, mapped process-owned satp ecall dispatch/restore, reusable process-bound memory frame allocation/map/unmap/revoke dispatch, process-bound cap.identify copy-out, one scheduler/launch-table-bound cap.identify/ipc.send/ipc.receive/ipc.reply/ipc.call/ipc.cancel/mem.frame_alloc/mem.map/mem.unmap/cap.revoke multi-syscall loop with checked launch-table resume, IPC delivery/reply/call/cancel/audit validation, scheduler-bound bad-length call failure validation, scheduler-bound cancel clearing/empty-idempotence validation, scheduler-bound revoked-endpoint failure/audit evidence: eight events with two failure records, process-bound wait_one/cancel_token timeout/cancel/completion, bounded scheduler wait-token timeout/cancel/complete unblocking, ipc.send copy-in with handle-backed transfer-slot validation, ipc.receive copy-out, ipc.reply copy-in, ipc.call copy-in/copy-out, bounded ipc.cancel endpoint clearing, revoked-endpoint denial, bounded CSpace IPC import/export with source-side imported-derivative revocation through cap.revoke, and IPC audit hooks through translated user windows, syscall facade copy-in/copy-out through translated user windows, page walks, and Sv39-shaped PTE records, and now has an accepted RFC 0010 syscall ABI target plus a proof-backed facade, trap-frame register adapter, one-shot/mapped/register-seeded/manifest-backed process-owned U-mode ecall proof, one scheduler/launch-table-bound manifest init entry/return proof, and minimal process/loader wrapper before the full reusable scheduler/loader-bound dispatcher and production process loader are implemented.

Q3 2026 (Jul-Sep): First Hardware

Key Outcome: Nucleus runs on physical RISC-V hardware and begins moving the bounded scheduler semantics into real task dispatch.

Q4 2026 (Oct-Dec): Nucleus Completion

🏁 Milestone: Anvaya 0.1 — "Nucleus Boots on RISC-V"

Target Date: December 31, 2026

Success Criteria:

• Nucleus boots on QEMU and real hardware
• Capability system functional (create, grant, revoke)
• IPC working (sync message passing)
• Scheduler operational (priority-based; bounded semantic proof exists, production integration remains)
• Memory management complete
• Test coverage >80% for Nucleus
• Initial Verus proofs for capability semantics

Demo: Boot Nucleus on QEMU virt, emit deterministic serial output, then prove timer-backed request/reply, task-context handoff, endpoint delegation, bounded scheduler semantics, and bounded object/task capability-table behavior before deeper kernel contracts are frozen.

2027: Userspace Year

Theme: Build the services that make an OS usable

Q1 2027 (Jan-Mar): Init System

The bounded proof slice already exercises service declaration, capability-gated registration, start, invalid-start denial, failure reporting, restart, stop, registry lookup, table-full denial, stopped-slot reclaim, and restart-limit checks, and now adds a versioned byte-backed init/service manifest ABI, capability handoff, scheduler admission, init-first dispatch, manifest-backed stack mapping, scheduler/launch-table-bound ABI ecall/return state, and service registry publication from a service manifest. Q1 2027 still needs production arbitrary stack allocation, the production userspace init process, and the real service supervisor.

Q2 2027 (Apr-Jun): Core Services

Q3 2027 (Jul-Sep): Network Stack

Q4 2027 (Oct-Dec): WASM Runtime

🏁 Milestone: Anvaya 0.5 — "AI Agents Run Natively" — ✅ RELEASED (v0.5.0, 2026-07-13)

Status: Released. All four completion gates (A–D) are closed. See CHANGELOG.md, the v0.5.0 tag, and V0_5_GOAL.md for the detailed evidence map. The parallel 0.5.5 FML13V01 hardware preview remains physically open; 0.6 — "Constitution & Human Override" is released.

🏁 Interim Milestone: Anvaya 0.5.5 — "FML13V01 First Hardware Preview" — 🚧 ACTIVE

Status: v0.5.4 keeps FML13V01 at Buildable while adding a reproducible regular-file vendor-clone media safety pipeline and deterministic hardware-log verifier to the mutually exclusive profiles, strict OpenSBI/DTB validation, pinned fixtures, and U-Boot bundle. The current candidate adds strict boot/Image/firmware identity binding plus bounded UART, one SBI TIME interrupt, SBI SRST readiness, and the signed zero-grant hello-status path. Synthetic fixtures and a compiled path do not advance the support level. It is not First light until an acquired board supplies the runtime firmware/DTB, UART, timer/reset, signed-app, and continuous transcript evidence required by V0_5_5_GOAL.md. The physical test and release runbook is the only accepted path from Buildable to the v0.5.5 App demo release and goal closure.

🏁 Milestone: Anvaya 0.6 — "Constitution & Human Override" — ✅ RELEASED (v0.6.0, 2026-07-14)

Status: Released. Gate A adds the bounded three-tier rule engine and attested amendment/rollback path; Gate B adds the firmware escape core plus a real M-mode/PMP hostile-S-mode QEMU proof; Gate C binds structured rationales to the AEC effect boundary; Gate D adds audit format v3 and verifiable redaction. The M-mode result trusts firmware, PMP, and the emulated platform, and audit v3 is tamper-evident rather than hardware-sealed against complete deletion or rollback. See V0_6_GOAL.md for the exact evidence and claim boundaries. The next feature milestone is 0.7 — "Post-Quantum & Hardware-Anchored".

🏁 Milestone: Anvaya 0.4 — "Production Substrate" — ✅ RELEASED (v0.4.0, 2026-07-12)

Status: Released. All six completion gates (A–F) are closed. See CHANGELOG.md and the GitHub release. For the detailed gate and evidence map, see V0_4_GOAL.md. The successor milestone, 0.5 — "AI Agents Run Natively", is released as v0.5.0.

🏁 Milestone: Anvaya 0.3 — "Run WASM Applications" — ✅ RELEASED (v0.3.0, 2026-07-12)

Status: Released as the 0.3.0 developer preview. See CHANGELOG.md and the GitHub release.

For the detailed implementation gate and evidence map, see V0_3_GOAL.md. The next milestone is 0.4 — "Production Substrate".

Milestone Definition: Anvaya 0.3 is the first usable single-node developer-preview OS slice: the nucleus boots in QEMU, creates real isolated userspace processes through the RFC 0010 syscall boundary, runs an init/service manager, exposes capability-protected IPC, storage, and network services, and can install and execute signed WASM/WASI applications with explicit capabilities, documented SDK support, and repeatable QEMU evidence.

Success Criteria:

• Filesystem service operational
• Network stack functional (TCP/IP)
• WASM runtime integrated
• WASI + ANVAYA extensions working
• Signed package/app manifest installed and launched with narrowed grants
• SDK released with documentation
• 10+ example applications
• Developer getting-started guide

Demo: Boot ANVAYA, connect to network, download and run WASM application, access filesystem with capability protection.

2028: AI-Native Year

Theme: Make AI agents first-class citizens

Current spec status: RFC 0002 accepts the Agent Execution Context model for identity, goals, lifecycle, supervision, approval, quotas, audit, world-model boundaries, failure/cancellation, and the relationship to normal processes, tasks, capabilities, IPC, and RFC 0010 syscalls. The bounded Gate A–D service and runtime slices are evidence-backed in the released v0.5.0 tree, including the audited Broker→AEC creation bridge, side-effect-free world model, exact approval binding/effect boundary, and capability-bound A2A coordination. These remain bounded milestone cores rather than production daemons or UI.

Q1 2028 (Jan-Mar): Intelligence Broker v1

Q2 2028 (Apr-Jun): Agent Execution Contexts

Q3 2028 (Jul-Sep): Cognitive Sandboxing

Q4 2028 (Oct-Dec): Multi-Agent Coordination

🏁 Milestone: Anvaya 0.5 — "AI Agents Run Natively"

Target Date: December 31, 2028

Success Criteria:

• Intelligence Broker operational (bounded Gate A service slice)
• AECs implemented with full accepted RFC 0002 lifecycle (bounded Gate B runtime)
• Cognitive sandboxing working (bounded Gate C core)
• Approval workflows functional (bounded Gate C core)
• Multi-agent coordination working (bounded Gate D core)
• 5+ example AI agents (roadmap stretch item, not a V0_5_GOAL.md completion gate)
• Agent development guide (roadmap stretch item, not a V0_5_GOAL.md completion gate)

Demo: Create an AI assistant agent that can read files, query the web, and take actions with user approval. Show audit trail of agent decisions.

2029: Distributed Year

Theme: Connect devices into a seamless mesh

Q1 2029 (Jan-Mar): Device Mesh Foundation

Q2 2029 (Apr-Jun): Distributed Storage

Q3 2029 (Jul-Sep): Distributed Intelligence

Q4 2029 (Oct-Dec): Interface Layer

🏁 Milestone: Anvaya 0.8 — "Multi-Device Mesh"

Target Date: December 31, 2029

Success Criteria:

• Device mesh operational
• Capabilities delegate across devices
• Storage syncs between devices
• Inference routes intelligently
• CLI interface complete
• Touch interface functional
• Desktop compositor working
• Voice interface basic support

Demo: Start a task on a wearable, continue on phone, complete on desktop. AI agent seamlessly uses compute across all devices.

2030: Production Year

Theme: Harden, optimize, and ship

Q1 2030 (Jan-Mar): Security Hardening

Q2 2030 (Apr-Jun): Performance Optimization

Q3 2030 (Jul-Sep): Ecosystem

Q4 2030 (Oct-Dec): Launch

🏁 Milestone: Anvaya 1.0 — "Production Release"

Target Date: December 31, 2030

Reconciliation (2026-07-16): the compressed development effort reached a feature-complete, QEMU-proven 1.0.0 milestone far ahead of this five-year plan. That milestone delivered the software/verification criteria below under QEMU (formal verification, PQC demonstrated, emulated benchmarks, docs). The criteria that require physical hardware, an external audit, and an ecosystem — Linux-competitive perf on real silicon, an external security audit, hardware vendor support, multiple form factors, 100+ packages, and a 100+ contributor community — remain open and define this production-launch target. Checkboxes below reflect the production-launch bar, not the QEMU milestone. The two long-lead items among them — the physical board and the external audit — carry owning milestones and review dates in Long-lead external gates.

Success Criteria:

• Nucleus formally verified (accepted invariants, bounded — QEMU/proof)
• External third-party security audit passed (design-time negative tests done; external audit OPEN)
• Post-quantum cryptography demonstrated across every trust surface (operational rekey not yet universal)
• Performance competitive with Linux for target workloads (emulated benchmarks done; physical A/B OPEN)
• 100+ packages available
• Complete documentation
• Hardware vendor support
• Multiple device form factors supported
• AI agents run reliably in production against accepted RFC 0002 semantics
• Community of 100+ contributors

Demo: Full ANVAYA installation on RISC-V laptop, running AI assistants, connected to phone and wearable, with verifiable security guarantees.

Long-lead external gates

2026-10-01 acquisition review: the user confirms no physical FML13V01 board is available. The v1.8 candidate can be validated locally under QEMU. Physical boot remains a required v1.9 gate; acquisition status must be reviewed again at the v1.8 tag. This observation does not defer or remove v1.9 acceptance.

Added 2026-08-26. Two production-launch criteria cannot be closed by any amount of QEMU work, and both have lead times measured in months. They were being carried as undated "open items"; this section gives each one an owning milestone and a review date so neither is discovered late.

Why the board is a 1.9 prerequisite, not a 1.7/1.8 one. Everything the board can prove — real timer topology, SBI reset, physical DMA isolation, boot media — sits behind the HAL and board-profile split that 1.9 is already scheduled to build (V1_1_GOAL.md). Acquiring hardware earlier would produce evidence the codebase has nowhere to put. Acquiring it later than 1.9 would leave the HAL unvalidated against real silicon, which is the one thing it exists to abstract. The acquisition itself must therefore start before 1.9 opens, which is why the review lands at the 1.8 tag.

Why the audit is deliberately deferred. The privileged TCB is 22,379 lines today against a ~15k target, and the M1 extraction march is still removing subsystems from it each release (storage left in 1.6; the network service leaves in 1.7). Commissioning an external audit against a core that is still shedding thousands of lines per release buys a report about code that will not exist. The audit is worth commissioning once the TCB is stable and the threat model (RFC 0025) is accepted rather than draft — expected after 1.9.

This is a deferral, not a dismissal. Neither gate may be quietly dropped, and neither may be claimed as met by an emulated substitute. Until both close, the 1.x line stays honestly labelled QEMU-proven and the manifesto's own "Production 1.0" bar (errata E2) remains 2030.

Post-1.0 Vision (2031+)

Anvaya 1.x Series

• Hardware vendor partnerships and commercial adoption
• Consumer device ports
• Advanced AI features (model fine-tuning, agent learning)
• Neural interface research

Anvaya 2.0 (Target: 2033)

• AGI-ready safety features
• Self-improving toolchain
• Hardware secure enclaves
• Formal verification of more components

Long-Term

• Become the standard OS for AI systems
• RISC-V default choice
• Sustainable computing standard
• Human-AI collaboration infrastructure

Resource Requirements

Team Growth Plan

Infrastructure Needs

Risk Assessment

Technical Risks

Project Risks

Success Metrics

Technical Metrics

Community Metrics

How to Help

Now (2026)

• Star the repo and spread the word
• Review and comment on architecture
• Contribute to Nucleus development
• Write documentation
• Test on RISC-V hardware

Soon (2027-2028)

• Build system services
• Develop applications
• Improve developer experience
• Create tutorials

Later (2029-2030)

• Port to new hardware
• Build commercial products
• Contribute to ecosystem
• Mentor new contributors

This roadmap is a living document. Updates are made quarterly based on progress and community feedback.

Last updated: January 1, 2026