Five planes. One pipeline. Zero cross-imports.

Vigil's codebase is eleven crates. The crates are organized into five planes. Between the planes there is a strict no-cross-imports rule, enforced by the build system. A crate in one plane cannot reach into another plane's internals. All inter-plane traffic crosses the event bus in vigil-core. This is not a stylistic preference. It is the property that makes the security-critical paths reviewable, and it is the property that makes the architecture survive contact with a determined enterprise security review.

This post walks through the planes, the rule, the enforcement, and what each property buys you.

The architecture is the audit boundary. Code that respects the boundary can be verified by a stranger in a weekend. Code that does not respect the boundary cannot be verified at all without owning the codebase.

The five planes

Each plane has a single responsibility, a small public interface, and explicit constraints on what it depends on. The planes are listed in pipeline order.

Identity. Holds the agent attestation chain, the principal authorization state, and the revocation record. TAP attestation lives here. VARP revocation lives here. The plane has no knowledge of what is being intercepted or how it is analyzed. It only knows who is allowed to act for whom, and how to revoke that authority across surfaces.

Intercept. The TLS proxy and the Chrome extension. Two entry points, one internal API. The plane captures incoming traffic, normalizes it into a structured representation, and emits the representation onto the event bus. The plane has no knowledge of the policy rules, the detection models, or the audit chain. It captures and emits.

Analysis. The four-model detection ensemble plus the action decomposition layer. Statistical only. No enforcement primitives. The plane consumes structured traffic from the event bus, runs detection inference, decomposes responses into structured actions, and emits scored signals plus action representations back onto the bus. The plane does not make policy decisions.

Policy. The deterministic rule engine and the Execution Gate. Decisions live here. No LLMs, no statistical models, no probabilistic anything. The plane reads scored signals from Analysis, evaluates structured actions against the rule set and the user's authorized capabilities, and emits enforcement decisions onto the bus.

Vault. The cryptographic audit chain and the local archive. VOAF chain construction lives here. The plane writes; nothing else writes to the chain. Every action that reaches Policy produces a Vault entry, signed by the user's local key, hash-linked to the previous entry.

This is the entire data flow. Five planes, one pipeline, ordered by the responsibilities each plane owns.

The eleven crates

The crates are mostly named after the plane they belong to. Some planes have multiple crates because the responsibilities are large enough to warrant separation within the plane.

vigil-core is the event bus and shared types. It is the only crate every other crate imports. It contains no business logic, only the type definitions and the bus implementation. If vigil-core were compromised, the rest of the system would have no place to communicate. We treat it as the most security-critical crate and review changes to it with the highest scrutiny.

vigil-authority is the Identity plane. It holds the TAP and VARP implementations, the attestation chain logic, and the revocation propagation.

vigil-proxy is the Intercept plane's TLS proxy. The Chrome extension is a separate JavaScript bundle that communicates with vigil-proxy over a local socket; the bundle is built outside the Rust monorepo but ships with the same release.

vigil-decompose is the action decomposition layer in the Analysis plane. It parses agent responses into structured actions.

vigil-detect is the detection ensemble in the Analysis plane. The four models live here.

vigil-pipeline is the orchestration crate that connects the planes through vigil-core. It is the only crate that knows the order of operations across the pipeline; it does not contain any plane-specific logic itself.

vigil-policy is the Policy plane. The Execution Gate, the rule engine, and the deterministic decision function live here.

vigil-store is the Vault plane's persistent storage. The VOAF chain is written through this crate.

vigil-verify is the open-source auditor. It reads a Vault chain and verifies it. This is the crate we have made available outside the proprietary repo, because audit you cannot independently verify is not audit.

vigil-cloud is the optional remote infrastructure for enterprise deployment. It does not appear in consumer installs.

vigil-tauri is the desktop application shell. It builds the menu bar app, the dashboard view, and the system integration on macOS.

These eleven are the entire codebase. Total Rust line count is in five-figure territory; the system is small on purpose.

