Sovereign uplink windows

An air-gapped Czar Grid has no path out and no path in. That is the posture the site chose, and the ordinary procedures respect it: updates arrive as signed bundles on media, the record is read at the console, and nobody outside the building has a view of the pool. Occasionally, though, a sovereign site wants Element 31 engineers to work with it directly rather than by ticket. For that there is one mechanism, and it is deliberately narrow. This article describes the sovereign uplink window: what the customer attests to, how it is approved, and why it expires.

Who asks, and how

The site asks. Customer appliances never connect to the portal, so the Grid cannot request a window and Element 31 cannot open one. A person at the site, with the authority to do it, requests the window through the customer portal from a connected machine that is not the appliance. The request states the purpose. It is a customer-initiated act like every other support interaction on a Czar Grid, with additional conditions because the site is sovereign.

Before the request can be approved, the customer attests to four things.

The four-part attestation

Data disks detached. The site's material, meaning camera feeds, captures, task records, adapted model weights, and the record of every decision, is the operator's and stays inside the operator's network. Before a window opens, the data disks are detached so that the engineers working in the window are working on the pool and not near the site's data. The attestation says this has been done, not that it will be.

Network isolated. The Grid is confirmed to be isolated from the rest of the facility's network for the duration of the window, so the only path that exists during the window is the one the site has chosen to open for it. The robots are on their on-board models for perception and decisions while this is true, and they behave as their vendors built them to. Safety was never on the pool.

Console supervised. A named person from the site is at the console and remains there for the whole window. Nothing is done unobserved. If the site cannot keep a person at the console, it should not attest that it can.

Authority confirmed. The person requesting the window has the authority within the site to open it. On most sites this means the automation lead with the knowledge of the safety officer, or whoever the site's own governance names. The attestation ties the window to a person who can later be asked why it was opened.

Approval and the hard expiry

Only after the customer has attested to all four points is the window approved. The approval is bounded in time: every window carries a hard expiry. When the expiry is reached, the site is isolated again, whether the work was finished or not. There is no extension that happens quietly on the engineer's side. If more time is needed, the site makes a new request and attests again.

The hard expiry is what makes the window safe to use. The site can plan around it: schedule the shift, assign the supervisor, detach the disks, and know precisely when the building will be sovereign again without anyone having to remember to close anything. An expiry that could be stretched would be a connection the site did not decide on.

During the window

The site's supervisor watches. The engineers work on the pool: a node whose attestation needs attention, a release that behaves unexpectedly on this floor, a question the site raised in its ticket and wants worked at the console together. The site's record continues to be written on the operator's hardware for anything the pool does, and the site's own notes record what was done during the window and by whom.

When the window lapses, the supervisor confirms isolation, the data disks are reattached according to the site's policy, the nodes attest, and the Grid returns to serving the floor with the robots asking it questions again. The site then reads its record as it would after any change.

What the record shows afterwards

A sovereign site should be able to show, for every window it has ever opened, the request, the purpose, the four-part attestation, the approval, the person at the console, the expiry, and the return to isolation. Most of this is the site's own record-keeping around the portal request, and well-run sites treat it as a controlled document like any other change to a sovereign system.

The result is a floor that remains air-gapped in every sense that matters while still having a way to get Element 31 engineers to the console when the site wants them. The window is rare, requested by the site, conditioned on the site's attestation, supervised by the site, and ended by the clock. Customer-initiated support sessions describes the broader support model this sits inside, and updating an air-gapped Grid covers the more common sovereign procedure, which needs no window at all.