Give every action a verification step written in advance: a test you can run, a number you can read, or a drill you can repeat. If an action has no way to prove it worked, it is a hope. Verification turns "done" into "working".
The gap between done and working
Teams close tickets when the change merges. But a pinning rule that skips one repository, or a secret scope that still includes a legacy token, is closed and still broken. Incidents repeat in the gaps between the two.
Add a fourth field to every action
Most action lists carry an owner, a due date and a description. Add a fourth: how we will know.
| Action | How we will know |
|---|---|
| Pin third party build steps | A search of all workflow files returns zero unpinned references |
| Hold new package versions for a waiting period | A test dependency published today is not resolved by a fresh build |
| Narrow build secrets | Listing secrets per job shows each job only has what it uses |
| Inventory every build | Pick five past builds and retrieve each inventory within minutes |
| Name a block owner | During a drill, the owner blocks a test package within the agreed time |
| Alert on advisory feed | A test advisory reaches the on call channel |
Three kinds of verification
Test. A direct check of the control, as above. Best for configuration changes.
Metric. A measure over time. For example, the share of repositories covered by the new rule. Good for coverage questions. Be careful that the metric counts what you think it counts.
Drill. A rehearsal of the response. For example, ask "which of our systems use package X?" and time the answer. Best for process and people actions.
Who verifies
Not the person who did the work. A second person or a scheduled automated check avoids marking your own homework. For small teams, swap actions between two people.
Record the result
Write the result in the postmortem: date, method, outcome. If the test fails, reopen the action and note why. A failure at this stage is a success for the process, because it was found before the next incident.
Verify again later
Controls drift, so repeat the check on a schedule. Quarterly is a common rhythm for important controls. Add the check to a recurring task rather than relying on memory.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how each finding carries a status, which is the same idea as a verified action.
Quick check
Who should verify an action?
Someone other than the implementer, or an automated scheduled check.
What if verification fails?
Reopen the action, record why it failed and fix it. Finding the gap now is the purpose of verifying.
Last reviewed: 19 October 2026.
