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.
| R-Series part | What the deployment takes from it |
|---|---|
| Receipts | Intent and outcome receipts for each governed task, issued by the engine |
| Verification | The offline verifier, built on the R-Series SDK, with both signature legs required |
| R+14 Key lifecycle | The tenant vault, planned on the R+14 key lifecycle; the key boundary is being defined |
| The evidence contract | Trust opened only with the operator’s pins, in both modes; offline bundles in the Disconnected mode |
The package has no receipt core and no cryptography of its own. Atlas, for local evidence search and export, is a separate capability.
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 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. |
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. |
| 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. |
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 current development build uses test keys generated for each run. Production custody is not built yet.
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. |
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.
| Not defended | What the evidence must not claim |
|---|---|
| Host-administrator compromise | That host captures, rule dumps or guard records are independent of the host. |
| Data sent to an approved destination | That data cannot leave through an approved flow. |
| 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.
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.