Customer-initiated support sessions

Most support arrangements assume the vendor can reach the equipment. A Czar Grid assumes the opposite. The appliance never connects to the customer portal, nothing on it reports outward, and Element 31 has no path onto the floor unless a person at the site opens one. Support still exists; it is simply arranged so that the customer starts it, bounds it, and ends it. This article describes how that works day to day and why the direction matters.

The direction of every connection

The customer portal is where a site goes for support tickets, billing, signed update downloads, and remote sessions. The important word is goes. A person at the site, on a machine that is not the appliance, signs in and does something. The appliance itself is never a party to the portal. It does not check in, does not fetch, and does not announce itself.

This holds under every posture. A connected site, whose pool reaches only the systems the site declared through Local Bridge, does not have a declared route to Element 31 by default and should not expect one. An air-gapped site has no path out at all. In both cases, the portal is a place people visit, not a place the Grid talks to.

Starting with a ticket

Most support begins without a remote session. The automation lead has already read the local record, usually knows which fleet, task version, or node is involved, and opens a ticket through the portal describing what the record shows. Element 31 engineers respond in the ticket. A good many questions are resolved this way, because the site holds a complete record and can quote from it.

Nothing about a ticket touches the appliance. The site shares what it chooses to share, in words and extracts it selects. The record itself stays on the operator's hardware.

When the site opens a remote session

Sometimes the site wants an engineer to work alongside its team rather than correspond. The site initiates that. A remote session is opened by the customer through the portal, for a purpose the customer states, and it runs for as long as the customer allows. Element 31 cannot open one.

On a connected site, the session is a deliberate act with a defined scope, taken by someone with the authority to take it. The automation lead is present. The session ends when the site ends it. Anything an engineer does during the session is done with the site watching, and the site's own record continues to be written throughout.

On an air-gapped or otherwise sovereign site, a remote session is only possible inside an uplink window. The customer must attest, before the window is approved, that data disks are detached, the network is isolated, the console is supervised, and the person requesting has the authority to do so. The window carries a hard expiry. When it lapses, the site is isolated again whether or not the work is finished. Sovereign uplink windows describes that procedure on its own.

What a session is for

A session is for working a problem the site has already framed from its record: a release behaving unexpectedly, a node whose attestation needs a second pair of eyes, a question about adaptation or evaluation on the pool. It is not for routine monitoring, and it is not a channel that stays open between problems. The pool is operated by the site; a session is an occasional, bounded invitation.

Updates follow the same direction. A signed bundle is downloaded by the customer through the portal, from a connected machine, and brought to the Grid by the site, whether across a network the site controls or on media across a gap. The appliance does not retrieve its own updates and no session is required to apply one. Updating an air-gapped Grid covers that procedure.

Why the direction matters

A support path that the vendor can open is a connection the site did not decide on that day. On a floor where camera feeds, captures, task records, and the record of every decision are meant to stay inside the operator's network, a standing support connection would contradict the whole arrangement. Making every session customer-initiated keeps the promise simple: nothing leaves the building, and nobody enters it, except when the site chooses.

It also keeps the operating roles clear. The automation team runs the pool. The safety officer approves bounds and reviews incidents from the record. Element 31 installs the pool with these people and afterwards is available through the portal when called. The site never has to wonder whether someone is connected, because the answer, unless the site has just opened a session, is no. Monitoring a pool that does not phone home describes how the site watches its own pool in the meantime.