Operations
Deployment runbook
A node deployment is four processes with explicit contracts: operation gateway, runtime daemon, paired secret kernel, and message relay. This public runbook names the required control classes and readiness checks; deployment-specific variable names, storage paths, and secret material stay in the operator package.
The network layout mirrors the trust boundary: gateway, runtimes, and relay share the service network; each secret kernel is reachable only by its paired runtime. Reproduce that property with network policy, private service discovery, and authenticated runtime-to-kernel channels.
Identity and pairing
Each runtime has a stable node identity, signer index, active domain, and expected backend profile. The runtime-to-kernel channel is authenticated, profile-pinned, and readiness-gated: a profile mismatch or unreachable kernel fails readiness before an operation starts.
Production custody uses a permit-based kernel policy mode. The admission plane evaluates business policy; the kernel verifies step permits, epoch binding, key binding, phase, and slot before touching local key material.
- Runtime identity and signer index are stable and appear in evidence and metrics.
- Kernel pairing is one-to-one; a runtime does not share a kernel with another runtime.
- Kernel authentication material is provisioned out of band and rotated through the operator procedure.
- Backend profile and policy mode are pinned on both sides before readiness is reported.
Persistence
Production nodes persist the admission ledger, admission journal, node progress journal, node effect journal, lifecycle share store, local secret store, operational envelope store, and policy-authority trust bundle. Keep these stores separated by trust boundary: runtime journals are public evidence roots; kernel stores remain behind the local secret boundary.
- Admission records and journals are hash-linked and replayable.
- Runtime progress and effect journals are durable before external state is reported.
- Kernel local storage and operational envelopes use distinct storage roots.
- Policy-authority material is treated as a provisioned trust bundle.
Gateway configuration
The gateway is configured with runtime base URLs, domain binding, authentication mode, approval requirements, limits, and backpressure controls. Authentication can be terminated by a trusted reverse proxy, validated through JWKS, or checked through token introspection; the selected mode must produce the same client binding fields that evidence records consume.
- Runtime routing binds every gateway operation to a concrete domain and runtime set.
- Client identity, subject, roles, scopes, tenant, token id, and optional client-certificate hash are recorded into evidence.
- Approval and limit policy are configured at the gateway and reflected in policy preview responses.
- Backpressure is enforced at the gateway, runtime admission layer, and kernel channel.
Reference deployment
The public quickstart starts a local two-node topology for development. Production deployment material is distributed with the operator package and should be reviewed against the same checklist: identity, pairing, persistence, gateway auth, policy authority, backpressure, observability, and recovery procedure.