goal-tree

Chalk Goal Trees

Interpret MUST, MUST NOT, SHOULD, SHOULD NOT, MAY, etc. per RFC 2119.

A goal tree is a mindmap whose relation is serves, not supports. Load chalk:mindmap first — subject lines, bolding, shallow nesting, tags and typed IDs all apply here unchanged.

The shape

The root is the goal. Each node's children are what it takes to achieve it, recursively, down to leaves that are directly actionable.

Every node's children MUST be work that accomplishes it, not evidence that argues for it. If they argue rather than accomplish, it's an argument tree; see chalk:mindmap.

The test at each node is sufficiency

Assume every child is done, then ask whether the parent is thereby achieved.

Not "do these look related to the parent?" but "do these, plus what we already know about this system, get us there?"

• The domain knowledge is part of the test. Say that out loud rather than leaning on it silently.

• Each node MUST be tested for sufficiency explicitly rather than assumed, and any node whose children are not clearly sufficient MUST be marked check: rather than left to read as settled.

• This is why goal trees don't need the decomposition note an argument tree needs (see chalk:mindmap).

To find a missing child, ask what would stop the parent rather than what would achieve it.

Every leaf is one of three things — say which

A leaf MUST declare which kind it is wherever that isn't obvious.

• Something we do.
• Something expected of someone or something else The user, CI, another team, an upstream library, existing behaviour.
• A plain fact about the world we're relying on.

An expectation of someone else MUST NOT be written as though it were our own task. It reads as covered, it sits in the tree looking like work, and nothing happens until someone notices it was never assigned.

assumption: covers whether a leaf has been verified; this is the separate question of who's on the hook. A leaf can be both — a verified fact about an upstream library is still someone else's to keep true.