Skip to content

Customer-initiated support on the platform

Support for Substrate runs through the customer portal, and every remote session starts with the customer. On sovereign sites, a session needs the customer's attestation and ends on a hard expiry.

· 4 min read

IN SHORT

Support for Substrate is always initiated by the customer. Tickets, update bundles, and session requests live on the customer portal, which appliances never connect to. When a remote session is needed, the customer opens it. On a sovereign site that means attesting that data disks are detached, the network is isolated, the console is supervised, and the requester has authority; the session then carries a hard expiry.

A platform that never phones home needs a different model of support. There is no vendor telemetry to look at, no remote agent waiting for instructions, and no way for Element 31 to reach an appliance that has not been deliberately opened. Support has to start with the customer, because nothing else can start it.

That is how Substrate support works. The customer portal is where the relationship lives. The appliance has nothing to do with the portal. And a remote session, when one is needed, is an act the customer performs, under conditions the customer attests to, for a time the customer can see coming to an end.

The portal and the appliance

The customer portal holds the things a customer needs from Element 31 over the life of a subscription: support tickets, signed update bundles to download, billing, and requests for remote sessions. It is an authenticated site for the customer's staff.

The appliance has no account there. It does not report in, does not check for updates, and does not receive instructions from it. The portal cannot see a running Czar, and a running Czar cannot see the portal. Every artifact that moves between them, in either direction, moves because a person on the customer's side carried it.

This separation is what makes the rest of the support model coherent. If the portal could reach the appliance, every promise about posture would have an asterisk. It cannot, so there is none.

Most support needs no session

The ordinary case is that a site handles its own day-two operation. The records are local: Evaluation traces for every operation, Watchman's integrity history, serving health for every node. A site's operations team, often with an integrator who knows the building, reads those records and resolves most questions without anyone outside being involved.

When a question does go to Element 31, it usually goes as a ticket with the relevant records attached by the customer. Many issues are resolved that way, in writing, with the customer choosing what to share. Nothing has to be opened for a ticket to be worked.

When a session is needed

Some issues need someone to look at the platform directly. For those, the customer requests a remote session through the portal. On a connected site the customer opens the session on their own terms. On a sovereign site there is one more step: the customer attests, before staff can approve, that four conditions hold. Data disks are detached. The network is isolated. The console is supervised by someone on site. And the person making the request has the authority to open the window.

Staff approve after the attestation is on record, and the approval sets a hard expiry. The session runs inside that window, with the site's supervisor watching the console. When the expiry arrives the window closes whether or not the work is complete. The site is back to its normal posture, and a new session requires a new request and a new attestation.

What the record shows afterward

A session leaves a trail in the record: who requested it, what they attested, when it opened, when it closed. A security team reviewing the site later can see every moment outside eyes were on the platform and confirm that each was authorized and bounded. There are no unexplained windows because there is no way to open one without going through the steps.

For a site that has promised its own auditors or customers that nothing on the floor is reachable from outside, this is the evidence that backs the promise. Not a policy document, but a list of sessions, each one attested and each one expired.

Why it is built this way

The easier design would give Element 31 a persistent channel to every appliance. It would make support faster in the ordinary sense and it would make every statement about posture untrue. Substrate takes the other path: the customer holds the door, the customer decides when it opens, and the record shows when it did. Support is still available. It is just never the appliance that asks for it. The security overview at /security describes the attestation model this depends on.

Questions this raises

Can Element 31 log into our appliance to fix something?
Only inside a session the customer opened. There is no standing access, no backdoor, and no path from the portal to the appliance. If the customer does not open a window, no one outside the building can reach the platform.
What is the customer attesting to before a sovereign session?
That data disks are detached, the network is isolated, the console is supervised by someone on site, and the person requesting the session has the authority to do so. Staff approve only after that attestation is on record.
What happens when the session expires?
The window closes on its hard expiry regardless of whether work is finished. The site is isolated again, and the record shows the session's start, end, and who opened it. A new session requires a new request and a new attestation.

KEEP READING