Detect, decide, name a human, write it back
Four fields. That is the runbook.
- Detect. Which signal, and from where. Here it is
error_rateon the nightly harness batch — the same loop you built in lesson 01, now missing its threshold. - Decide. Rollback if the signal is at or above the line. Continue if it is under. No third mood called "wait and see" unless the runbook wrote that mood down as continue.
- Named human. A seat, not a channel.
release-owneris a person who can unblock a rollback. "The team" is not a page target. - Writeback. A path in the repo. The decision becomes
a line in
incidents/log.jsonlso the next checkout can see what ran. Slack is not the record.
Run the editor. Three quiet incidents, one rule.
| id | error_rate | rollback_blocked | decision |
|---|---|---|---|
| INC-041 | 0.12 | no | rollback |
| INC-042 | 0.03 | no | continue |
| INC-043 | 0.15 | yes | escalate |
INC-043 is the only one that names a human. The signal
says rollback, but rollback cannot run (last-good tag
missing, lock held, whatever the runbook marked as
blocked). The junior does not invent a workaround. They
page release-owner and write that down.
Why rollback is the point
Continue is allowed. It is just not the default once the signal crosses the line. The expensive mistake at 3am is shipping past a threshold because the wiki said "use your judgment." Judgment is what you do when the runbook has no rule. If the rule exists, you execute it.
Escalate is not a vibe. It is the branch where the written action cannot run, so a named human has to.
What the next steps drill
- Predicting the three decisions from the table (step 4)
- Filling the threshold comparison from the runbook (step 5)
- Replacing a wiki string with the four fields (step 6)
- Replacing "the team" with the named human (step 7)
- Writing
execute_runbookso the writeback record falls out of the decision (step 8) - Running three incidents through it (step 9)