Approval queues, kill switches, and escalation

An approval queue is where a dry run's proposals wait. Each item names its target, the exact change, the evidence behind it and the risk — the same four fields, every time, so approving is a scan rather than an investigation.

Queue design is about the reviewer's attention, and it fails in two directions. Too much detail per item and nobody reads it. Too many items and it becomes a rubber stamp — which is worse than having no gate, because now there's a signature on work nobody examined. If your queue is consistently long, the workflow is proposing too much, and that's the thing to fix.

A kill switch stops new work immediately: one documented way to halt the workflow and prevent queued writes. A flag file the run checks, a disabled schedule, a revoked credential — the mechanism matters less than that it's one action, documented, and rehearsed. An untested kill switch is a belief about your system, and you'll be testing it for the first time during the incident it exists for.

An escalation path handles what the workflow can't decide: ambiguity, a policy conflict, the third consecutive failure. Route it to a named person with a compact packet — what it was doing, what happened, what it needs — and one answerable question. "Something went wrong, please advise" is not escalation, it's abandonment with extra steps.

Loading your workspace…