A button that says "approve" gets clicked. A question gets read. That difference decides whether your human check is real oversight or just theatre.
The approve-button problem
Module 1 covered this: when something is right most of the time, people stop checking. Approval buttons are where it lands.
After forty correct shortlists, the forty-first gets the same two-second glance. That is the one with the mistake in it.
Design against it by asking for something that cannot be answered without looking:
| Weak | Strong |
|---|---|
| "Approve this shortlist" | "Which two of these ten would you drop?" |
| "Confirm sending 12 messages" | "Which message needs rewriting?" |
| "Review flagged candidates" | "Three of these were flagged for the same reason. Which one is different?" |
The strong versions cost about thirty seconds more, and they are the entire value of having a person involved.
Where to put the check
Before anything that cannot be undone or that a candidate will see. Everything else can run unattended.
| Can be undone — no check needed | Cannot be undone — check first |
|---|---|
| Reading CVs, scoring, tagging | Sending any message to a candidate |
| Drafting a message | Putting a meeting in a candidate's calendar |
| Suggesting a shortlist | Recording a rejection |
| Adding an internal note | Moving a stage in a way that triggers other automation |
| Ranking | Anything written to a system you do not control |
In a screening-to-booking workflow, that means one check: after the shortlist is proposed and the invitations are drafted, before anything leaves the building. One check that people actually engage with beats four they click through.
Catching failures that do not look like failures
The dangerous problems do not produce errors. The automation runs, finishes, and does the wrong thing — or does nothing while reporting success.
- Watch results, not errors. How many candidates got booked today? A zero on a Tuesday is a signal no error message will give you.
- Check the numbers add up. Candidates in should equal candidates scored plus candidates skipped, with reasons. If they do not, something is being dropped.
- Run a known test case daily through the live system, with a result you can predict.
- Alert on nothing happening. "No runs completed in 24 hours" catches the most common failure — the trigger itself stopped firing — and the hardest one to notice.
Records you can reconstruct from
When someone asks in four months why a candidate was handled a particular way, you need: what went in, which version of the AI and the instructions were used, what it decided and why, what it did, who approved it and when, and what happened.
The two people forget are the versions — and they are the two that make a record make sense. Without them you can see what happened but not why, because the thing that produced it no longer exists in the same form.
The test for a check
Could someone approve it correctly without reading the content? If yes, it is not a check. It is a delay with a button on it.