Research program

ABSD is an experimental operating system used to investigate one systems question with a working kernel, a userspace, and real programs rather than in the abstract. This page describes the program for researchers and prospective collaborators. Its statements carry the same labels as the rest of the site; where it describes intent rather than results, it says so.

The question

Mainstream Unix-like systems enforce authority, failure, and durability rules defensively in userspace, on top of a substrate that grants ambient authority and reports success loosely. Capability systems such as KeyKOS, EROS, seL4, and Zircon made authority native, and crash-consistency work such as ALICE, CrashMonkey, and FSCQ made storage guarantees testable. ABSD asks what an operating system looks like when all of these rules are native together: when a process holds exactly the authority it was handed, when an update succeeds only from the state it was based on, and when "done" is stated at the strength the evidence supports. The organizing invariant is that no transition may claim more certainty, authority, effect, or durability than its inputs establish.

The hypothesis is not that this is free. It is that the costs are specific and measurable (few are measured yet; multicore throughput was found bounded by kernel serialization), and that a small system built this way can still run ordinary software. ABSD exists to find out where that holds and where it does not.

What exists today

• RELEASE-QUALIFIED An x86-64 kernel and a Rust userspace that boot under QEMU (TCG or KVM), serve stock OpenSSH logins, keep files across reboots, run a shell with pipes and redirection, and shut down in order. An installed image can be updated from the previous release, staged from a host while halted, and rolled back. See release absd-20261003.1.
• MILESTONE-QUALIFIED Processes start only by spawn, with an explicit list of handles; there is no fork. Authority is the set of handles a process holds, as in capability systems; a handle's rights can be dropped, never added. There are no user IDs and no ambient privilege. See design.
• MILESTONE-QUALIFIED A kernel-native compare-and-swap on versioned cells: a cell changes only from the version the caller names, so an update based on stale state is refused rather than lost.
• MILESTONE-QUALIFIED Ordinary Rust programs built for ABSD without source changes, and unmodified crates.io programs (of 19 tried, 10 build and 9 run; 19 of 25 cases match their Linux builds byte for byte). See compatibility.
• VALIDATED Research builds with several CPUs under KVM, a 64-bit ARM port of the kernel in virtual machines, and a boot-time probe that enumerates one USB device on an emulated controller. None is part of a release, and none has run on physical hardware. See status.

On the main branches (2026-10-07) the kernel is about 46,000 lines of Rust and the platform (runtime, file server, SSH server, commands) about 32,000, counting tests and comments but not vendored code. One developer directs the work; AI coding agents did most of the implementation and the review described below.

Method: bounded acceptance

The method is part of the research. A result is accepted only in a named form:

• A named environment. Every claim states where it was observed: emulator, machine type, firmware, device models, CPU count. Hardware support is tiered and never inferred from emulation (tiers).
• A recorded run. Counts come from the check scripts' own output, against exact kernel and platform commits. A release is an exact pair with a manifest and digests.
• Negative controls. A check is trusted only if it can fail. Deliberately broken kernels (mutants) must be caught by the probe that claims to cover them; the SSH server's entropy check has its own negative control; the read-only physical image is run with write-requesting options and the test disks are compared byte for byte afterwards; documented absences are checked to be absent.
• Stated failure models. "Durable" always names its model. Two are qualified under QEMU: an abrupt stop, and a modeled power-loss law in which anything not covered by a completed flush may be lost or reordered. Neither is a claim about real power loss.
• Separate acceptance. Releases and integrations are accepted on a review separate from the run that produced them. That review is done by separate AI model sessions, not by an outside human. Acceptance shows that the recorded checks passed and were re-examined, not that the design or code has been audited by a person.
• Failures are kept. A failed run is not rewritten into a pass. The release record keeps its earlier failures; multicore throughput scaling was measured and recorded as not earned; strict real-time timing with a shared physical core failed and is recorded as failed.

This makes progress slower to state and easier to check. The evidence page shows the record kept for each milestone and release.

Selected milestones

Questions under investigation

Authority at the time of an effect