The no-cross-imports rule

The rule is simple to state. A crate may only import:

1. vigil-core (the bus and shared types).
2. Crates within the same plane.
3. The standard library and approved third-party dependencies.

A crate may not import another plane's crate directly. If vigil-policy needs information from vigil-detect, it does not call into vigil-detect. It consumes the signal that vigil-detect emitted onto the bus through vigil-core. The communication is one-directional, asynchronous, and explicit.

The rule is enforced by the build system. We have a workspace-level lint that fails the build if any crate imports a crate outside its plane. The lint runs in CI on every PR. We cannot ship a build that violates the rule by accident.

The rule has costs. Some operations are awkward when you cannot reach into another plane's data structures. Some refactors are harder because you cannot share an internal type across planes. The costs are real. We pay them on purpose, because the property the rule produces is more valuable than the convenience the rule denies.

What the property buys

Three things, in order of importance.

One: the security-critical paths are auditable in isolation. A reviewer can read vigil-policy end-to-end without reading any other crate. The plane takes structured inputs from the bus and produces structured decisions. The decision logic is deterministic. The reviewer can confirm that no path in vigil-policy calls into a statistical model, into the network, or into anything that could be influenced by an attacker-controlled prompt. The confirmation is a property of the plane's import graph, not a property of careful inspection of every line.

This is the difference between architecture as a security property and architecture as a guideline. Guidelines fail under pressure. Architecture, enforced by the build system, does not.

Two: changes are localized. When we add a feature to the detection ensemble, the change is in vigil-detect. The change cannot accidentally affect vigil-policy, because vigil-policy does not import vigil-detect. The blast radius of any change is bounded by the plane it lives in.

This is what enables us to ship at the pace we ship. The codebase is small enough to understand in full, and changes do not produce surprises in unrelated planes. A bug in the LSTM does not silently change enforcement behavior. A bug in the policy engine does not silently change detection.

Three: the architecture survives a determined attacker. An attacker who compromises one plane has compromised that plane. They have not compromised the others, because the planes do not share state outside the bus, and the bus carries structured messages with explicit shapes. An attacker who shifts the LSTM's output can shift the tier signal that vigil-policy reads. They cannot shift the policy engine's decision function, because the function does not import the LSTM.

The threat model is bounded by the architecture. We have written the boundaries explicitly so that the bound is provable, not just claimed.

What this is not

The architecture is not novel in computer science terms. It is a clean implementation of a layered architecture with a message bus, which has been the dominant pattern for distributed systems for thirty years.

The architecture is not exotic in Rust terms. The cargo workspace mechanism makes multi-crate enforcement straightforward. The lint we use to enforce the no-cross-imports rule is fifty lines of code.

The architecture is not unique to Vigil. Any defense product can be built this way. Most are not, because the discipline of refusing the cross-imports during early development requires rejecting easy code paths in favor of the right ones, and the easy code paths are seductive when the product is small and the team is in a hurry.

The decision to enforce the architecture from the first commit is what produces the property. Retrofitting it is much harder than starting with it. We started with it. We are glad we did.

What you can do with this

If you are evaluating Vigil for a security review, the architecture is the first thing to ask about. Confirm that the planes are real, that the no-cross-imports rule is enforced, and that the decision-making in the Policy plane does not import statistical or LLM-based components. The answers to these three questions determine whether the architectural claims this blog makes are real or marketing.

If you are building a defense product, this is the pattern that survives. Five planes, message bus, no cross-imports, build-time enforcement. The specifics of which planes you need depend on your product. The discipline of separating them does not.

If you are an open-source contributor and you want to look at the smaller, isolatable crates, vigil-verify is open-source and is a self-contained example of how the architecture works in miniature. It reads the chain, verifies it, and produces a result. It does not depend on any other plane's internals. You can rebuild it from source in under a minute and test it against any VOAF chain.

The architecture is the bar. The codebase is small. The boundaries are explicit. We did this on purpose.