Automation

Operating model

An incident or lifecycle event is evaluated by ordered rules. A matching rule selects an immutable published playbook version. Safe enrichment and condition steps can advance automatically. A destructive action step cannot execute unless an approval step has produced a response-action receipt that matches the intended action and the approver holds the required scopes.

Authors can set autonomy posture (observe / assist / guarded / autonomous), but guarded operation with approval gates remains the default enterprise path for high-impact work. Continuous overnight hunting and quiet-period proof of work are documented under Hunt Ledger — not here.

Views in the workbench

Overview summarizes recent runs and domain coverage of published playbooks and rules. Playbooks is where you create, clone, edit steps, validate, and publish new versions. Rules bind triggers, conditions, cooldown, and pinned playbook versions; you can test rules against evaluation incidents without starting production runs. Runs shows step timelines, status, and operate actions (retry, cancel, rollback) where permitted. Approvals lists runs waiting on human decision. Templates install reviewed starting points. Documentation inside the product describes the step catalogue and governance notes.

Step types and run modes

Playbooks compose: trigger, enrich, condition, branch, task, approval, action, verify, wait, notify, sub_playbook, rollback, and end. Validation checks dependency order and ensures destructive actions sit behind approval gates.

Runs execute in live (real side effects after approval), dry_run (exercise logic without external changes), or shadow (record decisions without applying them). Choose dry_run or shadow when validating a new playbook against real incident shapes.

Permissions

Authoring, publishing, running, approving, cancelling, retrying, and rolling back are separate automation permissions. Approving a playbook gate also requires response:approve and the action scope for the underlying response action. Reading the workbench requires automation:read.

Empty and evaluation states

Live tenants with no playbooks see an empty state directing them to templates or create playbook — not synthetic substitution. Evaluation mode loads local demo playbooks/runs explicitly labeled synthetic.