From Hosted Runtime to Native Operating System
Astrid’s native-OS direction asks whether its authority model can survive below a conventional Unix daemon. The important comparison is not between two product names, but between two enforcement locations: today’s hosted semantic kernel and a proposed ring-zero capability microkernel. This chapter explains what would move into the native kernel, what must remain in ring-three runtime domains and capsules, and how Astrid’s evidence gates limit what the project can honestly claim.
Two kernels, one boundary principle
Today, astrid-kernel is a semantic supervisor inside a host process. It owns or connects the event bus, capsule registry, capability store, durable state, audit, VFS, and local transport. It loads capsules and routes their events, but it deliberately excludes cognitive loops, LLM calls, and product-specific tool implementations. The current runtime can therefore provide a useful agent substrate without owning the machine’s privileged CPU state.
The proposed astrid-native-kernel is a different object. An actual kernel, in Astrid’s definition, directly owns the privileged mechanisms needed to enforce boundaries between mutually distrusting domains: page tables, protection domains, scheduling, inter-domain IPC, hardware handles, interrupt and timer mediation, IOMMU and DMA controls, revocation, reset, and watchdog recovery. It would not be a larger version of the semantic supervisor. Its success would be measured by whether an untrusted domain can be contained and recovered, not by how many application features ring zero can host.
This distinction preserves the project’s original idea while changing its depth. The hosted daemon currently uses operating-system facilities such as Unix sockets, Tokio, host files, native subprocesses, and Wasmtime. A native deployment would replace some of those host assumptions with an Astrid-owned machine boundary. It should not move product policy down into that boundary merely because the kernel now controls more hardware.
The proposed kernel is therefore intentionally smaller in vocabulary than the software above it. It knows that a domain owns a page range, an endpoint, a scheduling budget, a device handle, or a DMA region. It does not know what a website, agent loop, USB class, filesystem, model provider, or tool schema means. Those concepts remain in runtime hosts, system services, and capsules connected over typed interfaces.
What belongs in ring zero—and what does not
The native design begins with a positive obligation set. Ring zero must initialize the machine, establish memory protection, create and schedule domains, carry bounded typed messages, mediate interrupts and devices, enforce resource budgets, revoke authority, and support reset and recovery. It must make these mechanisms fail closed under malformed input, exhaustion, and domain failure.
The exclusions are equally important. The charter keeps POSIX processes, global paths and file descriptors, filesystems and databases, TCP/IP and HTTP, Wasmtime execution, inference, dynamic kernel code, unbounded allocation, and manifest self-declarations out of ring zero. This is not an aesthetic preference for minimalism. Each exclusion prevents a class of application policy or parser surface from becoming part of the most trusted code on the machine.