Engineers who leave no path out
When E31 engineers leave a site, nothing they built reaches outside it, no access outlives them, and nothing they learned goes with them. That is a working discipline, not a closing checklist.
· 4 min read
IN SHORT
E31 engineers leave no path out of a customer's site. Access is granted by the site, used inside the segment, and withdrawn at the end. Everything is built on the appliance, so nothing needs to be moved in or copied out. The version reaches only declared routes to systems the site secures. The practice keeps no copy of anything built.
The last thing a customer should have to worry about after an engagement is what the engineers left behind. Not the use case, which is theirs and running, but the other kind of leftover: an account that still works, a session that was never closed, a dependency on something outside the building, a copy of the corpus on a laptop somewhere.
E31 engineers leave none of these. This article describes the discipline, and why it is a way of working for the whole engagement rather than a checklist at the end.
No path in that the site did not control
Leaving no path out begins on the first day. The engineer arrives with no standing access to anything. The site grants what the scope requires, under its own identity system, device rules, and approval chain. The engineer works inside the segment, on the appliance, under those rules.
The practice does not bring an alternative path. No remote tunnel, no outside workspace the appliance connects to, no account the site did not create. Because every path the engineer uses is one the site granted, every path is one the site can withdraw, and at the end it does.
Everything is built on the appliance
Versions are composed on the Czar in the rack. Corpora are indexed there. Adapters are trained there on the site's own material. Routes are declared there. Versions are published there and the run record is written there.
Nothing is built elsewhere and moved in, so there is no second copy that exists outside the building. Nothing is taken out, so there is no copy that leaves. The practice keeps no versions, no adapters, no corpora, no records, and no documentation from a customer's engagement. What it carries between engagements is its methods.
On an air-gapped site, this is enforced by the site's own media procedures. On a connected site, it is enforced by the same discipline: the engineer's tools stay inside the segment and nothing of the customer's goes anywhere the customer does not secure.
The version reaches only what the scope declared
A use case built by the practice makes calls only through declared routes, each named in the scope and set in the version. On a connected site the routes reach systems the customer already runs and secures. On an air-gapped site they reach only inside the building. There is no route to a vendor's cloud, no call home, no telemetry that leaves.
The site team can read the routes in the version after the engineers are gone. The run record shows every call the version made. If a route were present that the scope did not name, it would be visible in both places. The verification does not depend on trusting the practice; it depends on systems the site already controls.
Access is withdrawn at the end
When the engagement ends, the site withdraws the access it granted. The engineer's role on the appliance is removed. Read access to the material in scope is removed. Whatever the site's rules required for the systems in scope is reversed.
There is no session left open, no account that outlives the engagement, and no mechanism by which the practice could reach the appliance afterward. If the customer wants help later, they initiate it, and access is granted again for that engagement and withdrawn again at its end.
What this costs the practice, and why it is worth it
Working this way means engineers sometimes work slower than they would with an outside workspace. It means material moves at the pace of the site's procedures. It means the practice cannot show one customer's work to another as an example, because it does not have it.
The practice accepts these costs because the alternative undermines the thing it is building. A use case on a sovereign appliance that quietly depends on an outside path is not sovereign. A customer who owns everything except the copy the consultants kept does not own everything. A site whose posture was loosened for an engagement has a different posture than it chose.
That is why this is a discipline and not a checklist. A closing checklist catches what was left behind. The practice's approach is that nothing is left behind because nothing was ever placed outside the site's control. That is a way of working from the first day, and it is part of what E31 certification assesses.
An engineer inside your segment describes the first day of this discipline. How an engagement ends describes the last. The practice page at /practice covers the practice as a whole.
Questions this raises
- How can we verify nothing reaches out after the engineers leave?
- The routes the version may call are properties of the version, readable in Agency. The run record shows every call made. Access the site granted is withdrawn under the site's own identity rules. The verification is in systems the site already controls.
- Do the engineers keep notes or examples from our site for future work?
- No. Nothing built or learned on a customer's appliance leaves the building, including documentation and records. The practice carries its methods between engagements, not customer material.
- What if we want the practice to help later?
- The customer initiates it. There is no standing arrangement that lets the practice reach the appliance. A later engagement starts the way the first one did, and access is granted again under the site's rules for its duration.
KEEP READING