Roadmap

This page owns capOS’s long-range architecture, outcome sequencing, and milestone history. It deliberately does not mirror live task state or current implementation detail.

Current Direction

The live selected milestone is Public-Ready Multi-User Web UI. That value was verified against the loopyard project setting at this page’s review time; loopyard remains authoritative if it changes. Current Status summarizes the implemented boundary.

The outcome is a self-served Web UI whose anonymous ingress, authenticated sessions, lower-layer socket use, response delivery, and cleanup are bounded and observable under concurrent load. Completion requires independent browser sessions, generation-correct bounded delivery, and local ceiling and adversarial-coexistence evidence. Provider preflight, private billable proof, provider-health proof, and public Internet/TLS exposure are separate steps; each real provider or exposure action still requires fresh authorization.

Task status, dependency edges, per-slice readback fields, and current hold reasons belong in loopyard and the owning Resource Governance contract, not here.

Architectural Sequence

The numbered stages describe dependency direction, not a dispatch queue. Loopyard selects the concrete milestone and may interleave independent work when its dependencies and conflict domains permit it.

Foundations: Stages 0 Through 5

The bootable kernel, virtual memory, Ring 3 transition, process abstraction, shared capability ring, and preemptive scheduling foundation are complete. Their current behavior and validation live in Current Status, the Repository Map, and the architecture pages. Future work must extend these mechanisms without reopening the interface-as-permission model or adding ambient authority.

Stage 6: Capability IPC And Service Composition

The landed baseline includes cross-process Endpoint calls, copy/move transfer, local release and revocation, process spawning, immutable session context, notification objects, MemoryObject-backed zero-copy sharing, and one-hop promise pipelining over kernel and Endpoint antecedents.

The remaining architectural outcomes are:

• service-facing SharedBuffer interfaces over the MemoryObject substrate;
• promise chains deeper than one dependent hop, with an ABI-owned answer allocation identity;
• stable service audit identity across intentional replacement or upgrade;
• restart and notification-driven service composition without widening init or kernel authority.

Current contracts are owned by Capability Ring, IPC And Endpoints, Session Context, and Service Architecture. Detailed remaining work belongs in the linked backlogs and loopyard.

Stage 7: Concurrent Runtime, Networking, And Remote Operation

The landed baseline includes AP boot and selected-AP user execution, multi-process and in-process scaling proofs, fair-share scheduling, SchedulingContext budget enforcement and bounded Endpoint donation/return, bounded SQPOLL/nohz operation, a userspace TCP/IP stack, native shell, and focused remote-session/Web UI paths.

The remaining outcome families are:

• concurrent scheduler ownership beyond the current selected-owner model and direct high-core hardware evidence;
• EEVDF and realtime-island policy evaluation after the existing budget and isolation-capability substrate;
• userspace-poller and device-queue placement under explicit policy;
• production SSH and WebShell over durable account/key material, session lifecycle, the userspace network stack, and auditable listener authority;
• standard Cap’n Proto RPC proxy transport and network-transparent services.

See Scheduling, Userspace Runtime, Networking, and the Stage 7 backlogs. The historical plaintext Telnet and kernel-socket fixtures are not production targets.

Hardware, Storage, And Portability

The local/QEMU storage substrate is complete through RAM-backed naming, virtio-blk, read-only and writable filesystems, persistent stores, bounded recovery, host-directory passthrough, and the installable-system proof. Device authority has landed for bounded DeviceMmio, DMAPool, and Interrupt paths, with a fail-closed DMA backend decision.

Long-range work remains:

• production-hardware IOMMU programming and direct-remapping evidence beyond the bounded QEMU Intel path;
• high-throughput and multiqueue NIC/storage ownership in userspace;
• broader filesystems, secure boot, signed system generations, and production recovery policy;
• AWS and Azure provider ports and separately authorized cloud proofs;
• an aarch64 port after the x86_64 hardware abstraction is stable: EL0/EL1 entry, GICv3, ARM generic timer, PL011, TTBR layout, per-CPU state, and the architecture linker boundary.

