Chapters
- 01 · Choose the Level of Automation
- 02 · Respect Permissions, Consent, and Ownership
- 03 · Preview Before Changing Important Data
- 04 · Decide Where People Approve
- 05 · Add Volume, Spend, and Time Limits
- 06 · Plan for Stop, Undo, and Recovery
- 07 · Test Unsafe Requests
- 08 · Capstone: Approve a Safe Automation Plan
15 min · Interactive exercise
Capstone: Approve a Safe Automation Plan
Run four unsafe requests through the whole plan, validate it, and approve version 1.0.
A control plan is only as strong as the section somebody skipped, and none of these seven has yet been read next to the others. This chapter finds out whether they agree, and whether any of them actually stops anything.
Three parts. First, four unsafe requests go through the assembled plan, one from each category in Chapter 7. Each is built to get through a plan that skipped a section. The renewal case is worth watching most closely, because nothing about that request is wrong: the person qualifies, they consent, the match is right, and the plan refuses it anyway.
Second, twelve validation checks run by stable ID. They test the seams. Does any action sit above the ceiling its blast radius allows? Does every forbidden state bind to an action that is actually in the plan? Do a transient and a permanent failure share a destination, which would mean the taxonomy is decorative? Each one needs two sections in view at once, which is why none of them surfaced while you were writing either.
Third, approval, gated on every check passing.
What the plan is not
It does not make the workflow safe. No plan does that, and a plan that claims to is the more dangerous artifact, because it ends the conversation.
What it does is attach every control to a specific thing that would otherwise go wrong. That changes the argument you are able to have. “Are we being careful enough” has no answer and never terminates. “Is an active renewal window the right forbidden state for cadence enrolment” has an answer, somebody can be wrong about it, and the wrongness shows up in a written list rather than in a customer's inbox.
GTM Lab
Saved locallyWorkflow Control Plan
sample-workflow-control-plan · v1 · draft
Run four unsafe requests
One from each category. Each is built to get through a plan that skipped a section, which is the only way to find out whether a section is doing anything.
- Correct by every rule, and unacceptableCorrect and unacceptable
The forbidden-state list. This is the only category where the system has to refuse something it believes in, which is why it is the one most likely to be missing. - A segment far larger than the capAt volume
The limits. Things that are safe individually stop being safe when the rate changes, and a dropped record is indistinguishable from one that had nothing to enrich. - The provider fails halfway throughPartial success
The state display. The question is not whether the failure was handled but what the system reports afterwards. - A cleanup routine with a defectThe repair is the hazard
The preview. A cleanup loop with a defect does not fail quietly, it amplifies, because each run acts on the state the last one left.
Run all 12 validation checks
The checks test the seams between sections, since every section was written while looking only at that section. Each runs by its stable ID and reports pass or fail with a reason.