Playbooks

A playbook turns a known fix into pre-approved response. Engineers write and publish it; responders then execute it from a guided incident page without waiting for an approver each time. This is the standard-change model: the approval is spent once, at publish.

Body and envelope

A playbook has two parts, and only one of them is the safety boundary.

The body is freeform natural language — the procedure as you would write it for a colleague, interpreted by AI at execution time. Prose is deliberate: a rigid step grammar is brittle exactly when reality deviates from the script, expensive to author, and one release away from becoming a workflow language that needs code review.

The envelope is what binds:

Envelope field	What it constrains
Allowed operations	An explicit subset of the governed action catalogue — T1 and T2 only; T3 can never be desk-executable.
Target scope	Targets derive from the pinned incident’s entity, never from the prose.
Run bounds	Maximum actions, wall-clock time, and token budget.
Validation	Deterministic predicates over evidence queries — field, operator, literal.
Escalation	What happens when anything fails: stop and summarise.

The worst case of any run is therefore allowed operations × bound targets, within bounds — enumerable at publish time regardless of what the prose says. That is precisely what makes pre-approval reviewable: a publisher signs off on a bounded envelope, not on trusting a paragraph of English.

Publishing

An engineer authors a playbook; a second engineer, who is not the sole author, publishes it as desk-executable. Both acts are audited. This is where separation of duties lives for playbooks — moved from execution time to publish time.

At execution, an in-envelope change auto-approves with provenance recorded: which playbook, which publisher, published when. Guards re-check at execution time, so retracting or demoting a playbook stops its approvals instantly, and protected targets apply unchanged. Anything outside an envelope falls back to ordinary per-change approval.

Validation never self-certifies

Whether the fix worked is decided by the runner, evaluating the envelope’s predicates against fresh evidence queries — not by the AI asserting that it worked. Where a judgement genuinely is required, the AI proposes a verdict with cited evidence and the responder confirms it.

Execution

A playbook run is a recorded, semi-supervised agent run: tools cut to the envelope at the tool layer, streamed live to the responder watching it, with the full transcript kept as the audit artefact. Failure halts and escalates — it never improvises past a failed check, and it never rolls back on its own, because a rollback is itself a new change.

The transcript is a replayable narrative, not a replayable execution; interpretation is non-deterministic and that is priced in deliberately.

The responder role

Playbooks introduce a rung on the role ladder: viewer < responder < operator < approver < admin. A responder can view everything, run published playbooks on matched incidents, resolve afterwards, and record notes — and nothing else. The guided incident page is that role’s entire surface.

Efficacy keeps them honest

Desk executions feed efficacy scoring. A playbook whose success ratio decays below threshold is automatically demoted from desk-executable (audited) until an engineer reviews and re-publishes it. Standing pre-approval is governed by a track record rather than by how convincing the playbook looked when it was written.

One format, two readers

The same body and envelope are executed by ISE’s in-app runner for the desk and read by engineers investigating through the Claude/MCP surface. Hardening a playbook for desk use is an engineer tightening the words and adding an envelope — never translating advice into a program.

Next

• Actions & approvals — the tier model an envelope draws from.
• Roles & access — the full role ladder.
• The core loop — where playbooks shorten it.