DCS is developing a customer-hosted deployment of R-Series for local AI workflows, with work focused on governed execution, offline evidence verification and independently tested deployment controls. It is a way to run R-Series inside an environment the customer controls, not a separate product.
There is no defence accreditation and no production-availability claim. Nothing built so far is evidence from target hardware.
Approved local models and internal workflows, on infrastructure the customer controls.
A single-host package is being built: a local inference gateway, a boundary guard, host network rules and an offline verifier, with the R-Series engine issuing every receipt.
Integrated install, key custody, isolation and failure tests, and independent review are still ahead.
An evaluation starts from a named use case, its data classification and the infrastructure. No government approval is promised.
Receipt format, signing, trust and evidence verification. Every receipt is issued by the R-Series engine.
Authorisation, approvals and connector execution: which action may run, and against which approved system.
The local inference gateway, installation, the network and host boundary, and offline dependencies.
The package has no receipt core and no cryptography of its own. Atlas, for local evidence search and export, is a separate capability. Connector OS · Atlas · How proof works
Four stages, all inside the customer’s environment.
Images, model artefacts and the verifier arrive as a release that the operator imports and checks by digest. Trust anchors never travel inside a release.
A request enters through the one inbound port. The local gateway authenticates it, checks it against pinned policy and serves it with a local model only.
The R-Series engine signs the intent and the outcome. The evidence log keeps them on the customer’s host.
The customer checks receipts with the offline verifier: both signatures required, no DCS account, no network.
The local gateway is the only entry point for user requests. It authenticates the user, classifies the task, applies policy, calls the local model and refuses closed on failure.
| When this happens | What the design does |
|---|---|
| There is no policy object, or the task is unknown | Denied. A missing policy means deny, and an unknown or missing classification counts as sensitive. |
| The request body names a tenant | Refused. The tenant comes only from the authenticated credential. |
| The model times out or returns malformed output | The task stops with a typed refusal. Nothing is passed through or repaired. |
| The model or its GPU is unavailable | The sensitive task stops: no other model, no foreign API, no cached answer. |
| The signer, the evidence log or the disk fails | The action is held. It does not run without a durable intent record, and nothing is reported as success. |
| A request or a model output contains a URL | It is not fetched, and no redirect is followed. |
| The host clock is set back | New time-bearing evidence is refused, and the event is recorded as degraded. |
Every outcome is written down as it was. Denied, failed and unknown are recorded, never turned into success.
The boundary is enforced at the host: an explicit list of approved flows, and host network rules that drop everything else. Application checks are defence in depth only.
Each approved destination is an exact address, protocol and port, fixed when the configuration is built. Hostname patterns and “private range means local” rules are not allowed. A flow that is not on the list is not allowed.
Host network rules for IPv4 and IPv6 drop everything that is not on the list, for every container, not only the gateway. Closing IPv4 never implies that IPv6 is closed.
Before a start, the guard compares the host rules with the expected form for the mode and checks the engine settings. With rules absent, partial or for the wrong mode, it refuses, and nothing with a route runs. A direct start without the guard’s fresh start token is refused.
While the stack runs, the guard keeps checking. If the rules change or a start bypasses it, it stops the stack, removes the routed networks and writes a typed record.
Host-administrator compromise is out of scope: root on the host can disable enforcement and forge records. Host captures and guard records are only as trustworthy as the host administrator.
The boundary rests on host enforcement, so it is described for one host, and for its tested build and configuration only.
| Path | What the design requires |
|---|---|
| External API calls | Denied by default on output and forward, for IPv4 and IPv6 literals, hostnames and any port. |
| DNS | Only the declared resolver, and only for the declared internal zone. Nothing is forwarded. |
| Proxies and URL fetches | No proxy settings in the containers, and services built with fetch-by-URL turned off. |
| Redirects and rebinding | Redirects out of the approved set are not followed. The rules allow addresses, not names. |
| Update agents | No route. Images are referenced by digest and never pulled at start. |
| Telemetry | Turned off in the configuration and denied by the host rules. The switch alone never counts. |
| The host itself | Host gateway addresses, metadata services and host listeners are denied to containers. |
| Socket and privilege bypass | No engine socket in any container, no privileged mode, no host networking. |
| Other containers on the host | Traffic between the project’s networks and every other bridge is dropped in both directions. |
An empty egress log is reported as insufficient evidence, never as no egress. Absence of egress is claimed only from the bracketed test procedure, within its interval.
The engine issues every receipt, and a durable outbox and an append-only evidence log keep them on the customer’s host. Signing requests reach the customer’s key system through an interface.
In development
The customer checks receipts with the offline verifier: the R-Series SDK, both signature legs required, no DCS account and no network.
The keys it trusts come from pins taken out of band, never from the bundle being checked. A bundle that carries its own pins is refused.
A dedicated offline verifier with a pinned trust bundle is in development, and will replace the SDK verifier.
A trust bundle gives every anchor exactly one role: trust-update, release or evidence-issuer. The trust-update role is held by the buyer, never by DCS.
A DCS release is checked against the pinned release anchors and carries no anchors of its own. A release that does is refused as a whole.
A bundle older than its maximum age, or revocation data older than its limit, is reported stale, never valid as current.
The mode is a deployment choice fixed in pinned configuration. A mode change is a recorded redeploy, never a runtime switch.
| Topic | Disconnected, as designed | Connected private, as designed |
|---|---|---|
| Routes | No external routes, shown only for a named build, configuration and test interval. | The same, plus declared external destinations as exact tuples, reached only through a logging egress proxy. |
| Signing | A local signer or the customer’s key system. A cloud key service cannot be required. | A cloud key service or remote HSM only if declared. The provider is then inside the trust boundary for key use. |
| Time | The local clock, labelled with its assurance. Later export or anchoring cannot create independent event time. | An external time source or witness only if declared, labelled with the provider. |
| Trust bundle | Local, with a pinned maximum age. Until the buyer sets it, the bundle is reported stale, never fresh. | The same. |
| Revocation | Can be stale up to the pinned limit. Beyond it, the verifier reports stale. | The same. |
| Connectors | Approved internal systems only. No public connectors. | Declared external destinations only, each tested or accepted in writing by the buyer. |
| Updates | Offline import only, recorded. No remote access by DCS. | Offline import by default. A customer-operated mirror only if declared. DCS is never a destination. |
In development “Disconnected” and “Connected private” are names for the two modes, not property claims. The first package targets the Disconnected mode, and the egress proxy for Connected private is not built yet.
The current development build uses test keys generated for each run. Production custody is not built yet.
“Unreachable” only means something if the same probe would have reached the same place without enforcement. So every negative result is bracketed by positive controls.
Controlled canary services on a lab network must be reached from every service while the package rules are off. The public internet is never used as a canary.
With the shipped configuration started through the guard, no canary may record a hit, while every approved flow still works.
The opening control is repeated at the end. If a control fails, the result is inconclusive, never a pass.
Every result is bound to the build, the configuration and the test interval. Without all three it cannot support a pass, and a failure is never deleted.
| Not defended | What the evidence must not claim |
|---|---|
| Host-administrator compromise | That host captures, rule dumps or guard records are independent of the host. |
| Physical access to the device | Anything about hardware tamper resistance. |
| The supply chain beyond pinned digests | That a pinned component is free of vulnerabilities or backdoors. |
| Hypervisor, firmware and CPU side channels | Hardware isolation of any kind. |
| Data sent to an approved destination | That data cannot leave through an approved flow. |
| The customer’s network beyond the host | Anything about the wider network. The tests observe at the host only. |
| A determined local attacker exhausting resources | Availability. |
| Legal or regulatory determination | Any regulatory status. |
| A malicious operator without root | That the package prevents misuse by its operator. Actions are recorded, which supports detection only. |
A first pilot is planned for non-classified data only.
This is the planned process for a first pilot. It has not run yet.
The buyer names a sponsor and a security owner, the workload, its data classification and the infrastructure owner.
The threat and data-flow model and the acceptance criteria are agreed with the buyer before proof design. The buyer’s security owner accepts the model.
One customer, one environment, one model and one workflow, on non-classified data, on a single-node platform.
Offline install, run and restart with external routes unavailable. Denial shown with reachable canaries and positive controls for every service, both IP families and the DNS, proxy, redirect and update paths. Model, signer, storage and disk failures. Stale trust and clock rollback refused. Every capture and configuration is bound to the build, the configuration and the interval.
The evidence states what was shown, for that build and that environment only. It never claims universal denial.
The acceptance pack includes customer-run offline verification and an independent review of the deployed version, with an operator runbook, restore and rollback, admin separation, and an SBOM and CBOM.
Acceptance is a buyer and DCS sign-off record. It is not a certification badge.
Status as of 31 October 2026: In development. The customer-hosted package is built and is in independent review. Receipt V2 revision 7 was issued on 30 October 2026. Evidence Contract v1 was signed with conditions by the programme’s cryptography lead on 30 October 2026. Every statement on this page is drawn from the claim register of that date.
We do not describe it that way. The design is a boundary on one customer-controlled host: deny-by-default egress through an approved list and host network rules, a guarded start, and evidence that is checked offline. Any statement about the boundary will be scoped to a tested build, configuration and environment.
Not by design. DCS has no runtime route, account, remote access, telemetry or update channel, and is never a declared destination. Releases are imported offline by the operator and checked by digest.
An approved local model, pinned by content digest and loaded from a local volume. Pinning shows which bytes are running, not that they are benign.
The sensitive task stops. The gateway calls no other model, uses no foreign API and returns no cached answer, and the stop is recorded.
The design gives the customer’s key system an interface and keeps customer-held keys as the intended control model. Where keys are generated, used and wrapped is being defined, and the development build uses test keys only.
That is the design: the offline verifier needs no DCS account and no network, takes its trust pins out of band, and requires both signatures.
No. It makes no hardware, availability or regulatory claim. Its evidence can support your own control mapping.
It is in development. A first pilot will be one customer, one environment, one model and one workflow on non-classified data, with acceptance criteria agreed with your security owner first. Start with an evaluation enquiry: your use case, data classification and infrastructure.
Sovereign Deployment is in development. If you have a named use case, tell us about it.