Chio/Docs

Component Responsibilities

Find the component that owns the state you need to inspect or change.

Concept chio@5f63e6e

On this page

Every kind of state in a Chio deployment has one owner. The kernel decides, a node hosts, an agent process retains work, a cluster coordinates, a swarm derives authority, and federation joins operators. When an action is refused, lost, or stuck, the fix starts with the owner of the state involved.

The separation keeps an action's authorization apart from the host that executes it, the agent that retains its work, and the operators that cooperate on it. That separation locates a failure before anyone edits policy: a failed persistence path, for example, is a Node question.

Platform mapSelect a part to inspect its role.
your operatorpartner operatorrequestshostsdelegatesreplicatestreatyKkernelnnodepagent processaa1a2swarmKKKclusterK′federation peer§platform reference
partner operatorrequestshostsdelegatesreplicatestreatyKkernelnnodepprocessaa1a2swarmKKKclusterK′federation peer§reference

Kernel

Kernel

Admits each governed operation under the caller's capability and the operator's policy, runs guards inside admission, dispatches through an adapter, and signs a receipt for the decision.

Read more in Kernel overview.

The kernel and the parts that host, run, replicate, and federate it. Every part is drawn once; a deployment runs one or several of each. Guards, adapters, and stores are left out.Platform overview

The kernel owns the decision

The kernel admits or refuses each governed operation under the caller's capability and the operator's policy. It runs guards inside admission, dispatches an admitted call through an adapter, and signs a receipt for every decision, refusals included.

A guard that implements the kernel Guard trait belongs here even when it reads state a node holds. Start with the kernel when the question is why a request was admitted or refused.

Read more in The mediated call and Guards.

A node hosts the decision and carries out its effects

A node is a process that hosts a kernel. It supplies the local state and execution around each decision: receipt storage, budget mutation, revocation lookup, identity verification, tool dispatch, and checkpoint publication.

A node runs in process, as a sidecar beside an HTTP service, as a local MCP bridge, or as a process host. Inspect the node when the decision is understood but persistence, export, or dispatch failed.

Read more in Node.

An agent process keeps identity and work across workers

The process is the durable agent; its worker is the program running it right now. Identity, authority, checkpoints, and named calls survive a worker restart or replacement. A process tree runs under one root grant, and cancel and revoke cascade through it.

A lost reply is recovered by the call's original identity with no second dispatch, and an unknown outcome stays unknown until it is resolved. Go to the process when work must continue after a stop or an external result is unresolved.

Read more in Process Operations and call recovery.

A cluster shares control state across one operator's nodes

A cluster coordinates nodes under one operator's key. They share authority, revocations, receipts, and budget exposure. A leader holds a lease with a fencing token, and replication carries each committed entry to the other nodes.

The cluster's consistency contract decides what one node may observe of another's writes. Restore and divergence questions start here; a local store failure starts at the node.

Read more in Cluster Recovery.

A swarm derives narrower authority from a parent

A swarm carries authority through a signed task graph that bounds delegation depth and fan-out. Each derived grant narrows its parent's, and an action can require joint signatures from several parties.

Delegated agents draw on one shared budget pool, and a restart never replenishes it. Start at the swarm to trace who granted an agent its permission and which parties must authorize a joint action.

Read more in Swarms.

Federation joins operators who hold their own keys

Federation connects operators whose keys are independently controlled. Adding a partner card pins the partner kernel's key, a treaty names the actions the two operators cooperate on, and each kernel admits work at its own door under its own policy.

Peer identity, treaties, admission, and evidence exchange decide what the relationship permits. A federated grant requires proof of possession (DPoP) at the receiving door. Start here to connect a partner, delegate across operators, or read evidence a partner sent.

Read more in Federation.

The receipt names the component to inspect first

One operation crosses the kernel, the node, and the process, so read its evidence before choosing a component. A receipt names the grant and the policy hash behind the decision; in the Quickstart, refusal.describe() prints both for the fixer's refused read of /secrets/.env.

  1. A refusal with a valid receipt starts at the kernel and its inputs: the grant and the policy hash the receipt names.
  2. An admitted request with a missing record starts at the node's persistence path.
  3. A restarted worker with an unresolved external call starts at the process's retained call state.

The navigation groups pages by component. Some URL prefixes span components: Node and Cluster runbooks live under /docs/deployment/, and the crate map lives under /docs/guard-platform/. Follow the page's section in the navigation.

Next: start from a symptom