Deployment modes
Managed, sovereign and air-gapped deployment, data residency, credential handling and the security model summary.
Deployment modes describe the intended topology. None is generally available.
Your infrastructure. Not our playground.
Boundary
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).
Modes
| Mode | Control plane | Inference | Status |
|---|---|---|---|
| Managed | Vendor control plane for fleet, licence and dashboard; data plane in the customer account | Per residency floor | designed |
| Sovereign | None required; the runtime applies policy, finishes work and exports evidence on its own | Per residency floor | designed |
| Air-gapped | None; no external network path | In place only | Coming soon: later design milestone |
Air-gapped operation needs open-weight executors and offline registries. It is a later design milestone and not available.
Data residency
Each executor and model pair declares its compute and inference location, prompt egress, training use and retention. A residency class is derived from live configuration, not copied from a static manifest, and compared with the policy floor for the component and environment when a change starts. Regulated components default to in-account inference in-region; cross-region use is an explicit opt-in. Being on a cloud provider or a hosted model service is never assumed to mean in-account. Resolver and reviewer inference obey the same floor as author inference.
Credential handling without secrets in the sandbox
The sandbox starts with no ambient credentials, keys or tokens. A step receives a handle; the egress proxy applies the credential outside the sandbox and re-originates the request. Handles expire with the step. Providers that require materialised secrets are flagged for security review and policy approval.
Security model summary
| Threat | Control |
|---|---|
| Prompt injection through retrieved content | Content treated as data; broker, proxy and filesystem enforce regardless |
| Credential theft | No ambient credentials; scoped, expiring handles |
| Metadata service access | Link-local addresses denied |
| Malicious extension | Signing, digest pinning, permission diff, conformance |
| Policy tampering | Protected paths, kernel outside every grant |
| Evidence forgery | Runner-only writes, append-only store |
| Direct deploy | Release identity only |
| Cost runaway | Multi-dimensional budgets, pause and escalate |
Numinance is designed to produce evidence that supports a customer's compliance program. It does not make anyone compliant.
Observability and evaluations
Telemetry follows OpenTelemetry conventions and is exported to the customer's own backend. It carries identifiers, decision and run references and metrics, and never secrets, handles, prompts, retrieved knowledge or customer code. Evaluations use the event stream and outcomes as a private customer corpus to compute qualification for promotion. That corpus stays in the customer account and is not a shared training set.
Boundary table
| Item | Managed | Sovereign |
|---|---|---|
| Source and credentials | Customer account | Customer account |
| Evidence | Customer account | Customer account |
| Fleet metadata | Vendor control plane | Not required |
| Breaker | Local | Local |
Failure cases
- Residency below floor at start: change refused.
- Control plane outage in managed mode: authorised work continues.
- Telemetry sink down: events buffer locally; evidence writing is independent.
Verification and recovery
How deterministic checks, an independent reviewer, bounded repair, canary observation, rollback and escalation decide whether a change keeps its authority.
Guides
Task-oriented walkthroughs for configuring Numinance, from onboarding a repository to a governed release, with each guide marked as runnable today or designed.