What an Action Ticket Is, and Why a Bank Will Sign Off on One

Four parts, in a fixed order, every time. It is deliberately boring, and the boringness is the entire reason a regulated estate will let it run.

Every Opstral use case ends in the same object, and until now we have described it in a sentence and moved on. It deserves better than a sentence, because it is the thing an operations director is actually being asked to approve, and because most of the disagreement in this category disappears once the object is described precisely enough to argue with.

An Action Ticket is the unit of governed execution. It is a single object containing a pre-check, an executable procedure, a post-check and an armed rollback, produced together, evaluated against a blast radius rule, and recorded in full whether it runs, is held, or is refused.

It is not a workflow engine, it is not a chatbot with shell access, and it is not a confidence threshold with a nice interface. It is the boring, auditable middle layer that has to exist between an agent deciding something and a production system changing.

The four parts, in order

1. Pre-check. Verify that the world is still in the state the diagnosis assumed. The fault is still present, the target is the one identified, no competing change is in flight, the maintenance and freeze windows permit it, and the dependencies are healthy. If any of that fails, nothing executes and the ticket records why. Being straight with you: today this is enforced as configurable safety guardrails on the executing agent rather than as a single named pre-check step with each condition recorded against the ticket. The structured version is the standard we are building to, and we would rather say so here than let you discover it in a security review.
2. Execute. Run the approved procedure, which is a specific set of commands with specific parameters, not a model improvising at a prompt. The procedure is versioned, it was written or certified by your engineers, and every command and its output is captured as it runs.
3. Post-check. Verify that the intended outcome occurred, using a test defined before execution rather than chosen afterwards. Not the process restarted, but the fault condition cleared. In practice this runs as a closure task of independent checks submitted to Sherlock, each carrying its own mechanical criterion, something on the order of p99 under 100ms for two consecutive samples, evaluated against live connectors with no model involved at evaluation time. A policy across those checks decides the verdict, and a failure reopens the incident rather than closing it. This is what separates execution from remediation, and it is why our own dashboards distinguish time-to-execution from verified closure.
4. Rollback. A procedure that cannot be undone is not eligible to run unattended, and actions with no rollback at all appear on the published refusal list rather than in this pipeline. What executes today is automatic rollback on step failure: the agent reverts the steps it completed and escalates with the full execution log. Validating the rollback path before the first step runs, rather than relying on it once a step has failed, is the same build as the structured pre-check above.

The order is fixed and there is no fast path. A procedure that skips the pre-check to save eleven seconds is a procedure that will one day execute against the wrong host during a window it should have respected.

The gate is a property of the action, not the diagnosis

Before any of that runs, the ticket is scored, and the thing being scored is the action rather than the certainty. Three questions, in this order.

• Is it reversible?Can the previous state be restored by a defined procedure, within a bounded time, without data loss. Not in principle. In this estate, with this rollback path.
• How far does it reach?Which services, which customers, which regulatory boundary. Enumerated by name from live topology, not estimated from the CI record.
• Can a machine verify it?Is there a post-check that proves the outcome without a human forming an opinion. If not, the action is not eligible to run alone regardless of how safe it seems.

Three yeses and the ticket may execute unattended, where you have allowed that procedure. Any no and it is held. Held does not mean it stops being useful, which is the point most easily missed, and the subject of the next section.

The full argument for why this gate is the right one, and why gating on model confidence is a category error, is in confidence scores are the wrong gate. The list of actions that never pass the gate under any circumstances is in what we will not automate, and why.

Why a held ticket is the valuable one

The instinct is to treat a hold as a failure to automate. It is closer to the opposite. Compare what a named approver receives at 03:20 in each world.

Without an Action Ticket, they receive an alert and begin an investigation, and they are the bottleneck for everything downstream of it. With one, they receive a decision: here is the fault, here is the evidence, here is the procedure, the pre-check has already passed, these eleven services sit inside the radius, this is the rollback and it has been validated, and you are the approver because you own the payments boundary. The elapsed time between the human waking and the human deciding collapses, because the investigation was already done and only the judgement remains.

That is why the gate makes automation acceptable rather than limiting it. An estate that trusts the hold will permit the unattended path. An estate that has been sold unconditional autonomy permits neither, and runs everything by hand.

What the record has to contain

An Action Ticket that executed correctly and cannot be reconstructed a year later has not met the standard. Every ticket, including the held and refused ones, carries the same fields.

The last row is the one auditors ask about and the one most systems cannot produce. Recording that somebody approved is trivial. Recording what was in front of them at the moment they approved is what makes the approval evidence rather than a signature.

Why a bank signs off on this

Not because the AI is good. A regulated buyer is not evaluating model quality, and treating the conversation as though they are is why most of these deals stall. They are evaluating four properties, and each maps to a part of the object above: the action was bounded and enumerated, the outcome was verified against a test defined in advance, the previous state was recoverable by a validated path, and a named human owned any decision whose consequences reached beyond a machine boundary.

Every one of those is a property of the execution model. None is a property of the model doing the reasoning. That separation is the whole design, and it is why the same architecture is deployable in an air-gapped estate where the model cannot phone home at all.

This pattern runs today across more than 2,000 nodes under governed execution in a Tier-1 enterprise estate in North America, and across more than 27,000 network devices in a Tier-1 telecom estate in India. Those are two different customers, and we try hard not to let their numbers stand next to each other as though they were one. What was measured there, and what was not, is set out in ProcBot day two operations and in how we decide what to publish as a number.