Crate Map

Platform documentation is a ladder: Kernel, Node, Cluster, Swarm, Federation & Compliance, Formal Assurance. Every page files at exactly one rung. This page answers the question an author hits first: the code lives in crates/<group>/<crate>, so which rung documents it?

Two things carry no rung information. The URL prefix carries none: /docs/guard-platform/ pages sit under a section named Kernel, and one prefix can hold pages that file at different rungs. The source directory carries none either, which is what the trap table below is for. File by the filing test, not by the path.

The six rungs

Each rung has one subject and one test. When two tests fire, the subject files at the lowest rung where it is fully determined.

The Rung column in the tables below uses these six names. Federation is the short form of the section name, Federation & Compliance. Rows that name an area instead (Learn, Economy, Build, Reference, Products) are off the ladder: that area owns the crate, and Platform does not document it.

Where the directory lies

Placements a reader would get wrong from the path alone. Check this table before filing anything under these directories.

The workspace, directory by directory

The workspace manifest lists 163 members. The tables below iterate that list, so the rows are the workspace’s own membership rather than a copy of it; 142 of them sit under crates/ and are grouped here by the directory they live in. The rest are below, under Members outside crates/. 136 members carry an ARCHITECTURE.md beside their manifest, which is the first thing to read when a one-line purpose is not enough.

crates/core

crates/kernel

crates/guards

crates/sdk

crates/observability

Every crate here files at Node. Emission semantics are documented at Node by design, including the tracing macros, the guard join key, and the guard metric names.

crates/platform

crates/protocol

crates/trust

crates/economy

crates/tooling

crates/products

Members outside crates/

21 workspace members live outside crates/. None of them files on the ladder, and no manifest under crates/ names any of them as a dependency: they are the examples a reader runs, the harnesses that gate a release, the benches that measure one, and the distribution packages for the places Chio is listed. They are here because a member the map omits is a member a reader concludes does not exist.

Two of them are worth knowing by name even if you never build them. chio-formal-diff-tests and chio-replay-gate file at Formal Assurance rather than Build, because their subject is a verification gate over the kernel rather than a convenience for someone building on it.

Kernel variants

Four crates provide kernel implementations for environments with different runtime capabilities. All four file at Kernel.

The Kernel-to-Node boundary

The boundary is not a judgement call. The portable core states what it will not do, and that list is the Kernel-to-Node seam verbatim. crates/kernel/chio-kernel-core/src/evaluate.rs fences these into the full kernel:

//! What it does NOT do (fenced into `chio-kernel` proper):
//!
//! - Revocation membership lookup (stateful `RevocationStore`).
//! - Budget mutation (stateful `BudgetStore`).
//! - Delegation-chain ancestor inspection against the receipt store.
//! - DPoP proof verification with nonce replay (LRU-backed).
//! - Governed-transaction policy evaluation (pulls in chio-governance).
//! - Payment authorisation (async adapter trait).
//! - Tool dispatch to wrapped servers (async transport).
//! - Receipt persistence / Merkle checkpointing (SQL / IO).

Any crate that implements one of those lines is Node content, wherever it sits in the tree. That is why chio-store-sqlite, chio-http-session, and chio-tool-call-fabric file at Node while the traits they satisfy file at Kernel. The same module header also names the verified-core boundary: revocation lookups, budget mutation, DPoP, and tool dispatch sit outside the present proof claim, which is what Formal Assurance documents as assumptions.

chio-federation, module by module

One crate, two rungs. The split is by module, and it is the seam where a reasonable reader is most likely to predict the wrong section.

The rule underneath: a per-action signature files at Swarm, a standing relationship between authorities files at Federation. The remaining modules take the same test. activation, artifacts, qualification, reputation, and revocation_gossip file by whether their subject is one action or a standing relationship; error, metrics, and validation are crate plumbing and carry no rung of their own.

Trust boundaries

spec/security/chio-threat-model.v1.json states the boundary this workspace is organized around in one line: its focus is the agent-kernel-tool trust boundary, over the surfaces native_chio, hosted_mcp, trust_control, and kernel_to_tool. Three readings of that line hold across every crate above.

• The kernel is trusted. Guards run inside the kernel process and the kernel signs receipts, so an adversarial agent cannot change a verdict or a receipt without breaking a signature. Native guards are ordinary Rust in that process. An operator-authored WASM guard is untrusted code running in the same process under wasmtime, and what confines it is an audited assumption rather than a proof: ASSUME-WASM-ENGINE assumes wasmtime enforces its documented return, trap, fuel-metering, memory-limiter, and in-process sandbox semantics for untrusted guest code.
• The agent is untrusted. Every input the agent provides is treated as adversarial. The capability token authorizes a scope, not a specific request shape, and scope match runs before guards do.
• The tool server is confined, not cooperating. The threat model lists tool_execution_confinement among the assets it protects, and ASSUME-SUBPROCESS-ISOLATION assumes tool-server subprocess isolation and OS process boundaries for effects outside the pure decision core. A tool server is bound to a signed manifest and expected to implement what it advertises; it is not trusted to enforce policy, and it is not modeled as a well-behaved party. Policy enforcement is the kernel’s job, and what happens past the process boundary is an assumption the deployment carries, not a guarantee the kernel makes.

Reading the source

The paths that come up most often when tracing a behavior back to code.

crates/kernel/chio-kernel-core/src/lib.rs          # Verdict enum
crates/kernel/chio-kernel-core/src/guard.rs        # portable Guard trait, GuardContext
crates/kernel/chio-kernel-core/src/evaluate.rs     # core evaluate() + the exclusion list
crates/kernel/chio-kernel/src/runtime.rs           # ToolCallRequest, Verdict
crates/kernel/chio-kernel/src/kernel/mod.rs        # KernelError, full-kernel Guard + GuardDecision
crates/kernel/chio-runtime-core/src/admission.rs   # runtime admission evaluation
crates/kernel/chio-swarm-authority/src/verifier.rs # swarm receipts, tokens, budget pools
crates/guards/chio-guards/src/pipeline.rs          # GuardPipeline + default_pipeline
crates/guards/chio-guards/src/advisory.rs          # AdvisoryPipeline + PromotionPolicy
crates/guards/chio-guards/src/post_invocation.rs   # SanitizerHook
crates/guards/chio-guards/src/external/mod.rs      # AsyncGuardAdapter, ExternalGuard
crates/guards/chio-policy/src/compiler.rs          # HushSpec-to-pipeline compiler
crates/trust/chio-federation/src/frost/            # threshold roster, rotation, verification
crates/platform/chio-store-sqlite/src/lib.rs       # the node's persistence layer

Where to go next

• Overview · what the Kernel section covers, and in what order
• The Guard Trait · the contract every guard implements
• Capabilities · the token the kernel verifies before anything else runs
• Testing Guards & Policies · the authoring-side gates named above