Stage — a phase of delivery. CC, OC, handover.
Set — a named grouping inside one stage. Fire, hydraulic, structural.
Condition — the individual requirement evidence is collected against.
Every condition belongs to exactly one set, and every set to exactly one stage. Nothing sits in two places.
What each level does
| Stage | Set | Condition | |
|---|---|---|---|
| What it is | A phase of the project. | A grouping of related conditions. | One requirement to satisfy. |
| Carries a due date? | No | No | Yes |
| Carries an owner? | No | No | Yes — one, several, or none |
| Collects documents? | No | No | Yes |
| Gets a decision? | No | No | Yes — this is what closes it |
| Shows progress? | Across the whole stage. | A bar on the set header. | Its own statuses. |
| What a contributor sees | Not really — they see their work. | Their work is grouped by set. | Only the ones assigned to them. |
Almost everything you actually do happens at the condition level. Stages and sets exist to make a few hundred conditions navigable.
Two things called “stage”
This is the one genuine trap in the structure.
| 1 | The project's current stage — the one phase the project is presently working through. A fact about the project. It's what the project header announces, and what pages default to when they have to pick a stage. |
| 2 | A stage's own status — Pending, Active or Completed, set by hand on the stage itself. A label on the stage. |
These two can disagree, and that's allowed. A stage's status is descriptive only — it gates nothing. Marking a stage Completed does not close its conditions, does not stop evidence arriving against them, and does not move the project on. Conditions in a Completed stage that were never resolved stay open and keep appearing in counts and reminders, exactly as they should.
So if a stage reads Completed but the project still shows open work in it, nothing is broken. Someone marked the phase done while conditions in it were still unresolved. Resolve them — or rule them Not Required — and the numbers agree again.
Where folders come from
On projects created since the 2.0 launch, the checklist owns the folder structure in Files & Evidence. Adding a set or a condition creates the matching folder; you don't build the tree by hand, and Files & Evidence doesn't offer folder-structure controls on those projects.
Older projects work the other way round: they're file-and-folder based, have no Conditions & Checklist, and their folders are managed directly. Both kinds are in active use — if your project has no checklist, that's why, and it isn't a permissions problem.
Renaming has different consequences at different levels. Renaming a condition is cosmetic. Renaming a set or a stage also renames the folder that carries its name — worth knowing before tidying up names mid-project, especially if anyone downloads packages and expects a stable structure.
Finding your way around a large checklist
- Views narrow what's listed: the default shows open work, and there's an all-items view plus one scoped to your own conditions.
- Filters stack on top — owner, status, tags, priority, and the Documentation axis.
- Search matches a condition's title or its code, so if your conditions carry consent numbers, searching the number is the fastest route.
- Tags cut across sets. A discipline that appears in several sets is easier to gather with a tag than by scrolling.