Checklists That Catch What a Second Reviewer Misses

A falsifiable checklist line has four parts: a question, a named artifact, an expected answer, and a consequence. Here is the pattern.

Q: Does the change set a lock_timeout before every DDL statement?
Evidence: grep for "SET lock_timeout" and "SET LOCAL lock_timeout" in the migration file.
Pass: at least one value, in the migration, before the first ALTER.
Fail: missing, or set only in the database's global config.
Assignee: author.

Compare that with "Is the migration safe?" That line cannot fail, so it does not catch anything. The evidence requirement is what converts a review into an audit.

This matters because the failure modes are real. A DDL statement acquiring a lock in PostgreSQL queues behind any long-running transaction holding a conflicting lock, and every statement arriving afterwards queues behind the DDL, even statements that would otherwise be compatible (Xata). A one-millisecond ALTER TABLE can therefore turn an idle transaction into a full outage (Medium). A reviewer reading the diff sees a small, correct change. Only a checklist line that asks for the lock_timeout setting catches the defect.

The same pattern works outside databases. Hatchworks' agent security checklist anchors its items to identity, least privilege and monitoring, each answerable by pointing at a registry entry, a scope list or a log (Hatchworks). Viktor's buyer checklist goes further and attaches a pass test to every question, such as an action log an administrator can open (Viktor). Copy that habit into every line.

The sign-off matrix works when each line belongs to exactly one role. Two people answering the same question produces two shallow answers and one gap.

The author's lines are mechanical. They can be answered by the person who wrote the change, and they should be answered before the pull request is opened, the way The Turing Way puts local test runs and CI status on the coder's list (The Turing Way).

The agent operator's lines exist because an agent does not have an author's sense of consequence. An agent will retry a failed step, call a tool it was not told to avoid, or run up charges if a credential leaks. Keeping retries off destructive calls and verifying the tool allowlist are operator questions, not author questions.

The second reviewer's lines are the ones that actually need fresh eyes. Keep them to five or fewer. Each one should be unanswerable by reading the diff alone.

The second reviewer's job is intent, blast radius and rollback. Everything else has been handled upstream, or should have been.

Intent. Does the change do what the ticket says, and nothing else? Ask for the ticket number and a one-line summary of the intended outcome, then ask whether any hunk in the diff serves a purpose not described in that summary. This catches scope creep and stray debugging code that the author's own review will not.

Blast radius. For database changes, the reviewer should name the lock each statement takes and how long it is held. Most ALTER TABLE forms take an ACCESS EXCLUSIVE lock, and the dangerous ones hold it for the duration of a full table rewrite (DBGorilla). The reviewer does not need to know the answer from memory; they need to make the author produce the table row that says it. For an index build, the answer is CREATE INDEX CONCURRENTLY, which does not block writes but leaves an invalid index behind if it fails (Citus Data).

Rollback. Not "can this be reverted" but "what is the command, and how long does it take." A rollback that requires another exclusive lock on the same table is a second outage waiting to happen. Petcona's online schema change tool warns explicitly that all database tools carry risk and that you should test on a non-production server and verify backups before running it (Percona). A checklist line that demands the rehearsal output turns that warning into a gate.

For MySQL shops the reviewer should also confirm the chosen strategy, since Vitess recommends its managed, online schema changes over unmanaged ones (Vitess). The reviewer's question is not which tool is better; it is whether the chosen tool was actually used for this table.

Take the most recent release that caused an incident, and walk the checklist backwards. For every line, ask whether the answer at the time would have been a fail. If the truthful answer was "pass," the line is decorative and should be rewritten or deleted.

Work a worked example. Suppose an incident occurred because a migration added a column with a volatile default, which rewrote a large table under an exclusive lock during peak traffic. The rewrite held the lock for the whole operation (DBGorilla). Replay the template:

Three of four lines would have blocked the release. The second line, as written, would not, because it only flags for review. That line should be rewritten to demand the answer to a follow-up: is the default constant or volatile, and if volatile, is the table under a size threshold that makes the rewrite acceptable? A checklist improves by this loop, one line at a time.

Run the exercise on a second incident to test whether the template generalizes or whether it has been overfitted to the first. If the second pass produces only decorative lines, the template needs a new category, not more lines.

Most teams now have a third role in the review, even if they have not named it: the person who runs the agent that wrote or executed part of the change. That role needs its own short list, because an agent's failure modes do not appear in a code diff.

The operator's lines should cover identity, scope and evidence. Every agent should have a unique ID and a named owner (Hatchworks). The tools it called on this task should be on an allowlist, and the log should show it. Anything irreversible, such as sending an email or deploying to production, should have a named approver, and the operator should be able to show that the approval happened before the action (Viktor).

Then there is the question of whether the agent's work can be reconstructed. If you cannot open the action log for a given run and read the steps in order, the operator cannot sign off on the change. That line is testable, and it fails loudly.

Where the operator needs a way to reproduce what an agent did, a single interface across model types helps. Quanta Inference puts text, image, video, audio and embedding models behind one API key, so the operator can replay a run against the same model family with the same credentials, rather than chasing five provider dashboards.

A checklist that never changes is a checklist nobody reads. Give it a maintenance rule: any incident adds at most one line, and any line that has passed without a fail for a full quarter is a candidate for removal. Roussy's advice to do a first pass for context and a second pass against the list only works if the list is short enough that a second pass is realistic (Marc Roussy).

The review practice literature is consistent about this. Catalina Turlea's review notes treat repetition and small improvements as recurring, concrete flags rather than open questions (Catalina Turlea). That is the register a good checklist should be in: specific, checkable, and boring.

When the template needs to spread across a team, the first step is usually a shared library of the checks themselves, so an agent can run the mechanical lines and leave the judgment lines to the reviewer. Quanta Skills is the skill library for that job; you can install a skill into a coding agent or put an expert on the line of business.