AI is the interface
No desktop, no app grid. The system boots into a conversation, and programs emerge from your sentences.
raiOS · Genesis
A calm interface for anAI-native operating system.
raiOS keeps trust, recovery, and physical approval in the kernel. Personal programs run in constrained, isolated surfaces — visible and verifiable.
The Surface photo and reflection overlay appear here.
In 32 seconds
From one sentence to a running program.
The build-everything layer in action
The sequence begins where everything begins: with your sentence. The system then assembles only what it needs — the foundation, the agent, network access for knowledge, and an offline builder layer with explicit capabilities. It iterates until every check is green. Only a signed result may pass through the gate.
What is raiOS?
An operating system that boots into AI.
raiOS is written from the first line in Rust, with no Linux or Windows underneath. At the bottom, the kernel owns the hardware and its native drivers. Above it sits the Genesis layer: a narrow foundation that creates Wasm services and grants only explicitly named imports. Agent, network API, builder, and programs live in separate cages. If one traps, only its cage is lost — never the whole house.
From request to program
You say it. The system builds, tests, and signs it.
The path every program must take
An agent writes the program onboard. The system tests and signs it, and it may run only after your approval on the device. Every step is recorded. If anything is wrong, rollback restores the last known-good state.
Rights are capabilities
A Wasm service gets exactly the doors you give it.
Rights are not checkboxes in a menu; they are explicit objects. The Genesis layer gives a Wasm service only named imports: a framebuffer region, input events, or exactly one file. Without an import, no door exists. PCIe, DMA, and IOMMU boundaries remain a target: VT-d structure is checked, while active translation and DMA isolation are still open.
The capability bundle
The Wasm service receives only fb and input.
Each import opens exactly one door. If it requests the ungranted
network import, there is no door and no host effect. That works
today; the IOMMU DMA boundary remains future work.
Stop immediately, restart cleanly
If a Wasm service gets stuck, Genesis revokes its imports, stops it, and starts a fresh instance without rebooting the system. A concrete sub-second SLA has not yet been proven.
Wasm is the cage
Drivers deliberately stay in the kernel.
raiOS does not move its drivers into separate domains today. USB, graphics, networking, and other hardware paths remain native and kernel-resident until the Wasm service world is robust. The hard boundary sits above them: replaceable services run as Wasm with explicit imports. If one traps, the kernel remains alive.
Protection sits above the drivers
On the left is the familiar risk: native driver code shares the kernel's fault domain. raiOS does not yet claim isolated driver restarts. On the right is today's real cage: a replaceable Wasm service traps, and only its instance restarts.
From interrupt to granted import
The network card signals; the native kernel driver handles IRQ and DMA. A Wasm service sees only the narrow, granted import. It cannot address either the device or a DMA region directly.
Evidence, not promises
What is tested today must fail hard.
Two boundaries are real negative tests today: a Wasm service accesses memory outside its region and traps; an ungranted import is completely absent and produces no host effect. Blocking foreign DMA through the IOMMU remains future work: VT-d has a structural check, but no active translation yet.
Two real attacks, one future test
OOB access and import denial run as fixed tests and must fail, or the build remains red. The third lane shows the open step honestly: IOMMU translation and real DMA isolation are not active yet.
Every version can roll back
If a new version fails, the domain returns to the last known-good state. Every build and every test leaves a report in the archive; nothing happens unobserved.
Honestly: raiOS does not have a mathematical proof. Instead, it uses predicates, negative tests, and rollback from day one — a documented tradeoff, not an accident. Before other people use the system, signed, reproducible builds and an audit log for every grant will be added.
The system knows itself
No guessing through logs. The agent asks — the system answers.
The first right raiOS grants is read access: permission to describe itself. Every state, device, and problem is a structured answer — not prose, not a PDF. That knowledge makes agents fast and their mistakes rare.
Question and answer — both as data
system.snapshot, device.graph, problem.list: the agent receives facts instead of guesses. When it tries to write, the system also answers structurally — with a no.
The trust system
Nothing runs because someone claims it should. Only because it is proven.
An agent may build and propose, but a program is accepted only when the evidence chain is complete: what does it claim, which rights does it request, which exact artifact was tested, were all tests green, and did you approve it? Only then can local policy compute a grant. Claims alone open no door here.
The evidence chain closes
Four pieces dock: the manifest, the exact artifact hash, the green test report, and your approval. Only when the ring closes is a grant issued; if one piece disappears, everything locks again.
The approval ladder
Seven risk classes, one rule: only reading is allowed from the start. Everything else remains locked until the full evidence chain exists — and even then only individually, narrowly, and revocably.
The agent factory
Agents build raiOS around the clock.
The factory is not shipped with the system; it is the construction site. Ten parallel agent lanes and one orchestrator build raiOS. Agents receive hardware knowledge as data instead of PDFs and compiler failures as structured responses. A human sets goals and grants rights.
Ten lanes, one rhythm
Drivers, predicates, and pipelines are built in parallel. Only the sensitive kernel is limited to two simultaneous lanes. On the right is the engine: the compiler answers with data, not prose — write, compile, read the failure, fix it.
The overnight loop — target design
The planned flow should detect a stalled test device, cycle power,
and preserve crash context. Three boxes remain open today: watchdog,
smart plug, and ramoops. This diagram is a target, not proof.
Your builder
Anyone may build here. Nothing else can break.
Agent and builder ship as the system's first pair of programs. Everything else grows from them: the agent retrieves knowledge from the internet through an explicit network capability, writes code into the builder, and the Rust compiler translates it onboard. Builder domains cannot receive security-critical rights; policy forbids it.
From experiment to real program
Build, crash, try again: inside the builder, a crash is only one log line and an offer to restart. A program becomes real only by passing the trust pipeline with green evidence. Without it, the gate stays closed — even for agents.
The breakthrough
In the end, the factory moves in.
Every other operating system receives software from outside: app stores, developer workstations, or the cloud. raiOS moves the factory into the system one piece at a time — compiler, tests, and promotion onboard. The goal is request, build, proof, and installation on your device. Every finished tool makes the next one easier.
Today, the QEMU path is proven daily. Surface Pro 4 boots
experimentally; graphics and USB run on real hardware. The WLAN chip
is DETECTED, while association and DHCP on Surface remain open.
An honest ledger
Truly new. Proven ideas, rebuilt. Deliberately omitted.
Not everything in raiOS is an invention, and nothing is missing by accident. This is the honest division:
Does not exist like this yet
Agents + evidence as the blueprint
Ten agent lanes build the system, but predicates decide what counts. A checkmark matters only when a test proves it.
You are the root of trust
A human sets goals and grants rights. Every grant is a recorded object that can be revoked at any time.
A builder for everyone
Compiler onboard, safe experimentation, promotion only through the trust pipeline: an OS that builds its own software.
Known ideas, rebuilt in Rust
Capability security
Known from research systems such as seL4 and Fuchsia: rights are objects granted individually, not forgotten checkboxes.
Drivers in the kernel bedrock
Hardware paths deliberately remain native and kernel-resident. Today's isolation protects replaceable Wasm services with explicit import grants, not the drivers.
WebAssembly as a cage
The browser idea inverted: the Rust compiler itself runs as Wasm inside a constrained onboard interpreter.
RECLOG + evidence reports
Hash-linked RECLOG structures and host reports provide verifiable evidence today. A permanent, append-only device journal is the goal, not yet proven for every record.
Replaceable foundation
The foundation is documented narrowly enough that seL4 could one day sit underneath without breaking anything above.
Deliberately not
No POSIX, no Linux
raiOS is not Unix. Legacy software does not run here; that is the cost of starting over.
No multi-user desktop
One machine, one owner, many domains.
No legacy hardware matrix
One reference device plus QEMU. Not every graphics card in the world — one, done properly.
No mathematical proof
Instead: predicates, negative tests, and rollback from day one — the documented tradeoff.