# The plan is a graph

> When you ask a model for a plan, it usually comes back as a flat list of about ten items, in no order that matters, with no gate between them, and with a…

Page: Methodology · Plan
Canonical: https://banes-lab.com/disciplined-methodology/plan#the-flat-checklist

This section is stop 22 of 102 in the learning route. Previous: [12 - Worth before work](https://banes-lab.com/disciplined-methodology/plan/worth-before-work.md). Next: [14 - Execute the template](https://banes-lab.com/disciplined-methodology/plan/execute-the-template.md). It builds on [01 - The loop](https://banes-lab.com/disciplined-methodology/start/the-loop.md).

When you ask a model for a plan, it usually comes back as a flat list of about ten items, in no order that matters, with no gate between them, and with a checkbox after each one that the model ticks itself. In this method a plan is a [directed acyclic graph](https://banes-lab.com/records/arch/directed-acyclic-graph.md) instead. Its phases pass evidence to each other, its tasks carry contracts, and a finished task is deleted rather than ticked, as [B1·a list against graph](https://banes-lab.com/disciplined-methodology/plan#the-flat-checklist-panel-a) shows. The architecture page claims that [a system is a graph](https://banes-lab.com/software-architecture/model/a-system-is-a-graph.md), and this section applies the same claim to the work done on the code.

### The list that ticks itself

A task turned straight into a flat checklist has no order and no gates, so the ticks on it say nothing about whether the work is done. Item four depends on item seven, but the model works through them in list order, and the plan reaches the end with three items quietly left undone. A flat list is the cheapest structure to write and the cheapest to tick, which is why the model and the developer both reach for it.

For this reason I treat a plan as a set of phases with gates between them, not as a list of tasks. A plan with no dependency order and no gates is sent back rather than started. In practice, the phases are ordered by what depends on what, and within that by what has to exist before something else can be built on it. A gate between two phases names the evidence the next phase reads before it starts. Every task has a contract with four parts: the file it touches, the evidence that proves it, the verifier that reads that evidence, and the thing it deliberately leaves alone. Severity decides which handler a failure goes to, and never the order of the list.

To check this, ask what each phase needs from the one before it. A phase that needs nothing from its predecessor is either in the wrong place or in the wrong plan. Priority and sprint are labels on a phase. They help decide where attention goes, but they never become the plan's structure, because a plan ordered by urgency hides its dependencies.

The two orderings in that practice are dependency and genesis, applied in that sequence. Under dependency, a phase comes after every phase whose output it reads. Genesis is the order in which things come into being: a thing exists, it is told apart from other things, it is related to them, it is structured, it is transformed, and it is constrained. A phase should never depend on something that comes later in that order than what it produces. A plan that builds a transformation on a structure that does not exist yet is inverted, and that is a fault in the decomposition, not a tie to settle.

[Impact analysis](https://banes-lab.com/records/arch/impact-analysis.md) records names, never counts. A row saying three files are affected gives the reader nothing to act on, while the three file names do. When a dimension has no impact, the row records the evidence that it was checked and found empty, because a blank cell looks the same whether it was checked or skipped, and only the checked one is safe. Every task has a unique id, and every mention of an id has to point to a task that exists, so a dependency note cannot keep pointing at a deleted task while still looking current.

The plan holds what is true now and what is left to do, and nothing else. It holds no findings about defects already fixed, no account of how the plan came about, no inventory of what already exists, and no finished task kept in place with a note. A finished task is deleted, which keeps the remaining tasks equal to the remaining work, and past work left on a checklist invites doing it a second time. The [planning templates](https://banes-lab.com/pag/templates/templates-planning.md) on the grammar page are built in stages and trimmed by deletion for the same reason. A count written into the plan is written state that goes stale, as [derived state](https://banes-lab.com/disciplined-methodology/verify/derived-state.md) explains.

B1·a list against graph

```mermaid
flowchart TB
subgraph flat["The flat list"]
direction TB
f1["item, in the order it came to mind"] --> f2["item"] --> f3["item"] --> f4["item"]
f4 --> ticked["done when every box is ticked"]
end
subgraph graph["The graph"]
direction TB
p1["phase 1"] -- gate: the evidence phase 2 reads --> p2["phase 2"]
p1 -- gate --> p3["phase 3"]
p2 -- gate --> p4["phase 4"]
p3 -- gate --> p4
p4 --> objective["done when the objective sentence reads true against the tree"]
end
```

## Links to

- [Directed Acyclic Graph (DAG)](https://banes-lab.com/records/arch/directed-acyclic-graph.md)
- [A system is a graph](https://banes-lab.com/software-architecture/model/a-system-is-a-graph.md)
- [Impact Analysis](https://banes-lab.com/records/arch/impact-analysis.md)
- [Planning templates](https://banes-lab.com/pag/templates/templates-planning.md)
- [Derived state](https://banes-lab.com/disciplined-methodology/verify/derived-state.md)

## Linked from

- [Orchestration as declared structure](https://banes-lab.com/pag/orchestration/declared-structure.md)
- [The loop](https://banes-lab.com/disciplined-methodology/start/the-loop.md)
- [Execute the template](https://banes-lab.com/disciplined-methodology/plan/execute-the-template.md)