The misconception: "taking over needs the command line"
In the previous article we described xGrid's Hub-Spoke design. Its most powerful capability is that any Spoke can take over as a new Hub — carry it away, plug it in, take over on the spot.
A common instinct after reading that: "So I need a laptop and the command line to do this?"
No.
In a disaster, the person taking over is often not an engineer but a nurse, an EMT, or a commander. What they have in hand is a tablet, not a laptop.
So taking over in xGrid is not "a command for engineers." It is a layered-access design.
Three layers of access: complexity is the user's choice
The same "take over" capability offers three depths of entry:
- The lowest layer, for engineers and sysadmins: fine-grained control and diagnostics.
- The middle layer, for advanced operators: programmatic triggering.
- The top layer, for anyone: pressing one button on screen.
Each layer has its own guardrails — confirm before an accidental tap, prevent double-taps, refuse the action if the state is wrong, time-out protection, and the whole thing is all-or-nothing: it either takes over completely or returns to where it started. It never gets stuck half-done.
The point of three layers: complexity is decided by the user, not forced by the system. Engineers can do fine-grained control; a nurse only needs one button. One capability, three kinds of people, each taking what they need.
From zero to taking over: scan and go
Next to each machine is a laminated connection card with two QR codes: scan one to join that machine's wireless network, scan the other to open the system. No typing network names or passwords, no URLs to remember.
Normally the tablet just stays connected to the nearest machine. When the Hub actually goes offline, a red prompt appears on its own at the top of the screen: "Hub offline — take over?"
The operator presses "Promote to Hub," a confirmation dialog appears, and after confirming, the screen shows "Taking over, please wait…" Moments later the page refreshes and this machine becomes the new Hub, carrying all the patient data from moments earlier.
No command line. No laptop. No commands to memorize.Automatic detection, not manual operation
Note the design choice: it is not a hidden "promote" button buried in a menu for the user to hunt for. The prompt appears by itself when the Hub truly goes offline.
This is deliberate.
Taking over is not a routine operation — it is an emergency one. You don't want someone pressing a button out of curiosity and suddenly giving the system a second Hub (split-brain). So the button appears only when it's needed: the Hub is genuinely offline, and you are a node that can take over.
And even if someone does tap it by mistake, the system self-corrects — the older Hub steps down on its own when it rejoins the network.
The design isn't to make mistakes impossible; it's to make mistakes self-correct after they happen.Low-level access is a fallback, not the main path
The one-button top layer covers the vast majority of cases. In a few situations engineers still need low-level access — local testing, a dry run, demoting a Hub back to a Spoke, or checking why something failed.
But that is a fallback, not the main path. Like an aircraft's manual-flight mode: you hope you never need it, but it must be there.
Can a tablet do low-level operations? Yes — but you don't need to
A tablet can install low-level tools too. But the point is: you don't need to.
The whole reason for layered access is to make the low level an option, not a requirement. In a disaster you won't ask a nurse to install some tool. You hand her a card: scan to connect, scan to open, press one button when it's time to take over.
This is the core idea of the whole design: package a sysadmin's power into an interface anyone can operate.
Further reading: Unplug and go — a Hub-Spoke designed for disconnection · "Offline-first" is not "offline-usable" · The Walkaway Test — does your system dare to run disconnected?