Solution
Governed Autonomous Execution
Autonomy is granted per action, on the blast radius of that action, never on how confident the model was. This is the part of the platform a change advisory board can actually read.
- Per actionAutonomy is granted one action at a time, never per platform and never by a switch.How it is designed
- Four gatesPre-check, execute, post-check, and a rollback armed before the first step runs.On every Action Ticket
- ApprovalStill required on every procedure in the shipped library. We do not sell day-one autonomy.Current library, stated plainly
- 2,000+Nodes under governed execution in production today, with pre-check and post-check on each.Counted, not forecast
What it changes
What a governance model buys you that a confidence score cannot
Autonomous operations stall in the same place at every organisation we talk to: nobody will let software change production, and they are right not to until four questions have answers. Which actions can run, what each one can break, who owns it, and what the record looks like afterwards.
Get autonomy past change control
The gate is stated in the language your change process already uses, so a board reviews a policy about actions rather than a claim about a model. That is the difference between an approved rollout and a permanent pilot.
Bound the worst case deliberately
The size of your worst outcome is set by a policy you wrote, not by how certain a model happened to feel. Anything carrying service impact is held for a named owner with the plan and the rollback attached.
Close the patch window without a war room
A run across thousands of nodes is sized by execution pods rather than by device count, and every node still gets its own pre-check and its own post-check. Parallel execution changes the throughput, never the governance.
Turn the audit into a query
Every action carries a pre-check result, a post-check verdict, a rollback path and a named owner, recorded the same way every time. Answering what happened stops being an archaeology project.
How it works
Every action runs as an Action Ticket
A confidence score describes the diagnosis. It says nothing about the consequence. A model can be ninety‑nine percent certain about a change that drops every session in the estate, and unsure about a pod restart that cannot hurt anyone. The operator's question was never how sure are you, it is what happens if you are wrong, so the gate is the blast radius of the action.
Every action therefore runs as an Action Ticket. Not a script, not a webhook, and not a model acting on its own authority, but a bounded unit of work with four things attached before anything executes.
The model
Autonomy is earned, one action at a time
Not as a switch, and not per platform. An action moves stage when there is a record behind it, and the record is the plan, the pre-check results and the post-check verdict from every run that came before.
Four stages, and one of them is a terminus
A named owner and an approved procedure before it can be proposed A record of approved runs before it can be bounded The radius never widens on its own
Some actions are designed never to move at all. Anything that writes to a financial record, changes a control another team owns, or has no viable rollback stays where it is permanently. That is the correct answer rather than a gap to engineer away.
- A named owner and an approved procedure before it can be proposed
- A record of approved runs before it can be bounded
- The radius never widens on its own
It has to hold at fleet scale, or it does not hold
A procedure that walks two thousand nodes one at a time turns a patch window into a war room. The execution engine sizes a run instead, starting execution pods appropriate to the work, with each pod handling many targets.
Pod count follows batch size, concurrency limits and the blast radius policy for the action. It never follows the device count, and every node still gets its own pre-check and its own post-check.
See it on a real fault
Four actions this describes
Each one walks a specific action end to end: what its pre-check asserted, what its blast radius allowed, and who had to press go.
- Service OpsThe CAB meeting where nobody can score the riskRead the walkthrough →
- Service OpsThe certificate expired on a SaturdayRead the walkthrough →
- Security OpsDay one, and the new starter cannot log inRead the walkthrough →
- DevSec OpsA critical CVE lands the day before releaseRead the walkthrough →
Evidence
What is actually recorded
We have no permission‑cleared customer logos or quotes to put on this page, and we are not going to invent them. Here are the figures instead, each one linked to the deployment it came from with its basis stated.
- Production deployment2,000+Nodes live under governed day‑two automation, heading toward a target estate an order of magnitude larger.Basis: counted live today. The target figure is a customer forecast, not a result.Day-two server operations →
- Production deployment85%Of routine manual operations automated under governance across a carrier estate of more than twenty‑seven thousand devices.Basis: measured in production, against the documented prior process.Carrier-scale operations →
- Production deployment100%Of automated fixes carry full provenance: the RCA path that justified them, the actions taken, and the closure state.Basis: every fix, not a sample. This is a structural property, not an average.Closed-loop automation →
Questions we get asked
Frequently asked questions
Why not gate on the model's confidence score?
Because confidence describes the diagnosis and blast radius describes the consequence, and only the second one answers the operator's question. A model can be highly confident about an action that takes down a shared service, and unsure about one that cannot hurt anything. Gating on confidence means the size of your worst outcome is set by how certain a model felt, which is not a control anyone can write into a change policy.
What happens when a post-check fails?
The rollback fires. It was armed before the step executed, so the reversal path is known rather than improvised. Completed steps are reverted, the ticket escalates with the full execution log attached, and the incident does not close. A procedure that finished is not an incident that ended.
Do any procedures run without a human today?
Not out of the box. Every procedure in the current library carries an approval requirement. Actions move to autonomous individually, on the evidence of having been run with approval first, and some are designed never to move at all.
How is this different from a runbook automation tool?
Runbook automation executes steps. It generally does not assert the preconditions at execution time as a named step, does not verify the outcome against live signals rather than exit codes, does not arm a rollback before running, and does not decide who is allowed to press go based on what the action can break. Those four things are the difference between automation and governed execution.
Can this run inside a restricted or air-gapped environment?
Yes. The execution engine, the audit store and the reasoning layer all run inside the customer perimeter with no egress required. The tradeoffs of that deployment model are set out on air-gapped AIOps.
Go deeper
Where to read next
- PlatformSentinel AIThe Orchestrator, Co-Pilot, ProcBot and Sherlock, and which one does what inside a single incident.
- SolutionAutonomous L1 OperationsThe same governance applied to the tier that carries the most volume and the least tolerance for a wrong action.
- TrustSecurity and access modelRBAC, the audit store, and what the platform is permitted to touch inside a customer perimeter.
Bring us the action you would never let software take
We will walk it through the gate with you: what it can break, what its pre-check would assert, what its post-check would have to prove, and whether it should ever run alone. If the answer is that it should not, we will say so.