Forward-deployed on an air-gapped site
Air-gapped work is built air-gapped. Forward-deployed engineers work inside a site with no path out, using the site's own procedures for media, updates, and access, and leave nothing behind that reaches outward.
· 4 min read
IN SHORT
On an air-gapped site, E31 forward-deployed engineers build the use case entirely on the customer's Czar with no path out of the building. Inference, retrieval, adaptation, and evaluation run on the appliance. Material and updates arrive by the site's own media procedures, and the engineers work under the site's access rules, leaving nothing that reaches outward.
Some sites have no path out. No connection to a vendor's cloud, no remote session, no route from the appliance to anything beyond the building. Work there is built the same way it will run: with nothing reaching outward.
E31 Consulting treats this as a working condition rather than a special case. This article describes how a forward-deployed engagement runs on an air-gapped site and what the site should expect.
Built air-gapped from the first day
A common pattern elsewhere is to build connected and disconnect at the end. The practice does not do this. A use case built with an outside dependency carries that dependency in its shape, and finding out at the end that something quietly reached out is exactly the problem an air-gapped site exists to prevent.
So the engineers build inside the building, on the appliance, from the start. If something would need an outside path to work, it is not in the use case. The version that is published at the end has never run anywhere else and has never had a path out to lose.
Everything is on the appliance
The reason this is possible is the stack. Czar is the appliance in the rack. Substrate on it provides inference, retrieval over the site's documents, memory, adaptation on the site's own material, evaluation, integrity verification, and declared routes to on-premise systems. Agency on it is where agents are composed, versions published, bounds set, approvals assigned, and the run record kept.
That is the whole toolkit the engineers need. They compose in Agency Studio on the appliance. They index the site's corpus on the appliance. They adapt on the site's captures and documents on the appliance. They evaluate a version against the site's material on the appliance. They publish and read the run record on the appliance.
An engineer who needs a workspace outside the building to do any of this is not working the way the practice works. Certified engineers are trained and assessed on working inside sovereign sites, and this is what that means.
Material moves by the site's procedures
Material does enter the site: the documents to index, the records to learn from, the signed updates for the platform. On an air-gapped site, all of it moves by media, under the site's own review procedures.
The engineers follow those procedures. They do not bring a channel of their own, and they do not ask for an exception. If the site's procedure is slow, the engagement plans around it. The posture belongs to the site, and the practice works inside it.
The same applies in the other direction. Nothing built on the appliance leaves it. The practice does not take a copy of the version, the corpus, the adapters, or the record out of the building, by media or by any other means.
Access under the site's rules
Inside an air-gapped site, the engineer's access is granted the way the site grants it to anyone: a role on the appliance, read access to the material in scope, whatever the site's rules require for the systems the scope names. Devices follow the site's device rules.
At the end, the access is withdrawn and the engineers leave with no path out, because there was never a path out to begin with. An engineer inside your segment covers this in general; on an air-gapped site it is simply stricter.
What the site team ends up with
The end of an air-gapped forward-deployed engagement is the same as any other: the site team publishes a version alone, through their own approval, on their own appliance. The difference is that everything they need to do that, and to keep doing it, is already inside the building. There is no vendor to call, no outside service the version depends on, no path that might close.
The version, the corpus, the adapters, the run record, and the documentation stay on the appliance. The operators who built it alongside the engineers can change it. The site has a use case that lives entirely within its posture.
One more note, for estates with more than one building. Many customers run more than one posture across their buildings. A forward-deployed engineer on a mixed estate works inside whichever posture the building has. The air-gapped site stays air-gapped; the connected site uses what it already secures. The practice does not harmonize the estate toward one posture. How the practice works inside your posture describes this more fully, and the practice page at /practice covers how certified engineers are prepared for it.
Questions this raises
- Can the engineers test against anything outside the site?
- No, and the practice does not need to. Evaluation runs on the appliance against the site's own material. A use case that only works with an outside dependency is not a use case for an air-gapped site.
- How does new material reach the appliance during the build?
- By the site's own procedures for bringing media in, under the site's review. The engineers follow those procedures the same way site staff do. The practice does not introduce a separate channel.
- What about updates to the platform during the engagement?
- Signed updates reach an air-gapped Czar by media, through the site's procedures. The engineers work with whatever the site has approved and do not depend on an update arriving mid-engagement.
KEEP READING