Production Readiness Roadmap

Production Readiness Roadmap

Purpose

This page defines what OSAI needs to become useful for production deployment. The QEMU target is complete (milestones 0-71), but the OS is still a single-boot, cooperative, self-test-oriented prototype. This roadmap covers the gap between "QEMU complete" and "production useful."

Items are ordered by priority within each tier. Higher tiers block lower tiers.

Status Legend

Marker	Meaning
⬜ Not started	Planned but no implementation yet.
🔵 In progress	Active engineering work.
✅ Done	Implemented and tested.
⚠️ Blocked	Waiting on prerequisite design, code, hardware, or tooling.

Contents

• Tier 1: Core OS Functionality
• Tier 2: Operability
• Tier 3: AI Agent Capability
• Tier 4: Hardware Readiness
• Tier 5: Ecosystem
• Effort Estimates

---

Tier 1: Core OS Functionality

Without these, nothing real can run. These are the critical-path items.

#	Item	Description	Status
1	Real preemptive scheduler with concurrent execution	Currently all processes run sequentially (run-to-completion). A real OS must schedule multiple processes concurrently with timer-driven preemption on housekeeping cores, while preserving the no-migration guarantee on leased AI cores. Without this, only one thing happens at a time.	⬜ Not started
2	Real ELF loader with proper address space isolation	The current loader uses flat binaries from the initramfs. Production needs proper ELF segment loading (text, rodata, data, bss), per-process page tables with independent virtual address spaces, and user/kernel boundary enforcement beyond the current single-address-space model.	⬜ Not started
3	Persistent filesystem across reboots	The mutable FS works within a single boot but state doesn't survive QEMU restart in a meaningful way. Production needs the VirtIO block image to actually persist, journal replay on real boot, and fsck-style consistency checks.	⬜ Not started
4	Real TCP/IP stack with external connectivity	The network stack has internal state machines but no real packet exchange with the outside world. Production needs actual VirtIO-net integration with the network stack (not just self-test loops), proper IP/TCP checksum computation, MTU handling, and a real path from NIC queue to userspace socket.	⬜ Not started
5	Real SSH server	The remote_login subsystem is 2,317 lines of command processing but no actual SSH protocol. Production needs a real SSH daemon (or minimal SSH-2 implementation) running in userspace, with key exchange, authentication, and encrypted channels. The current OpenSSH bridge is a host-side Python script, not an in-guest daemon.	⬜ Not started

---

Tier 2: Operability

Without these, the system is not manageable in any real deployment.

#	Item	Description	Status
6	Real-time clock and wall time	Only monotonic timer exists. Production needs wall-clock time (NTP or at minimum RTC), timestamps for logs, file modification times, certificate validation, and scheduled operations.	⬜ Not started
7	Proper logging daemon with persistent log storage	Currently logs go to serial only. Production needs a ring buffer, log rotation, persistent log files on the mutable FS, and log retrieval via osctl or SSH.	⬜ Not started
8	Process crash recovery and restart policies	The service supervisor tracks states but doesn't actually restart crashed processes. Production needs watchdog timers, automatic restart with backoff, crash dump collection, and core-dump-equivalent diagnostics.	⬜ Not started
9	Package/update delivery mechanism	The update subsystem models transaction states but has no actual mechanism to receive, verify, and install OS images. Production needs a signed update transport (HTTP fetch or push), image verification, staged installation, and atomic swap on reboot.	⬜ Not started
10	Hardware watchdog and panic recovery	The kernel panics and halts. Production needs a hardware watchdog (VirtIO or platform), automatic reboot on hang, and a boot counter to fall back to the previous known-good image after repeated failures.	⬜ Not started

---

Tier 3: AI Agent Capability

Without these, OSAI can't do its actual job — running embedded AI agents that improve applications.

