A dependency is a claim about data, and it has to be paid for

The rule

An edge A → B is legal only if you can name the specific value B reads from A's output.

If you cannot name it, there is no edge. Not "it feels sequential." Not "these are both setup steps." Not "the code reads better that way." Name the value or delete the edge.

The failure this prevents does not announce itself. An over-serialised pipeline returns the correct answer, slowly, and the slowness is indistinguishable from the work being hard. Nobody files a bug against it, so it survives indefinitely and gets worse with every item added.

Three relations that look identical and are not

Nearly every wrongly-serialised system comes from collapsing these into one idea.

Data dependency — real, and it orders. B consumes something A produced. verify(finding) needs finding. This is the only relation that justifies B waiting on A. Test: name the value.

Resource contention — real, but it does not order. A and B both need a thing there is only one of: one browser, one logged-in session, one write lock, one test database. This imposes mutual exclusion, not sequence — A-then-B and B-then-A are equally correct. The right primitive is a lease, not an edge. Modelling contention as a dependency is the most common way this rule breaks, because the observed behaviour is identical (things run one at a time). The difference appears when you add an item: with leases a new item is free; with edges it extends a chain.

Conceptual ordering — not real, and must never order. "Design before build." "Scout before observe." These describe how a person narrates the work, not how values flow. Some survive the test (parse → plan is real, because plan reads the manifest). Most do not. This is where over-declaration comes from, because it is genuinely how people think — and it is still wrong.

The two shapes

The false barrier (orchestration). An await-all between stages blocks every item on the slowest item of the previous stage.

const found   = await parallel(items.map(i => () => find(i)))    // barrier
const checked = await parallel(found.map(f => () => verify(f)))  // barrier

Item 1 finished finding at t=4s; item 6 takes 90s. Item 1's verify starts at t=90 having needed nothing from item 6. Wall-clock becomes sum of slowest-per-stage when it should be slowest single chain. The fix is a pipeline: each item flows through all stages independently.

A barrier is justified only when the next stage genuinely needs the whole previous stage — dedup across the full set, an early-exit on total count, or a prompt referencing "the other findings." Never by "I need to flatten/map/filter first" (do it inside a stage) and never by "the stages are conceptually separate" (that is what a pipeline models).

The over-declared blocker (ledger). Ledgers with a WAITING state meaning blocked by dependencies rot toward serial, because every hand-written edge is a guess and guesses skew conservative: a missing edge looks like a bug, a spurious edge looks like caution. So authors add edges when unsure, leaves sit in WAITING that arrived READY, and nothing flags it because WAITING is a legitimate state.

Same test, applied at the ledger: a WAITING entry must name the upstream output it consumes — not the upstream task, the value. Enforce it as a throw on the transition, not a lint, or this rule becomes the theatre that [[enforce-dont-declare]] describes.

The scars

1. Reported 2026-08-30, and the reason this rule exists. The observation, verbatim in substance: agent A finished its work, agent B is still working, and A is blocked waiting on B when A never needed B's output at all. This is the false barrier, described from the outside by someone watching it happen. What makes it diagnostic rather than merely annoying is that the person watching could see the waste and the system could not — there is no error, no warning, no signal of any kind. The only symptom is elapsed time, which is exactly the symptom that gets attributed to the work being large.

2. Near-miss the same day, caught at design time. A QA reconnaissance system fanned out per checklist item across five test identities sharing one browser. The obvious model — "item under identity C depends on the identity-A items finishing" — is wrong twice over: it is contention, not data flow, and it invents an ordering the constraint does not require. Under that model a section of eight independent items becomes an eight-link chain, and adding a ninth item extends it. Under a lease per identity, the items in a group are fully independent and a ninth is free. The two designs have identical observed behaviour on the first run, which is what makes this class of error survive review.

The check

Which value does the downstream step read from the upstream step's output?

One sentence. If answering it needs the word because or the word should, the edge is conceptual and comes out.