RamenOS
In ProgressA Rust OS lab for agent-native computing: typed capabilities, semantic state, and evidence-backed hardware claims.
Status
Public pre-alpha
A working OS lab, not a release-ready operating system.
Works Today
QEMU + typed gates
Boot smoke paths, IPC checks, IDL/codegen checks, Store gates, and Driver Foundry loops.
Current Frontier
HIL appliance loop
Live serial capture with bounded power and reset actuation before broader hardware claims.
Boundary
Evidence first
No production, security, release, or broad metal claims until the matching proof exists.
RamenOS is a Rust OS research lab for agent-native computing.
It tests a focused idea: agents should interact with an operating system through typed contracts, explicit capabilities, and machine-readable state instead of inferring everything from shells, logs, and human-facing surfaces.
The project is public pre-alpha. The point of publishing it now is not to present a finished OS; it is to make the evidence path, contract surfaces, and design constraints visible while the work is still taking shape.
Why it exists
Today, an agent often gets a shell, a filesystem, logs, and a vague instruction. It has to infer state from human-facing surfaces and hope it understood the machine correctly.
RamenOS asks a narrower question: what if the OS gave agents typed capabilities, bounded authority, and observable semantic state directly?
That means replacing root-shell guessing with temporary capabilities, explicit authority boundaries, auditable effects, and claims that are tied to reproducible checks.
The three pillars
The architecture is split into three parts that are meant to stay conceptually distinct:
- Core is the kernel, capability system, and the minimal runtime machinery the rest of the system depends on.
- Foundry is the tooling layer for building components, generating typed interfaces, and proving that contract surfaces still line up.
- Store is the persistence and package-management side of the system, with fail-closed gates instead of ambient trust.
That separation matters because the project is not only “a kernel in Rust.” It is also a place to test OS ideas against typed contracts, reproducible gates, and hardware evidence.
Evidence ladder
RamenOS keeps different passing states separate. A QEMU smoke pass is useful, but it is not the same kind of evidence as a live hardware capture.
The ladder:
- QEMU smoke — fast, reproducible simulator evidence.
- Replayed HIL log — known hardware traces checked through the same surfaces.
- Live serial capture — real device observation, with no claim that actuation exists yet.
- Appliance-mediated capture — serial plus bounded power/reset control.
- Metal graduation — hardware claims promoted only after the evidence path supports them.
Run the smoke proof
The public proof path starts small on purpose:
git clone https://github.com/maxwellsantoro/RamenOS.git
cd RamenOS
just foundry-s0That command is the first public gate for visitors who want to see the project do something concrete before reading architecture prose.