Task Decomposition: Trees with Evidence

The promised lesson

We've been circling this one since the touch points: choosing where trajectories meet is the decomposition problem, and it was promised its own treatment. Here it is — the multi-conversation archetype where the object of design is not the roles but the task itself: how to break one goal into subtasks that separate conversations can complete, such that the pieces provably come back together.

Break the task into subtasks that are:

  INDEPENDENT   each completable without conversing with the
                others — its brief is enough
  COMPOSABLE    the outputs fit together by design — declared
                interfaces, not hopeful prose
  EVIDENCED     "complete" means evidence, not assertion

Independence buys PARALLELISM and FAILURE ISOLATION.
Composability buys a whole from the parts.
Evidence buys knowing which subtree to distrust.

The tree

Decomposition produces a tree: the goal at the root, subtasks as children, recursively, down to leaves small enough for one clean conversation. The map first:

Two properties of this picture do all the work. Siblings are parallel: A, B, C run as three simultaneous conversations — three walls, three clean trajectories, finished in the time of the slowest, not the sum. And failures stay in their subtree: if A1 goes wrong, the damage is bounded by A — B's and C's conversations never saw A1, so they cannot have been conditioned by its mistakes. The tree is the firebreak diagram, drawn before any conversation starts.

But both properties hold only if the cuts were real — and cuts are real only if the seams were declared:

Evidence of correctness

Now the part that turns decomposition from hopeful management into engineering. Every subtask's definition includes one more field: what evidence will show it is actually done? Not "the conversation said so" — every trajectory believes in its own work. Evidence, and it comes in two strengths:

⟨tool_use⟩
run_command(cmd = "./check_a1.sh samples/")

⟨tool_result⟩
3/3 files: PASS. 4,112 rows, 0 rejects, schema conformant,
timezone/unit checks green.

When composition fails anyway

Independence is a bet — the same bet every cut makes — and the place bets fail is at the joints. So the tree has one more rule: composition is itself a task, with its own evidence. When siblings' deliverables meet, something must check the fit:

⟨tool_use⟩
run_command(cmd = "./check_join.sh")

⟨tool_result⟩
FAIL: map view shows depths 5.5× too large for 12 of 12 test
points. A2 serves meters (per interface). B1 plots values with
label "depth (m)" but axis scaled as if fathoms→meters were
still needed.

1. Cut where the seam is thin — small brief, small
   deliverable, declared interface.
2. Siblings must not need each other's conversations —
   independence is what parallelism and isolation are
   made of.
3. Every subtask closes with EVIDENCE — hard where the
   world can testify, soft (a fresh critic against a
   stated bar) where it can't.
4. Every joint is a task: composition gets its own
   evidence.
5. When a joint fails, evidence localizes the fault —
   reopen the guilty subtree, not the tree.

What "done" means at the root

Climb back to the root and notice what the tree has bought. The root's completion judgment — the coordinator's owned question — is no longer "do I believe all this work?" It is a ledger: every leaf closed with evidence, every joint tested, the root's own end-to-end evidence green. Belief has been replaced by an audit trail. And the deeper reason this matters is one we set out with: for most real tasks there is no ground truth to check against — there is only whether the human accepts the result as correct. Evidence is how a decomposed system earns that acceptance: not "trust us," but "here is the tree, here is each piece's proof, here is the proof they fit."