Book a demo Buy online
PlatformDelivery BoardAutomation & RunbooksOutcome ReceiptsJust-in-Time ElevationCredential VaultGoverned SessionsDevices & DiscoveryPatch ManagementReporting & ExportsRoles & Multi-Tenancy
Verified AI OperationsThe Operation LoopCommanded AutonomyCompare the operating modelThe Verified Operation Spec
SolutionsFor MSPsFor Enterprise & Internal ITHealthcareLegalFinancial servicesMunicipal & Education
ProofOperation walkthroughSecurity & architectureVerified Operation SpecFive questions for your RMM's AIChangelog
CompanyAboutFounder's noteContact
PricingBuy 1–20 technician licenses onlinePlans — from $499 per monthCustom requirementsFoundation Circle
Log in
Book a demoBuy online

Home/Platform/Automation & Runbooks

Operations

Turn the outcome you need into work you can review.

AI helps select a runbook whose outcome, preconditions and verification are already named. A person writes and certifies it against a test target before it is eligible for governed production work; any recovery path is declared with the procedure.

Review a runbookSee the operation loop
Runbook · service recovery · v4
typed outcomeprint queue accepting jobs
preconditionsspooler service installed · disk over 2 GB
steps5, signed, no free text
verificationthe target answers a fresh check
rollbackrestore the prior spooler state
certified bya second person, not the author
eligible forstanding authorization, service-recovery class
used byOP-000217 · SRV-ACCT-02

Anatomy

A runbook names a result. A script names keystrokes.

That difference is why an operation can be verified at all. If the runbook only said "run these commands", there would be nothing to check afterwards except whether the commands ran.

Anatomy of a certified runbookservice recovery · v4
01 — WHAT THE AUTHOR WRITES TYPED OUTCOME print queue accepting jobs A result, not a script The runbook names the state the machine has to end in. That is the thing that gets checked later, by the machine itself. PRECONDITIONS spooler installed · disk over 2 GB What has to be true first If a precondition fails the runbook does not start. The operation reports which one failed, instead of trying anyway and finding out. STEPS 5 signed steps · no free text Fixed steps, signed A person wrote them and signed them. The planner chooses which runbook to use; it does not rewrite what is inside one. 02 — AND ALL OF THIS EXISTS BEFORE IT MAY RUN THE VERIFICATION SRV-ACCT-02 answers: running The test that defines success Written with the runbook, run against the target afterwards. Its answer is the only thing that closes the operation — not the AI's account of its work. THE DECLARED ROLLBACK restore the prior spooler state The undo, written first A runbook with no rollback cannot be certified. You know how to reverse it before it runs, not after something has gone wrong. CERTIFICATION tested, then signed by someone else A gate, not a badge Someone other than the author signs it off after it has been run against a test target. That signature is what makes standing authorization possible. 03 — RUN TIME WHAT THE PLANNER DOES selects · does not write Selection, not improvisation It matches the request to a certified runbook and runs it as written. Your production server never meets a script invented for it thirty seconds ago.
The two blocks that make an operation provable — the verification and the rollback — are authored by a human before the runbook can be certified, which means before it is allowed anywhere near a customer machine. Success is defined by the person who wrote the fix, not by the model that chose it.

Certification

"Certified" is a gate you pass, not a sticker we print.

Every rung buys a specific permission and nothing more. The top rung is the only one that can run under standing authorization, and it is the only one a second person has signed.

The certification ladderwhat each rung unlocks
A FAILED RUN SENDS IT BACK DOWN NO GATE — ANYONE MAY DRAFT DRAFT anyone on your team GATE · PROVEN ON A TEST TARGET TESTED run against a test target GATE · A SECOND PERSON SIGNS CERTIFIED signed off by someone else GATE · YOUR POLICY ALLOWS IT ELIGIBLE, STANDING AUTH runs without a fresh yes Write it, save it, share it. It cannot touch a live machine. It ran on a test target and the target confirmed the result. A second person signed it off. An author cannot certify their own. Runs under standing authorization for its class. No fresh yes needed.
The top rung is earned and revocable. A certified runbook whose verification stops passing drops back down the ladder and starts asking for a human again — which is the behaviour you want from something you handed standing authorization to.

