Deployment profiles

The runtime/secret-kernel split makes the deployment model a configuration choice rather than an architectural constraint. In a SaaS deployment the full stack — runtime daemons, secret kernel processes, relay, monitoring — is operated by the vendor; the customer brings policies, key material, and access controls. In an on-prem deployment the customer operates the complete stack on their own infrastructure, with the same software, the same API, and the same evidence format. A hybrid model is also valid: the customer runs the secret kernel on-prem or behind a hardware boundary while the vendor operates the orchestration runtime — the kernel stays off the network, so the trust boundary holds regardless of who manages the surrounding infrastructure.

Because the secret kernel communicates with the runtime only through a fixed, typed local interface, the hosting boundary can be drawn wherever the customer's risk model requires. The same DomainManifest, epoch binding, and policy receipts work in all three models. Switching deployment model changes only who manages which process and where it runs; protocol compatibility, evidence format, and audit vocabulary stay the same.

In the HSM profile, the Local Secret Kernel terminates in a hardware module. One active node_id binds to one active HSM-backed secret boundary, and the HSM identity is part of that binding. The Execution Plane still handles policy admission, DVM choreography, transport, logs, and public artifacts — the hardware boundary only owns permits, one-time secret material, secret logs, and secret-dependent transitions.

This profile fits deployments where certification, physical key boundary, and operational segregation are prioritized over deployment convenience. The DVM contract keeps the HSM role minimal and certifiable while the distributed workflow runs unchanged.

The software profile terminates in an isolated process or container boundary. Mobile deployments hold one participant's local share through a platform vault and native node runtime while the rest of the quorum runs on servers. The SDK exposes one product API and routes local keygen and signing through the same DVM contract.

All three profiles — HSM, software, mobile — share the same formal boundary contract. The K semantics, the L1 operation set, the receipt format, and the evidence shape are common. What differs is what sits behind the kernel boundary: a hardware module, a process boundary, or a platform vault. That separation keeps receipts, evidence, and operation state compatible across profiles without translation.

Three state classes have explicit placement rules. Replicated DVM state — public protocol projection, transition state, inbox facts, certificates — is replicated across the cluster. Local operational state — logs, session accounting, policy cache, telemetry — stays with the runtime. Local secret state — shares, nonces, presign artifacts, the secret log — stays behind the kernel boundary. Incident response maps issues to whichever class they came from.