RESOURCES
Installing, updating, and running a pool, including on sites with no path out.
Articles in Operations
- Operations
Sovereign uplink windows
On an air-gapped site, a remote session with Element 31 is possible only inside a window the customer requests, attests to, and that expires on its own. The attestation, the approval, and the hard expiry.
· 4 min read
- Operations
Customer-initiated support sessions
A Czar Grid never connects to the customer portal on its own. When a site wants Element 31's help, the site opens the session, decides its scope, and ends it. This article explains what that means in practice.
· 4 min read
- Operations
Training the site team
A Czar Grid is run by the team that already runs the floor. Bringing them up to speed comes down to four habits: reading the record, approving versions, handling signed updates, and knowing where safety lives.
· 5 min read
- Operations
Reviewing an incident from a local record
When something goes wrong on the floor, a Czar Grid gives the site a complete local record to review: the task version, the decisions served, the fallback, the robot's own stop. No vendor needs to be asked.
· 5 min read
- Operations
Approvals, named roles, and versions
On a Czar Grid, no site task runs until a named person approves a specific version of it. How authoring, versioning, bounding, and approval fit together in Agency Studio, and why the floor is safer for it.
· 4 min read
- Operations
The run record and the next morning
Every task that runs on a Czar Grid is recorded and replayable, and every decision the pool served is written down locally. The next morning, that record is what the automation lead reads first.
· 4 min read
- Operations
Replacing a node in a Grid
When one Czar in a Grid needs to come out, the pool keeps serving and the replacement arrives sealed with its provenance on record. It attests before it joins, and the site's record shows the whole exchange.
· 4 min read
- Operations
Adding a vendor's fleet to an existing pool
A Czar Grid serves every robot in the building regardless of vendor. Bringing a new fleet onto a running pool is routine: a declared route, a budget per robot, a watched first shift, no change to the subscription.
· 4 min read
- Operations
Who operates the pool
A Czar Grid is run by the people who already run the floor. This article lays out which role owns which part: the automation team, the safety officer, the integrator, the robot vendors, and where Element 31 stands.
· 4 min read
- Operations
Monitoring a pool that does not phone home
A Czar Grid sends nothing out of the building, so monitoring happens inside it. The record, the latency budgets, the fallback pattern, and Watchman's integrity checks are what the site watches.
· 4 min read
- Operations
Rolling back a release on the pool
A new release on a Czar Grid is a signed, read-only image. Going back to the previous one is the same procedure in the other direction, with the same verification, the same attestation, and the same record.
· 4 min read
- Operations
Updating an air-gapped Grid
An air-gapped Czar Grid has no path out and no path in. Updates still arrive, as signed bundles carried in by media, verified by the node before anything changes. This is how that works in practice.
· 4 min read
- Operations
Day two: operating the pool
After installation, a Czar Grid becomes part of the building's routine. Here is what the automation team actually does each shift: reading the record, watching budgets and fallbacks, and approving task changes.
· 4 min read
- Operations
Day one: installing a Czar Grid
What actually happens when sealed Czar nodes arrive at a facility: rack placement, posture decisions, attestation, declared routes, and the first robot that asks the pool a question.
· 4 min read