The honest edge

What happens when nothing in the library fits.

Most of what an MSP does repeats. Some of it does not. This is the path where something genuinely new gets written, and it is deliberately the slowest path on the platform.

  1. It says so, rather than improvising

    No certified runbook matches the request. The operation does not fall back to a model writing commands against production and hoping. It stops and says the library has no answer for this.

    Nothing has been leased · nothing has run

  2. It builds a plan and shows you all of it

    Typed outcome, steps, the check that would prove success, and the rollback — the same shape a runbook has, produced for this request. You read it before anything happens, not afterwards.

    A plan on the card, and a question

  3. A person authorizes this one specifically

    An ad-hoc plan is never eligible for standing authorization. Whatever you have delegated for certified classes does not apply here. Someone reads it and says yes to this exact plan on this exact machine.

    Leased privilege, target verification and the receipt still apply

  4. If it works, it becomes a candidate

    A plan that resolved a real ticket can be promoted into a draft runbook and start climbing the ladder. That is how the library grows — out of work you actually did, not out of a template pack.

    Draft → tested → certified

This is the part of the product where a model writes something. We would rather say that plainly than let you discover it. What we will not do is let that output reach a production machine without a named person reading it first, and without the same leased privilege, target verification and locked record that everything else gets.

Authorship

Who can write one, and who can bless it.

The separation is the control. An author who can also certify their own work has a library of one-person opinions, not a library of proven fixes.

Action Technician Senior / lead What it changes
Draft a runbookYesYesNothing yet — a draft cannot run on a customer machine
Run it against a test targetYesYesProduces the evidence the next gate asks for
Certify itNoYes, if not the authorMakes it selectable by the planner and eligible for standing authorization
Publish a new versionDraft onlyYesThe new version starts at the bottom of the ladder again
Withdraw a certificationNoYesIn-flight operations finish; nothing new selects it
  • Versions are immutable. Editing a certified runbook creates a new version rather than changing the one that has already been used. The receipt for OP-000217 will always resolve to the exact version that ran.
  • The receipt names the version. "Restart print spooler, v4" is in the record, so a question asked six months later has an unambiguous answer.
  • Certification is scoped to a class. Standing authorization is granted to a class of certified runbook, not to the whole library and not to the AI in general.

The questions people ask about runbooks.

So the AI does not write the fix?

For anything in the certified library, no — it selects one and runs it as written. The model's job is choosing correctly and noticing when nothing fits. For a request nothing matches, it does write a plan, and that plan cannot run until a person has read it. The two paths are kept visibly separate on the card.

Can we bring our own scripts?

Yes. The work of turning a script into a runbook is naming the outcome it is meant to produce, the check that proves it, and the rollback. That is not paperwork — it is the part that makes the result verifiable, and it is why a runbook can be run by something other than the person who wrote it.

What stops a runbook doing more than it says?

Two things, and neither is trust. The steps are signed, so a modified runbook does not run. And the privilege it borrows is scoped to one operation on one target for a fixed number of minutes, so even a runbook that tried to reach further would find nothing to reach with — see Just-in-Time Elevation.

How does a runbook get to a machine at all?

Through an authenticated session that was established before the steps existed, using a credential the model never received. The runbook's steps run inside that session and carry no credential of their own — Credential Vault draws that boundary in full.

Where does the runbook show up afterwards?

In the operation record, by name and version, alongside what the target machine answered when it was asked whether the outcome had been reached. Outcome Receipts shows the whole artifact.

Bring us something that breaks a lot

Watch a runbook go from draft to certified.

Fifteen minutes: we take a fix you already have, give it an outcome, a verification and a rollback, and run it end to end.

Book a demoSee the delivery board
← PreviousDelivery BoardSupport, maintenance and projects in view Next →Outcome ReceiptsActions and verification in one record