Skip to content

TECHNICAL PREVIEW · IN ACTIVE DEVELOPMENT

ALL NOTES

DEPLOYMENTS

Austere sites and the emitting uplink

In every other environment, connectivity is something an operator would like and cannot always have. At an expeditionary site it is something they may have and must sometimes refuse, because an emitting uplink is a signature and a reachback path is an exfiltration path.

· 8 min read

Almost every industrial environment treats connectivity as something an operator wants and cannot always get. A plant has dead zones behind steel. A yard loses coverage behind its own cargo. A remote site has a link too thin to be useful. In each case the link is a good thing in short supply, and the architecture exists to work without it.

An expeditionary site inverts that. Connectivity is frequently available and sometimes has to be refused, for two independent reasons. A transmitter is a signature: emitting announces that something is here, at a place and a time, with a pattern that persists whether or not anyone is listening today. And a reachback path is an exfiltration path, because a link built to carry data out is a link capable of carrying data out. Which bytes cross it is a software property, and software properties are the weakest kind of assurance to offer an accreditor.

So air-gapped operation here is not a limitation to be worked around. It is a posture, chosen and un-chosen deliberately by the people responsible for the site, and that distinction has architectural weight. If disconnection is a decision rather than a fault, then the disconnected behavior of the system has to be its primary behavior, and connection has to be an explicit action with an explicit cost.

Emission is a decision

Take that seriously and a long list of ordinary software conveniences becomes unacceptable. A license check that contacts a server. Telemetry that reports health. An update client that polls. A control plane in someone else's infrastructure whose absence degrades the fleet. Each of these converts a posture decision into a software default, and defaults are exercised at whatever moment the code happens to reach them rather than at a moment anyone chose.

There is a second, subtler failure in systems that merely support disconnected operation. A system with a connected mode and a disconnected mode has two behaviors, and only one of them is exercised routinely. Development happens connected. Testing happens connected. The disconnected path becomes the least-travelled code in the product and is discovered to be broken at the point of use, which in this environment is the point where nobody can fetch a fix. The way out is not better testing of the offline path but eliminating the distinction: the system runs the same way whether or not anything is reachable, and a bundle crossing the boundary is a bounded event rather than a state change.

The cost of refusing the link then has to be honestly stated. Refusing should cost nothing operationally — no capability lost, no degraded coordination, no expiring authorization. What it costs is timeliness: updated models, revised policies, and new configuration arrive when a bundle is carried across, on the unit's schedule, not before. That is a real cost and it is the correct one to pay, because it is the only cost that does not accumulate into a dependency.

Governance with the vendor blind

Classification confines every byte. This is stronger than commercial sensitivity: handling is determined by the classification of the material, mixing levels is itself an incident, and the boundary is enforced by people whose job is to enforce it. Commercial terms written on the assumption that a vendor may collect telemetry for support and product improvement do not survive contact with that regime. Neither does a support model built on remote diagnostics.

Governance therefore has to work with the vendor structurally blind. Authority moves down as signed bundles. Evidence moves up as attestation. Operational data does not move at all. The general property — that a fleet plane can verify integrity across sites while seeing nothing about what any site did — is argued elsewhere, and this archetype is where it stops being a design preference and becomes a precondition for the system being allowed on the site at all.

One refinement is specific to austere operations. Even the evidence channel can be too much. Attestation measurements disclose nothing about operations, but the existence of an attestation exchange discloses that nodes are present and active, and its timing and volume are themselves information. So verification cannot depend on reaching a verifier. A node has to check the evidence it can check locally, against signed policy carried in the bundle, and continue working; the record of what it verified rides back across the boundary on the next crossing, at the operator's discretion. A machine that stops working because it could not phone a verifier has reintroduced the dependency the architecture exists to remove.

Austere logistics change what service means

Power, cooling, transport weight, and spares are all scarce, and compute competes for them against everything else the site needs. Generator capacity is finite and shared. Airlift and sealift weight is allocated. Cooling in a hot climate, inside a shelter, is a harder problem than cooling in a building, and the sealed enclosure that the security model wants is the enclosure that makes thermal management hardest. Density that would be reasonable in a facility is not obviously reasonable here, and sizing the plane down without breaking the architecture is part of the work.

Sustainment changes shape as well. There is no spare-parts depot and often no specialist. The sealed-node discipline — a signed, read-only image, one defined workload, no shell to log into — has a maintenance consequence that follows directly: field service becomes replacement rather than repair. Nobody opens the box, swaps a board, or reimages a unit at the site. A failed node is removed and a provisioned node takes its place, and the replacement proves what it is by attestation before it is given work or keys.

That is a cleaner maintenance concept than the alternative, and it is not free. It requires that provisioned spares exist, that provisioning works without connectivity, and that the person performing the swap can complete it without judgment calls. Designing for the least-specialized hands that will ever touch the equipment is the right target, and it happens to align with the security argument: a node with nothing to configure is a node that cannot be misconfigured under pressure.

The physical-security story cannot rest on a room

Equipment at an austere site is handled, transported, staged, and recovered by whoever is closest, on timelines nobody planned. It may sit unattended. It may be left. The datacenter assumption that physical access is the exception is not merely weakened here, it is reversed, and the general case for attestation on machines that get handled is made elsewhere.

What this environment adds is the requirement that possession not equal access. Data at rest and keys have to be protected such that holding the hardware yields nothing, and a unit that has been outside positive control has to be treated as untrusted until it re-attests, not after someone inspects it for damage. The seal on the node is doing security work and inventory work at once: it makes the question of what this unit is into a question with a cryptographic answer, which is the only kind of answer available when the chain of custody has a gap in it.

Provenance arrives as a written question

In this sector, supply-chain provenance is not a diligence item raised by a thoughtful buyer. It arrives in writing from an accrediting authority or a contracting office, and it asks what is in the machine, where the parts came from, who assembled it, and who has touched the software. Those questions are far easier to answer if the system was designed to answer them than if the answers have to be reconstructed afterward from purchase orders. Integration and final assembly in the United States, with the supply chain treated as a design requirement rather than a procurement artifact, is how the architecture is being built to make those answers documentable.

It should be said plainly that we hold no certifications or accreditations today, and nothing here should be read as implying otherwise. The properties described — sealed images, hardware attestation, disconnected operation, documented provenance — are being designed to support an accreditation process. They are not a claim to have completed one. In a sector where an unearned claim is disqualifying, the distinction is worth being explicit about.

Disconnected as the default

The design intent for this archetype is simple to state and demanding to build. The system's normal condition is disconnected. It coordinates, infers, adapts, and proves its own integrity with nothing reachable outside the site. Updates arrive as signed bundles when someone decides to carry them across, verified inside the boundary before anything is staged. Nothing operational leaves, ever, by any path, because no such path exists to be misconfigured.

The reason to build for this environment is not that it is the hardest one, though it is. It is that this is where autonomous systems are wanted for the most defensible reason there is: the work needs doing in places where a person's presence is itself the risk. Infrastructure aimed at that ought to be able to operate with no connection to anything, and ought to be able to prove what it is when someone asks.

DESIGN PARTNER PROGRAM

Build this with us.

We are working with a small number of teams operating real fleets in constrained environments. If the cloud is not an option where your machines work, we want to talk.