What defines the system?

Substrate has an explicit wire contract and implemented resource lifecycles. An initial ESS specification now describes the accepted-operation ledger lifecycle; it does not generate the entire service or replace the wire contract. Its definitions live in Rust types, versioned contract sources, route handlers and durable store transitions. Conformance checks connect those definitions; they do not replace them.

This page describes the implementation in release 0.16.1, which advertises the substrate-wire/0.25.0 development contract: the Linux host driver and, as a development profile, a Kubernetes namespace driver behind the same daemon. See status for availability and the route reference for addresses.

Subsystems and ownership

Boundary	Flow
Caller and SDK	Authenticated HTTP or WebSocket requests to the daemon
Daemon and SQLite	Reserve operations, record observations and events
Daemon and host driver	Dispatch work and observe its outcome
Host driver and kernel	Probe capabilities and enforce process confinement
Namespace driver and API server	Probe capabilities; serve workspaces on PersistentVolumeClaims and keeper Pods (development profile)

See the security boundary diagram.

The SDK calls the daemon. The disposable MCP adapter translates tools and resources through that SDK. The daemon coordinates admission and lifecycle work; the host driver proves and applies confinement; SQLite retains the evidence needed after a disconnect or restart.

Source owner	Definition it owns
substrate-wire	Typed requests, resources, observations, events, refusal vocabulary and canonical request hashing
substrate-daemon	Transport authentication, route dispatch, admission and lifecycle coordination
substrate-store	Durable reservations, subject-scoped resources, stored answers, event sequence and recovery views
substrate-host	Linux probes, workspace I/O, process confinement, quotas and measured outcomes
substrate-guarded	Guarded workspace I/O and the exec environment rule, shared by every driver
substrate-kubernetes / substrate-executor	The namespace driver and the executor its Pods run
b10x-substrate-sdk / substrate-mcp	Client handles and recovery; bounded MCP tools, resources and session translation
xtask / substrate-contract-check	Bundle rendering, schema and compatibility checks, and contract conformance checks

These are source responsibilities, not separately deployed services. The implementation is in the public workspace crates.

Model coverage

In this handbook, a caller creates workspace W1, writes input.txt, and starts exec X1 with operation O1. These short labels are illustrative: resource IDs are opaque, and real operation IDs must satisfy the operation ID rules.

Domain	Explicitly represented today	Example or boundary
Machine and capabilities	Driver generation, probed facts, limits and capability snapshot	X1 binds to the inspected snapshot; missing facts cannot authorize a capability
Workspace	Identity, source, state, labels, guarded bytes, optional storage bound and lease	W1 may start empty or from an authorized, configured Git source
Exec	Start input, argv, environment, requested/applied confinement, limits, state, output and usage	X1 hashes W1's input under the requested bounds
Session	Raw-pipe or PTY mode, resource state, lease, bounded attachment and hosted attachment authority	A protocol process uses the same execution boundary
Command and operation	Typed mutation input, caller ID, request hash, reservation state and stored outcome	O1 identifies the start request; it is distinct from X1
Events	Closed transitions, resource identity, generation, sequence, actor, cause and observation	An exec observation can be correlated with its causing operation
Recovery	Operation lookup, retained event cursors and reconciliation snapshots	A caller recovers after losing a response or falling behind event retention
Authority and enforcement	Authenticated subject, delegated admission, grants, source authority, capsules, secret slots and egress apertures	These constrain admission or execution; product identity and policy remain outside

There is one important limit to event coverage: sessions have typed resources, requests and lifecycles, but the public event vocabulary does not have a separate session.* branch. Session transitions publish an operation-ledger projection such as operation.terminal or operation.unknown. Inspect the session resource for its state. This behavior is explicit in the store's event projection and the wire event validator.

Workloads, images, volumes and endpoints are future resource families, not implemented route families. A Docker driver is absent, and the Kubernetes namespace driver, a development profile, admits an exec only on the confinement its probe observed. A general architecture goal therefore does not imply complete served domain coverage.

What is derived, and what is authored?

Bundle source is authored under xtask/bundle-source. The renderer produces deterministic bundle bytes and digest manifests, using the wire crate's controlled hashing and bounds bindings. The JSON schemas are not generated from Rust types. Released trees under contracts/substrate-wire remain immutable and must reproduce byte for byte with their own renderer.

The daemon's command-line parser is authored with clap in main.rs. HTTP handlers and store transitions are authored Rust too. Neither the CLI nor its release changes are generated from an ESS or Entity Runtime model. Contract checks prove specific relationships between declarations and behavior; they do not establish whole-system derivation.

Follow operations and observations to see how W1, O1 and X1 relate during a request, then run the command.