Home/Verified AI Operations/The Operation Loop
The operation loop
One request. One connected operation.
Support, maintenance and project work use the same governed loop when they run through Seraph. This page walks it end to end — what enters each step, what comes out, and how the operation records a stop or a target-confirmed result.
The loop, expanded
Every step exists because a claim depends on it.
Read the right-hand column first. It is the honest reason each step is there: drop the step, and one of the sentences we sell stops being true. That is the whole design rule.
Step by step
What actually happens, in the order it happens.
Nine minutes of wall-clock time for OP-000217. Here is every one of them.
-
Qualify — a typed outcome, not a request
Dana writes one sentence in Teams. Seraph reads it, works out which machine it is about, and turns it into an outcome that can be checked later: printing works at the NW-Medical front desk. Then it selects a certified runbook that reaches that outcome. It does not write a script for your production server — it picks a fix that has already been tested and certified. If nothing fits, it plans, shows you the plan, and asks.
-
Approve — policy, and a human's say-so
Policy decides what is even eligible: this runbook class, this customer, this target, this time of day. Then a person decides. Marcus sees the card on his board with everything he needs to judge it — who asked, what will run, on what, for how long, and how it comes back if it goes wrong — and authorizes with one click. His name and the moment he clicked are attached to this operation, and no other.
-
Lease — scoped, and it auto-revokes
Only now does any privilege exist. Seraph asks the broker for admin rights bound to two things at once: this operation and this target. The justification is recorded with the grant. The rights expire on the clock — not when the job finishes, not when someone remembers. There is no shared admin account behind this and never has been.
-
Run blind — the AI never sees a password
The connection to SRV-ACCT-02 is authenticated before any generated instruction exists. The model works with a credential reference; the executor resolves it to a value on the other side of a boundary the model cannot reach. So there is no moment where a password could be logged, echoed into a prompt, or captured in a trace — because it was never delivered to the thing doing the reasoning.
The claim this figure exists to settle: the model is never given the credential, so there is no moment at which it could leak one. What crosses the boundary is a signed job and a reference; what never crosses is a value. -
Prove — the fixed machine confirms
This is the step the rest of the industry does not have. Seraph does not mark the work done. It asks SRV-ACCT-02 a fresh question and records the machine's own answer: service running, queue clear. That answer — not our summary of it — is what lands in the receipt. If the check cannot run, the row says so instead of going quiet.
-
Seal — a locked record, one ID
Every event above is assembled by the platform into one record under one reference: OP-000217. It carries the fingerprint of the record before it, so altering it later puts every subsequent record out of agreement. Dana gets told she is fixed. Marcus's board goes green. Priya's export picks it up on Friday. Same object, three audiences.
Same operation, three experiences
Dana's version is four messages. The machine's version is a lease, a job and an answer.
The loop is not something your users should have to see. Here is OP-000217 across all three lanes with time running left to right — and the thing worth staring at is the empty middle of the top lane.
The half nobody demos
A failed operation still completes. And it still signs.
Any platform can show you a green run. The question that decides whether evidence is worth anything is what the system does on the bad day — and the answer has to be the same six steps, ending in the same record.
- Failure is an outcome, not an absence. The operation reaches an end state, gets a receipt, and gets sealed. It is not left half-written or quietly retried until something works.
- The lease still expires on its own. Privilege does not linger because a job stalled. The clock is the clock.
- The declared undo is already there. It was written before execution, so it exists even when the step that would have needed it never ran.
- It stops and hands to a person. A certified runbook that cannot reach its outcome does not escalate its own permissions or improvise a second approach. It stops safely and puts a named human back in the loop.
We would rather show you this than a highlight reel. A receipt that only exists for successes is advertising. The reason we can be relaxed about publishing failure records is that they are the ones that prove the record is not curated.
“No response captured”
This is a real recorded outcome, and it is the one that matters most. When the verification check cannot reach the target — the machine is off, the network dropped, the service never answered — the receipt says exactly that.
It does not say “completed”. It does not silently inherit the AI's opinion of its own work. An unanswered check and a successful check must never look the same in a record you are going to forward.
The plan changed mid-flight
Sometimes the first approach is wrong and the right move is to change course. That change is not a silent retry — it is its own recorded event: what was being attempted, what was observed, what is being attempted instead, and who or what policy allowed the pivot.
The revised work then rejoins the same operation and lands in the same receipt. You get one record that narrates the wrong turn as well as the fix, because a record that hides the wrong turn is the one nobody should trust.
It stopped safely, and said so
A stop is a designed state, not a crash. The lease is allowed to expire, the target is left in a state the runbook declared, and the operation is handed to a named technician with everything already assembled for them.
Marcus picks it up under his own fresh lease and continues inside the same operation. There is no second ticket, no second record, and no gap between what the AI did and what the human did next.
The refusals
Five things the loop will not do, at any speed.
These are not settings. Turning any of them off would make the receipt a nicer-looking log line, which is the artifact we exist to replace.
- No standing privilege. Neither the AI nor the platform holds admin rights at rest. Privilege is minted for an operation and dies on a clock.
- No credential to the model. Not masked, not redacted, not “only in memory”. The value is resolved on the far side of a boundary the model cannot address.
- No self-reported success. If the target did not answer, the operation does not claim it worked — no matter how confident the model is.
- No undeclared rollback. The undo is written before execution or the operation does not start. Reversal invented afterwards is not reversal.
- No unnamed authorization. Every operation traces to a person — for a step, for the operation, for a runbook class, or for the policy it ran under.
Honest scope: the loop applies to certified runbooks first, and the certified library grows every release. When a request has no certified fix, Seraph plans it, shows you the plan, and asks — it does not improvise privileged work on your production estate to look faster.
The questions people ask after reading this page.
What happens if no certified runbook fits the problem?
It plans. Seraph builds an execution plan, shows it to you as a sequence you can read before anything runs, and asks for authorization. It does not write a script and run it on your production server because nothing better was available. The plan is where a new runbook usually comes from — you run it once with a human on each step, and if it holds up it goes through certification. How runbooks get certified →
Can my technician take over while an operation is running?
Yes, at any moment, with one click. Taking the wheel mints a fresh lease under the technician's own identity — it does not hand them the AI's privilege and it does not start a second operation. The work continues in the same operation and lands in the same receipt, with both leases recorded. Commanded autonomy →
Does the AI decide what it is allowed to do?
No. Policy decides what is eligible and a person decides whether it proceeds. The model's job is to work out which certified fix reaches the typed outcome and to carry it out under privilege someone else granted. It cannot widen its own scope, extend its own lease, or authorize its own work.
Is a patch or a remote session a different process?
Same six steps. A patch wave is the loop applied per machine with gates between rings, and a governed remote session is the loop with a human doing the work under a lease. The evidence shape does not change, which is the point — you should not have to learn three formats to answer one auditor. See patch waves and governed sessions.
How do I know the receipt reflects what really happened?
Because the parts of it that matter are not written by the thing you are asked to trust. The authorization comes from your identity system, the lease comes from the privilege broker, and the confirmation row can only ever carry what the target machine answered. The model contributes no field to the confirmation. Then the record is chained, so editing it after the fact puts every later record out of agreement. Outcome receipts →
What does the end user have to learn?
Nothing. Dana asked in the channel she already uses and got told when it was done. There is no portal to log into, no ticket form, and no session she has to accept. Watch the three minutes →
Fifteen minutes, one operation, end to end
Pick a step you don't believe, and make us run it in front of you.
A live ticket, resolved. Then we open the record, show you the machine's own answer, and roll it back on the call.