Devlog 01: why we are building a governance kernel, and why in Rust

This devlog documents R&D in progress. Details will change as the work does; entries are corrected rather than rewritten.

Where this comes from

The VS Code plugin taught us the lesson the hard way: governance that lives in prompts and configuration files is governance an agent can route around. The plugin’s own rebuild happened because its AI builder bypassed its rules, and the fix was structural enforcement, gates that reject rather than guidelines that request.

Structural enforcement inside an editor extension still has a ceiling. The extension can only see what the editor lets it see, it dies when the session does, and every editor and agent runtime needs its own bridge. The enforcement layer wants to live lower.

What the kernel is

The governance kernel is that lower layer: a small, standalone component that owns policy evaluation and evidence recording for agent-assisted delivery, independent of any particular editor or agent.

Three design commitments, held from the start:

1. Policy as a compiled artefact. Rules are evaluated by the kernel, not interpreted from prose by the very model they constrain. If a gate says a spec cannot advance without review evidence, that is a return value, not a suggestion.
2. Enforcement below the tools. Editors, CLIs and agent harnesses talk to the kernel through one interface; no single integration can relax what the kernel refuses.
3. An audit trail built for evidence. Append-only, hash-chained, designed for the question “show me what changed and why” rather than for decoration.

Why Rust

The honest answer is fitness, not fashion. The kernel sits in every delivery loop, so it must start fast and stay small; it handles evidence that must not be corrupted, so memory safety without a garbage collector matters; and it needs to embed everywhere the work happens, a static binary with C-compatible bindings reaches editors, CI runners and harnesses alike. Rust is the boring, defensible choice for exactly this shape of component.

Where the work is now

Early. The current focus is the policy evaluation core and the shape of the evidence log; the plugin remains the production governance surface while the kernel earns its place underneath it. How we test all of this, including the test-bench setup, is documented in the research section.

Next entry: the policy model, and what “a control that changes behaviour” means when the control is code.