Installation modes
Where the Numinance runtime is designed to run - managed with a customer data plane, sovereign, and the later air-gapped milestone - and what you provision in each.
In every mode the code, credentials and evidence stay on infrastructure you control. The modes differ only in how much of the thin vendor control plane you use. "Your infrastructure. Not our playground."
The two planes
The runtime is split into a data plane and a control plane.
- The data plane is yours. It runs the orchestrator, the runners that create one sandbox per work unit, the credential broker, the egress proxy, the database, and the artifact and evidence storage. Source code, secrets, model traffic and evidence live here.
- The control plane is thin and holds metadata and references only. It serves the dashboard, fleet view, registry index and licensing. It never receives code, credentials or prompts.
Connections from the data plane to the control plane are outbound only, and orchestration payloads carry references and digests, never content. For the full mechanism see Data and control planes.
Deployment boundary
In each deployment mode, exactly what may cross to the vendor?
Customer data plane · fixed
- Runnerhost agent
- Engineworkflows
- Sandbox + harnessper work unit
- Broker + egress proxyhandles, default-deny
- Artifact storecontent by reference
- Evidence storeappend-only
- Source and credentialsrepos, CI, secret managers
Vendor control plane
Metadata service and dashboard. Holds change status, fleet state and licence state.
Managed: the vendor runs the thin control plane
Under developmentThe runner opens an outbound connection to the vendor-operated control plane. Nothing in the vendor plane can reach into yours, and only the metadata listed below may travel.
- Who operates the control plane
- The vendor, as a thin metadata service and dashboard.
- Link direction
- Outbound from the runner. No inbound path into your network.
- Workflow payloads
- References and digests only, encrypted with a key you hold; payloads outside the allow-list or over 16 KB are rejected.
- Human approvals
- Made in the dashboard by a human principal and validated against the author identity before acceptance.
- If the link is cut
- Installed runtime keeps applying policy, completing authorised work and exporting evidence.
✓ May cross to the vendor
- References: change_id, work_unit_id, run_id, artifact_ref
- Digests: sha256 of artifacts, policy and plan digests
- Statuses: state and gate outcomes as enum codes, timestamps
- Non-content telemetry: runner heartbeat, versions, breaker position, redacted structured events
✕ Never leaves the customer plane
- Source code: worktrees and repositories stay in your plane
- Diffs and findings bodies: stored as artifacts, travel as references
- Prompts and completions: content, so claim-checked into your artifact store
- Secrets and credentials: broker mints handles locally; sandbox holds none
- Evidence content: records stay in your append-only store; only digests and status can be summarised
Managed mode. An outbound link carries references, digests, statuses and non-content telemetry only. Source, diffs, prompts, secrets and evidence content never leave.
Text description
The customer plane is fixed in every deployment mode: Runner, Engine, Sandbox + harness, Broker + egress proxy, Artifact store, Evidence store, Source and credentials. Only the link to a vendor control plane changes. Everything is design intent under development; nothing here is connected to a running engine.
- Managed. The runner opens an outbound connection to the vendor-operated control plane. Nothing in the vendor plane can reach into yours, and only the metadata listed below may travel.
- Who operates the control plane: The vendor, as a thin metadata service and dashboard.
- Link direction: Outbound from the runner. No inbound path into your network.
- Workflow payloads: References and digests only, encrypted with a key you hold; payloads outside the allow-list or over 16 KB are rejected.
- Human approvals: Made in the dashboard by a human principal and validated against the author identity before acceptance.
- If the link is cut: Installed runtime keeps applying policy, completing authorised work and exporting evidence.
- Sovereign. The product works without the vendor control plane. You run the control components yourself, so nothing needs to leave your network for the system to function.
- Who operates the control plane: You. The runtime has no dependency on the vendor-operated one.
- Link direction: None required. Updates are pulled by the runner inside your own update window.
- Workflow payloads: Same reference-and-digest rule; the store they point to is yours.
- Human approvals: Made through your own identity provider, under the same no-self-approval rule.
- Licence: A signed, offline licence file. Expiry stops upgrades and new packs, never authorised work.
- Air-gapped · Coming soon. Air-gapped operation is on the roadmap as a later milestone after managed and sovereign. No package, date or procedure is promised, so the diagram shows no data flow for it.
- Status: Coming soon. Not designed in enough detail to document exact crossings.
- Today: Choose sovereign to keep the control plane out of your network.
May cross to the vendor in managed mode: References (change_id, work_unit_id, run_id, artifact_ref); Digests (sha256 of artifacts, policy and plan digests); Statuses (state and gate outcomes as enum codes, timestamps); Non-content telemetry (runner heartbeat, versions, breaker position, redacted structured events).
Never leaves the customer plane in any mode: Source code (worktrees and repositories stay in your plane); Diffs and findings bodies (stored as artifacts, travel as references); Prompts and completions (content, so claim-checked into your artifact store); Secrets and credentials (broker mints handles locally; sandbox holds none); Evidence content (records stay in your append-only store; only digests and status can be summarised).
Mode comparison
| Managed | Sovereign | Air-gapped | |
|---|---|---|---|
| Data plane | Customer-owned | Customer-owned | Customer-owned |
| Vendor control plane | Used for dashboard, fleet, registry index | Not required | None |
| Outbound connectivity | Outbound to the control plane | Only what you allow | None |
| Updates | Pulled by runners in your update windows | Pulled from a mirror you operate | Delivered by you out of band |
| Breaker | Customer-local | Customer-local | Customer-local |
| Status | Designed | Designed | Coming soon (later design milestone) |
Managed
Managed is the default shape. You provision the data plane in your cloud account or on your hosts. The vendor operates the thin control plane for the dashboard and fleet view. Runners register outbound with a host attestation and pull signed bundles and release manifests during windows you set.
What you get: less to operate, a ready dashboard for changes, approvals and qualification, and a fleet view of runners and breaker state.
What you accept: the control plane can see metadata such as change states and runner heartbeats. It cannot see your code or reach into your network, and it cannot trip or reset your breaker on your behalf without a human principal.
Sovereign
Sovereign mode runs the same data plane with no dependency on the vendor control plane. The product is designed to work without it: policy bundles, approvals, evidence and the breaker all function locally. Licensing is verified offline from a signed file, and expiry stops upgrades and support without stopping already authorised work or evidence export.
Choose sovereign when policy forbids any outbound dependency beyond your chosen model endpoints and source control.
Air-gapped
Air-gapped operation, with no network path out of the environment, is a later design milestone. Nothing about it is available or scheduled here. Sovereign mode is the closest designed mode today.
Customer targets
The data plane is designed to be provisioned in two shapes. Neither is a command you can run today.
| Target | Intended for | Shape |
|---|---|---|
| Customer cloud account | Production | Infrastructure-as-code module that provisions network, runner hosts, database, artifact storage, evidence storage and encryption keys |
| Compose | Single hosts, laptops, evaluation | A Compose layout of the same services |
| Kubernetes | Customers whose standard is Kubernetes | Later, after the above |
What customers provision
Design inventory
Names below are generic. Exact resources depend on the release.
- A private network with default-deny egress except through the egress proxy, and hosts that do not expose cloud metadata services to sandboxes.
- Runner hosts with a sandbox isolation profile. The profile the host offers caps the autonomy level any work unit may run at on that host.
- A relational database for orchestration state, with continuous backup.
- Artifact storage, and separate evidence storage with immutability (write-once retention) enabled.
- Encryption keys under your control.
- An observability backend if you want telemetry in your own tools.
- Identity: your OIDC provider, so approvers are real, attributable people.
- Model access: your own endpoints or cloud model services, with residency rules you set.
Failure modes
- Control plane outage. In managed mode you lose the dashboard and fleet view. In-flight authorised work, policy evaluation, the breaker and evidence writes continue locally.
- Weak host profile. A host that offers only a process-level profile cannot run work at high levels, by design. Moving up the ladder may mean moving up the isolation profile.
- Unpinned images. The runner refuses unsigned or unpinned images. A blocked update is the safe outcome.
Operations
The operator's mental model for running Numinance day to day - who approves, who can stop it, how autonomy is earned, and how a bad change is undone.
Risk and approval
How risk classes route work to autonomy, human approval or denial, and how separation of duties keeps an agent from approving itself.