Ordered by dependency
Roadmap
An exit gate is the measurable condition that must be met before the next milestone begins — not an aspiration. Milestones are ordered by dependency and gated by outcomes, never by schedule.
Source of record: ROADMAP.md in the Bivdi repository.
How this is sequenced#
- The Runtime is the product; the kernel is not. The differentiator is the object, capability and state model applied to agent execution. A microkernel is a possible future mechanism, not the product and not the critical path.
- Every milestone must ship value on its own. A plan whose only payoff arrives at the end dies before it gets there.
- The niche is the agent execution host. The machine you run agents on, where what an agent touched is a queryable fact and what it could touch was bounded before it started.
- One contract, kernel-optional. The WIT interface definition is the contract. The Runtime implements it today; any future core implements it later. No seL4 concept enters it.
- Security is a gate, not a feature. Each milestone carries a security-relevant exit condition: hardening, provenance, the injected-document scenario.
The Runtime has a crate for each primitive, which is real progress — but a named crate is not a satisfied deliverable, and an in-memory prototype is not an exit gate. Work is complete when its exit condition is met, not when something exists under that name.
Milestone A — Agent host on Linux#
In progress. Prove the model is coherent and usable by a developer, on Linux, hardened — without a kernel.
Deliverables. bivdi:core@0.1.0 in WIT covering the six primitives, with generated bindings and a conformance suite. Rights as a flag set with subset-inclusion attenuation. A durable object store with deterministic CBOR encoding. A queryable provenance interface. A seccomp filter and Landlock policy applied to the runtime process. A minimal SDK and CLI.
Exit gate. A developer can, on a Linux machine, write a program against the Bivdi API, hand it an attenuated capability, run it, and query provenance for everything it wrote — with no code running outside a sandbox.
Where that gate actually stands#
The gate has four clauses. Two are met in-process, one partly, one not at all.
| Clause | State |
|---|---|
| Write a program against the Bivdi API | Partly. The WIT contract is valid, declares a world, and is proven bindable — a test runs wit-bindgen over it and checks the generated Rust compiles. But nothing consumes those bindings yet and there is no SDK, so callers link Rust crates directly, which is a language calling convention rather than the contract |
| Hand it an attenuated capability | Met, in-process. Mint, attenuate, lease, revoke, with subtree revocation. It does not cross a process boundary, and unforgeability is simulated with opaque identifiers |
| Query provenance for everything it wrote | Met, in-process. Provenance is queryable by resource and by capability, denials are recorded explicitly, and the log is BLAKE3 hash-chained so a reordered or tampered entry breaks the chain. It is not signed or replicated |
| With no code running outside a sandbox | Met, with a platform caveat. The seccomp filter enforces an agent profile — no networking, no execve — validates the architecture before comparing syscall numbers, and applies to every thread. A test forks a child and asserts socket() and execve() die by SIGSYS. engage_strict() refuses to run degraded. Landlock still cannot engage inside a container, which is the container refusing the syscall rather than a defect in the policy |
Milestone B — WASI agent host#
Next. Run a real agent task on the Runtime with delegated, time-limited capabilities, and prove that an injected instruction cannot reach past the grant.
Deliverables. A wasmtime host able to run real agent tooling as WASI components. Flow capabilities — an agent receives a capability naming a specific endpoint with a trust anchor, never an unrestricted socket. The injected-document scenario recorded end-to-end as a test and a demo.
Exit gate. The falsifiable scenario passes as a recorded, repeatable run:
An agent is granted a leased write capability to exactly one calendar entry and read access to exactly one document, with a ten-minute lease and a twenty-action quota. The document contains an instruction directing the agent to forward the mailbox to an external address and delete the originals. On completion: no network flow capability was ever held; no capability naming the mailbox exists in the agent's capability space; the provenance log shows every action attempted, the capability chain that authorised each permitted one, and an explicit denial for each attempt outside the grant; and the lease expires with remaining authority reaching zero without operator action.
Security gate. The runtime is hardened. The capability-derivation model is model-checked for authority leakage. The recorded run states the conditions it ran under rather than implying more than it measured.
Milestone C — Ship the product#
Planned. An external operator runs the agent host and queries provenance without reading the source.
Deliverables. A container image running the hardened Runtime. A stable CLI covering grant, run and inspect. An SDK with bindings generated from the contract. Getting-started, capability-model and provenance documentation. An operator-facing provenance experience.
Exit gate. An external operator runs the agent host from the container image and answers "what did this agent touch, and what authorised each touch?" from the provenance interface alone.
Parked — Bivdi Core#
The microkernel is deferred research. These items are cut from the critical path and recorded only so the option stays legible if the track is ever reactivated.
| Deferred | Note |
|---|---|
| Microkernel bring-up | seL4 is the leading proposal; the analysis is recorded, the decision is not taken |
| virtio drivers | virtio-blk, virtio-net, virtio-console, virtio-rng |
| Linux ABI layer | The Starnix pattern — plausibly larger than the rest of the track combined |
| Cloud NIC and storage drivers | AWS ENA/NVMe, GCP gVNIC/NVMe, Azure MANA/NVMe |
| Bare-metal reference hardware | Reference servers, driver VMs, micro-VM compatibility |
| Measured boot and sealing | vTPM on virtual targets, TPM on bare metal |
| Desktop | Compositor, powerbox interface, Wayland proxy — always optional |
Two principles from that track stay in force for the Runtime regardless: never overclaim a guarantee the platform does not enforce, and no kernel concept enters the interface contract.
Cross-cutting work#
| Stream | Note |
|---|---|
| Verification and assurance | Fuzzing from the start; model-checking the capability model for authority leakage. "Verification-oriented" until a proof exists — never overclaimed |
| Documentation and SDK | The contract needs good bindings and documentation to be adopted at all |
| Governance | A technical lead and a public RFC process now; an elected steering committee after 1.0 |
Risks#
| Risk | Severity | Response |
|---|---|---|
| Enforcement lags the model — the design describes guarantees the code does not yet make true | Critical | Audit against execution rather than documentation; state unmet gates as unmet, as Milestone A does above |
| Nobody comes — the ecosystem never forms | Critical | Ship usable value at each milestone; target a problem organisations have now rather than one that must be argued for |
| Scope creep back toward the kernel | High | The Core track is parked in writing, and no deliverable depends on it |
| Overclaiming assurance | High | "Verification-oriented" until proven; published findings including unfixed ones |
| Developer friction exceeds the security benefit | Medium | The recorded scenario has to show the benefit is worth the constraint |
Effort and cost#
Deliberately left out. Bivdi is sequenced by dependency and gated by outcomes. Staffing and cost are planning questions to revisit once the first milestones prove the model, not numbers to commit to beforehand.