What is goal decomposition?
Goal decomposition is the process of turning a large objective ("launch the course", "close the funding round") into a structured set of smaller pieces, each small enough to estimate and execute, connected by their dependencies. The output of a good decomposition is not a list; it is a hierarchy laid over a planning graph: phases containing tasks, tasks linked by what enables what.
What makes a decomposition good#
Three properties separate a useful decomposition from an impressive-looking one:
| Property | Test |
|---|---|
| Estimable leaves | Each bottom-level piece is small and familiar enough that "how long, roughly, give or take what?" has an answerable shape |
| Explicit dependencies | The pieces declare what blocks what; the order is derivable, not remembered |
| Bounded breadth | No level asks a reader to hold more than about seven siblings in mind at once |
The third property has seventy years of cognitive science behind it: working memory holds roughly seven items (Miller, 1956), so a level with fifteen siblings is unreviewable by construction. Topolog enforces this mechanically: its validator flags any container with more than seven work-bearing children, and the fix is always grouping, never deletion (Miller's law as a lint rule).
Top-down, level by level#
Effective decomposition runs breadth-first. First cut the goal into a handful of phases and decide their dependencies and endings. Only then open each phase into its own handful of pieces, and recurse. Each level is a complete, reviewable statement of the plan at one altitude.
The breadth-first discipline matters for two reasons. It front-loads the highest-value decisions (the shape of the whole) before any detail work, and it produces natural checkpoints: a mistake at level two is caught while it is seven boxes, not after it has become ninety tasks.
This is also exactly how AI-assisted decomposition works in Topolog: the model proposes one Miller-sized level at a time, each level is validated and rendered for review, and ambiguities become questions rather than assumptions (the full pipeline). The bound that keeps levels readable by humans is the same bound that keeps generation steps reliable for models.
When to stop decomposing#
Decompose until the leaves are estimable, then stop. The end state of decomposition is not atoms; it is pieces whose uncertainty you can state honestly (an estimate with a spread). Splitting a well-understood 8-hour task into five 90-minute fragments adds bookkeeping, not knowledge. Splitting a hazy 3-week blob into its real parts adds knowledge, because the haze was hiding structure: usually a dependency, a decision, or a loop.
A practical signal: if you cannot put a defensible range on a piece, it is not a task yet; decompose it once more. If you are inventing distinctions to make pieces smaller, you are done.