Operations
Keep work moving. Keep decisions in view.
The board keeps each operation's next decision visible. Review the plan and authorize before privilege exists; take the wheel when you choose. Approved work can continue within policy, and an operation stops with a reason when it needs a person's judgment.
The board
Four columns. Only the first one is your problem.
Operations move left to right on their own. A card enters Needs you with a plan and no privilege, and leaves Done, with evidence as a locked record. The three columns after the first are things happening, not things to do.
What a card holds
Enough to decide in four seconds.
A card is not a ticket summary. It is the whole decision: who asked, what will run, where, with what rights, for how long, and how it comes back.
Who asked, in their words
The original message from Teams, Slack or the help desk — not a rewritten summary. Dana said the front-desk printer stopped. That sentence stays on the card.
The runbook it intends to use
Named, versioned, and already certified. You are approving a fix that has been run and proven elsewhere, not a script written for your server in the last few seconds.
Certified runbooks →The rights, and their expiry
Which privilege it needs, on which machine, and for how many minutes. While the card sits in the first column that privilege does not exist yet.
Just-in-time elevation →Two moments
It interrupts you twice. Not once a minute.
Planning, elevation, execution, verification and sealing all happen without an interruption. The two exceptions are the two that should never be automated away.
Authorize
One click, and it is the click that mints the lease. Before it, the operation holds a plan and no privilege at all. After it, admin rights exist for a fixed number of minutes on one machine.
Your name goes on the operation at that moment, and it stays in the record next to the work it authorized.
What the record carries →Take the wheel
Watch a step you do not like and step in. A fresh lease is minted under your own identity — the AI's lease is never handed over — and the work continues in the same operation.
It does not fork into a second job with a second audit trail. Same operation id, same receipt, with the handover recorded in it.
Commanded autonomy →Attention
The work is continuous. Your attention is not.
This is the whole economic argument for the board, drawn to scale. Seven operations occupy a full hour. The technician lane underneath shows every second the human was actually engaged.
The stop
It stops before it guesses, and hands you the reason.
The dangerous automation is the kind that improvises when reality does not match the plan. Three things halt an operation and put a card back in front of a person.
-
A precondition is not true
The runbook declared what had to be true before its first step. If the service is not installed, or the disk is below the threshold it needs, the operation does not start and the card says which precondition failed.
-
The machine's answer does not match
Every governed operation asks the target an independent question. If the answer is not the declared outcome, the operation does not report success. When a recovery path was declared before execution, the card records whether it fired.
-
Nothing in the library fits
When no certified runbook matches the request, the planner builds a plan, shows it to you in full, and waits. This is the one path where something new is written — and it cannot run without a person reading it first.
A failed operation still completes and still signs. "No response captured" is a real recorded outcome, not a gap in the log. A board that only produced records for successes would be advertising rather than evidence.
The questions people ask about the board.
If I never press authorize, what happens?
Nothing runs. The card sits in the first column with its plan, and no lease is minted. The absence of your click is a hard stop, not a delay before a default. You can also set standing authorization for a specific class of certified runbook, which moves your say-so earlier rather than removing it — see Commanded Autonomy.
Does it look the same for one technician and a whole bench?
No, and it should not. One virtual technician working through operations gives you a single ordered queue, sorted so anything needing a human sits at the top. Several running at once splits into a lane each, so you can see where the work is concentrated, which client is absorbing the hour, and which card has been sitting in Needs you longest.
Can I take over after the AI has already changed something?
Yes. Taking the wheel mints a fresh lease under your own identity and continues the same operation — same id, same receipt. The handover is recorded in it, so the record shows which part of the work the AI did and which part you did.
Does the board show me what it is about to run?
Yes, in full. The card names the certified runbook and version, the target, the privilege being requested, the number of minutes it will exist, and the declared rollback. A runbook is not a black box — you can open the steps before you approve them.
What stops one client's operation appearing on another client's board?
Records, storage and boards are isolated per tenant, and an operator's scope is identity crossed with customer. An MSP primary can reach into its own sub tenants; a sub tenant can never reach up or sideways. That rule binds the AI exactly as it binds a person — Roles & Multi-Tenancy.
See it with your own tickets
Watch one hour of the board in fifteen minutes.
We will run a real operation end to end, take the wheel mid-flight, and then open the record it produced.