Current storage and device behavior is in Current Status, Storage And Naming, the device maps, and DMA Isolation.

Identity, Policy, And Audit

The target is a durable identity and policy plane that grants narrow bundles to local, remote, service, guest, and external principals. Remaining outcomes include durable multi-account credentials and recovery identities, passkeys and explicit OIDC bindings, per-account/session resource profiles, policy labels implemented as wrapper capabilities, and persistent charged audit storage with protected recovery capacity. Authentication claims never substitute for resource admission or capability authority.

See User Identity And Policy, Local Users, and Trust Boundaries.

Security And Verification

Verification remains layered: host tests for pure logic, focused QEMU proofs for system behavior, bounded Loom/Kani/TLA+/Alloy models for named invariants, dependency and generated-code checks, and independent review. Bounded models must keep their bounds explicit and must not be described as universal proofs.

Future proof work follows concrete hazards: weak-memory and teardown races, untrusted-service exhaustion, public-ingress coexistence, durable recovery, high-core scheduling, and production device ownership. The owning sources are Verification Workflow, Security And Verification, and REVIEW.md.

Future Tracks

These tracks are not selected merely by appearing here. Promote one into loopyard only when it becomes a concrete visible outcome with an owning design and bounded acceptance evidence:

• aarch64 and broader production hardware support;
• Rust std, broader native C/POSIX and WASI, Go, Python, JavaScript/TypeScript, PUC Lua compatibility, C++, and browser/WASM support;
• GPU/media capability integration, robotics realtime control, and scientific-agent workflows;
• system monitoring, trusted time and clock authority, cloud metadata, volume encryption, formal MAC/MIC modeling, and debug/trace authority;
• network transparency, persistence-at-scale and checkpoint/restore, live upgrade, crash recovery and supervision, and federated multi-instance demos;
• SDK publication and distribution follow-ons, including the live-proxy Cap’n Proto RPC transport tracked by SDK Dual Transport;
• typed native command surfaces that replace prototype application-owned StdIO parsing, as designed in Interactive Command Surfaces;
• the self-hosted agent task backend described below.

Native no-std Rust, a bounded native C/POSIX adapter, and the WASI host adapter are implemented baselines; their presence does not complete the broader runtime tracks above.

The shared-service track continues to use chat, Adventure, and Paperclips to exercise resident services and capability-native clients. Per-feature demo narrative belongs in git history and the owning demo/backlog page, not in this roadmap.

Cross-Cutting Long-Range Tracks

Whitepaper

The schema-as-ABI paper consumes evidence from the implementation tracks; it does not define a second implementation plan. Its outline, evidence gaps, and claim boundaries live in docs/paper/ and papers/schema-as-abi/. Missing evidence stays explicit there until a normal implementation milestone produces it.

Self-Hosted Task Backend

The long-term outcome is a capability-native coordination backend running on capOS with durable validated tasks, dependency-derived runnable state, conflict-domain checks, and generation-fenced leases. PostgreSQL-backed loopyard is the current task authority and semantic reference. The bounded capOS coordinator, 9p persistence, HTTP/JSON adapter, and vibe-loop adapter are development proofs, not production storage, authentication, or public ingress. The gap inventory is Self-Hosted Task Backend.

Formal And Model-Based Engineering

seL4 HAMR and related model-driven techniques remain evaluation tracks rather than commitments to replace the Cap’n Proto-first runtime. Adopted techniques must preserve schema-defined interfaces, capability confinement, bounded resource accounting, and the existing executable proof workflow. See seL4 HAMR and seL4.

Milestone History

This ledger preserves named project outcomes. The timestamp is the recorded anchor or closeout time; the commit is the reviewed history anchor, not a claim that every later hardening change is contained in that one commit. Detailed measurements, commands, residuals, and follow-up slices belong in the Changelog, git history, and loopyard.

The active Public-Ready Multi-User Web UI outcome is not a closeout and is not entered in this table. When the live selected milestone closes, record one verified row here, keep detailed evidence in its owning sources, and let loopyard select the next visible outcome.