#	Item	Description	Status
11	Real CPU inference runtime with actual model execution	The CPU AI runtime is a deterministic skeleton with fixed outputs. Production needs real matrix/tensor operations, at minimum GGUF or similar model format loading, quantized INT8/INT4 kernels, attention computation, and tokenizer execution for small models (e.g., Phi-3-mini, Llama-3-8B quantized).	⬜ Not started
12	Real source-code indexing	The source index loads a 2-file fixture. Production needs to actually parse and index a real Git repository — walk the tree, tokenize source files, build symbol tables, and maintain dependency graphs.	⬜ Not started
13	Real Git operations	The Git workspace agent models metadata/lifecycle but doesn't speak Git protocol. Production needs at minimum libgit2-equivalent functionality: clone, diff, apply patch, commit, and push over SSH or HTTPS.	⬜ Not started
14	Real build/test sandbox execution	The sandbox models build/test as metadata transitions. Production needs to actually fork a process, run a compiler or build tool inside the sandbox with filesystem and network restrictions, capture stdout/stderr, and report pass/fail.	⬜ Not started
15	App-agent command protocol	No actual external API exists for sending requests to an AI cell. Production needs a defined protocol (HTTP/REST, gRPC, or custom TCP) that accepts agent requests, dispatches them to the correct AI cell, and streams responses back.	⬜ Not started

---

Tier 4: Hardware Readiness

Without these, OSAI won't survive real deployment on physical hardware.

#	Item	Description	Status
16	NUMA-aware memory allocation	The PMM treats all memory as flat. On Xeon and multi-socket systems, memory locality is critical for performance. The allocator must be NUMA-node-aware from the start.	⬜ Not started
17	IOMMU/SMMU enforcement	Currently defined in the architecture but not implemented. DMA-capable devices (NICs, NVMe) can read/write arbitrary physical memory without protection. This is a security and stability requirement.	⬜ Not started
18	Kernel ASLR and stack canaries	No memory layout randomization or stack protection. The kernel text/data addresses are deterministic across boots. Production needs basic exploit mitigations.	⬜ Not started
19	Rate limiting and resource quotas per AI cell	AI cells declare resources upfront but there's no runtime enforcement of CPU time, memory bandwidth, or network bandwidth quotas during operation. A misbehaving cell could starve others.	⬜ Not started
20	Proper PCI/PCIe enumeration beyond discovery	The x86_64 path does basic PCI discovery but no proper bus enumeration, BAR sizing, capability walking, or MSI/MSI-X interrupt setup needed for real NVMe and high-performance NICs.	⬜ Not started

---

Tier 5: Ecosystem

Without these, the project won't be adopted by external developers.

#	Item	Description	Status
21	Selective POSIX compatibility layer	Not full POSIX, but enough to run common tools: a shell with pipes/redirection, cat, ls, cp, basic sed/grep. Developers need to debug and inspect the system interactively.	⬜ Not started
22	CI/CD pipeline with automated QEMU regression	The gate scripts exist but there's no GitHub Actions or CI configuration. Every push needs automated smoke boot, regression tests, and report generation.	⬜ Not started
23	Performance benchmarking against Linux/BSD baselines	No comparative data exists. Production credibility requires running the same workloads on tuned Linux (with isolcpus, CPU pinning, kernel bypass) and showing where OSAI actually wins.	⬜ Not started
24	Developer documentation for external contributors	No API docs, no architecture guide beyond the wiki, no "getting started" for someone who wants to write an app-agent or contribute a driver.	⬜ Not started
25	Licensing decision	Still "to be decided." No one can use or contribute to an unlicensed project in production.	⬜ Not started

---

Effort Estimates

Tier	Scope	Items	Rough estimate
Tier 1	Core OS functionality	1-5	6-12 months of focused engineering
Tier 2	Operability	6-10	2-4 months
Tier 3	AI agent capability	11-15	4-8 months
Tier 4	Hardware readiness	16-20	3-6 months
Tier 5	Ecosystem	21-25	Ongoing

Critical path: Items 1-5. Without concurrent scheduling, real networking, and real SSH, the OS can't run any real workload regardless of how good the architecture is.

Dependencies

Tier 1 (items 1-5)
  └── Tier 2 (items 6-10)
        └── Tier 3 (items 11-15)
              └── Tier 4 (items 16-20)
                    └── Tier 5 (items 21-25)

Tier 1 items are largely independent of each other but all must be complete before Tier 2 makes sense. Tier 3 requires Tier 2 operability (logging, crash recovery, updates). Tier 4 requires Tier 3 to be working in QEMU before porting to physical hardware. Tier 5 is ongoing but becomes priority after Tier 4.

Related Pages

• Project Tracker
• Implementation Plan
• QEMU 100 Completion Plan
• Roadmap
• Open Decisions
• Risk Register