Boot and recover.
A named target boots consistently, reports failures, and returns to a recovery path without model assistance.
NIX / PLAN
Make it work. Then prove it.
The path from a narrow hardware target to local intent, useful applications, compatibility, and acceleration.
07 / DELIVERY PLAN
Build the foundation.
Then prove the experience.
| Phase | Deliverable | Acceptance evidence |
|---|---|---|
| 0 · Freeze the target | Select one motherboard/CPU/GPU/storage/network profile; specify NIX ABI, IPC, Pod and Memory schemas | Device inventory, threat model, boot plan, open specifications |
| 1 · Core boots | Rust/C kernel, memory, scheduler, IPC, initial drivers, recovery | Boot, process isolation, storage recovery, repeatable emulator and hardware runs |
| 2 · Local intent | CPU inference, prompt shell, typed plans, minimal compositor | Offline intent → validated plan; model failure leaves a usable shell |
| 3 · Author | Native writing Pod, prompt launch, Memory broker, versioned manuscript | “Write a book” creates a workspace; text survives restart, exports, and restores |
| 4 · Research & build | Vetted catalog, opt-in source retrieval, isolated compiler, manifests and rollback | Reuse-first decisions; build cannot read unrelated Memories or secrets |
| 5 · Legacy application | VMM port/integration, Core hypervisor backend, guest provisioning and window integration | One legal Windows guest runs one selected application with tested isolation |
| 6 · Acceleration & XR | Graphics/compute drivers, game verification, XR device/runtime support | Published hardware matrix and measured performance, stability, and latency |
No delivery dates or universal application compatibility are assumed. The new kernel, graphics drivers, local-model performance, and virtualization backend are the largest engineering dependencies.
PROGRESS / MEASURED IN EVIDENCE
The next milestone
is a result you can repeat.
Save and reopen.
A real writing task survives restart, exports its content, and restores from a backup. The result is more than a successful launch.
Demonstrate compatibility.
Name the application, edition, guest or runtime, device profile, and test outcome. Publish that result before expanding the claim.
08 / NEXT DESIGN QUESTIONS
The foundations are settled.
These choices come next.
Which exact custom x64 computer is the first target?
Choose one CPU platform and one GPU model, plus storage, network, audio, and USB controllers. Decide whether a second GPU will be available for guest passthrough. This fixes the initial driver scope.
Can NIX browse the internet for research?
Recommendation: offline by default, with explicit network permission per research or installation task. All AI computation remains local in either mode.
Should Core use the proposed microkernel design?
Recommendation: a small capability-based kernel, with user-space drivers and services where practical. Confirm this architectural proposal before freezing the kernel ABI.
What should NIX prove first?
Recommendation: Author. A writing workspace proves intent, interface assembly, native Pods, Memories, and persistence without the immediate GPU and guest-OS dependencies of gaming.
How should NIX change its own interface?
Recommendation: compose vetted UI primitives first. Generated code stays inside build/application Pods, with permission review and rollback. Core remains a separately built and signed component.
FOLLOW ALONG / GET INVOLVED
Build in the open.
Learn from the evidence.
Explore the Core repository for implementation work, and use the architecture pages to understand the target design. Milestones on this page are acceptance gates, not promised delivery dates.
Explore NIX on GitHub ↗CONTINUE EXPLORINGWhy NIX?