A check made before an action can be stale by the time the action happens. Versioned cells and per-operation rights checks address this for state the kernel owns MILESTONE-QUALIFIED. Whether the same discipline can carry authority whose grounds expire, and how spent authority is kept from becoming unspent after a crash or a lost reply, is open PLANNED.

Durability as a stated contract

The filesystem's guarantees are qualified under two modeled failure laws MILESTONE-QUALIFIED. A native storage engine, admitted by the semantics its consumers need rather than by feature list, is current work and not claimed EXPERIMENTAL-INTEGRATION. Real power loss on real drives is not yet tested UNSUPPORTED.

Several CPUs without weakening the invariants

Multicore scheduling is validated as research, with each process on one CPU at a time and a measured serialization boundary VALIDATED. The open question is how far parallelism can go before lifetime and authority rules need new mechanisms, and which of those mechanisms earn their cost. A successor study of object lifetime across CPUs is current work EXPERIMENTAL-INTEGRATION.

Semantics across architectures

The ARM port runs a fixed workload whose results are compared with the x86-64 build VALIDATED. The question is whether the kernel's guarantees are properties of the design or of one architecture's memory model.

Several principals without accounts

Today one operator identity holds a fixed authority ceiling. How independently authenticated principals can hold different authority without importing user IDs and permission bits is an open design problem PLANNED.

Compatibility above native semantics

How much ordinary software runs above a native interface that differs from Unix, and where it stops, is measured for Rust programs MILESTONE-QUALIFIED. A foreign-binary personality is a deferred experiment, with a stop rule if it begins to pull the native design toward the foreign one PLANNED.

Operating the system, not just running it

Configuration, time, networking status, and failure records as explicit contracts with desired and observed state, rather than as files read once at boot PLANNED. The north star is a system that runs unattended for months within declared limits; that is a direction, not a claim.

Near-term program

• PLANNED A developer preview: a public source tree, assembled from pinned component revisions, that someone else can clone, build, boot under a documented QEMU/KVM configuration, and log into. It is accepted only after an independent clean-environment build and boot from the published instructions. It does not exist yet, has no date, and its license is undecided.
• PLANNED Exact-hardware qualification of one physical machine, starting read-only: several CPUs, reset, and automatic result collection before any disk write.
• PLANNED Operating contracts for essential services, configuration generations, time, and administered networking.

What dedicated resources would change

The constraint is evidence, not ideas. Specific resources would turn current limits into testable claims:

• Physical test machines with serial console capture and remote power and reset control. Today's physical results are read from photographs. Collected, attributable receipts are the precondition for exact-hardware qualification.
• Sacrificial drives and a controlled power-cut rig. Real power loss is the largest gap between the modeled durability results and a claim about hardware.
• Dedicated qualification hosts with isolated cores. Multicore and real-time timing results need cores that nothing else shares; strict timing failed with a shared physical core, and isolated-core timing is not yet established.
• Human reviewers. In particular for storage semantics, memory ordering, and small invariants that are worth modelling formally. Review so far is by AI models; human reviewers would test what that review misses.
• Time for release engineering. Making the developer preview reproducible by strangers is work the research does not need, but other researchers do.

What this is not

• Not a replacement for Linux or a BSD, and not production-ready. See what it is not for.
• Not a verified system: no formal proof of the kernel or platform is claimed. Claims rest on recorded runs and review, under named environments and failure models.
• Not hardware-supported. Physical hardware qualification: not yet established.
• Not an AI operating system, and not a product or a company.
• Not publicly available. The source is developed privately and nothing can be downloaded; a public source distribution is intended, without a date.
• Not independently reviewed. The implementation and its review are largely the work of AI coding agents directed by one developer; no outside human has audited either. See how it is developed.

Adjacent work

Constellation, a separate project by the same author, is an experimental set of programs that keeps a worker's report that something is done apart from independent evidence that it is true now. It shares some of ABSD's ideas: refusal over guessing, and claims no stronger than their evidence. ABSD runs some of its programs as native workloads because they were not written for ABSD; nothing in ABSD depends on them, and ABSD's semantics are not defined in their terms. See research.