About Deliverables
A deliverable is a scoped chunk of work inside a project. It is not a task list. It is a graph of sections. The graph decides what is ready next. A person marks the deliverable done when it is delivered.
The sections of a deliverable
A new deliverable is empty. The service makes no section and no task for it. You add the sections.
Add one section for each chunk of work. Give the sections an order. A section can depend on other sections. Those links form a graph. See About Sections.
A deliverable can also start with work in it. When you start a deliverable from the inbox of a deployment, the service makes one section and moves the selected tasks into it. See About Deployments.
Done is a decision
A deliverable is done when a person marks it done. The service does not decide it for you.
The sections show the progress. When every section is done, the work is done. But the deliverable stays open until you mark it done. That keeps "we did the work" distinct from "we delivered it".
You can reopen a done deliverable. Do that when the delivery was not complete, or when you need to add work to it.
There is no closer section and no "Delivered" task. A deliverable that was made before this change had a closer. That closer is now a plain section. If the closer was done, the deliverable is now marked done.
Deliverables and deployments
A deliverable can ship to a deployment. Set the deployment on the deliverable when the work goes to a thing that runs, for example a site or a service.
A deliverable can also come from a deployment. When you start a deliverable from the inbox of a deployment, the deliverable records where it came from.
So a deployment and its deliverables form a loop. Work comes up in the inbox. A new deliverable takes that work. The deliverable ships back to the deployment.
Hidden context
A deliverable has a Context field. You edit it in the edit sheet: "What this is about, for search and suggestions". Write it in Markdown. The page does not show it. Search and the place suggestions read it, so a new task finds this deliverable more easily.
What a deliverable looks like in the rest of the product
The project lists its deliverables. A workspace-wide list shows deliverables across projects.
The map draws each deliverable as a block of sections. You can hide completed work. You can hide blocks that have no cross links. You can mark a few sections as highlights. The map then shows those sections and the work that leads to them.
A deadline can attach to a deliverable or to a section. The date lives on the deadline. The record shows the earliest attached date.
A plan step can link to a deliverable or to a section. The step then follows that record.
Every deliverable has an address. See About Addresses.
Why this structure
A flat task list cannot tell you what is ready. A graph of sections can.
The done mark is yours because delivery is a judgement. The tasks can all be done while the outcome is not yet in the hands of the people it is for.