Deliverables & the Maker → Checker → Approver Workflow
How a deliverable goes from “built” to “approved” through three different people, on evidence.
What a deliverable is
A deliverable is a tangible artifact the project produces, with its own acceptance criteria. Add one via New deliverable at /new/deliverable, and browse existing ones at /browse/deliverables. The acceptance criteria are the yardstick the checker and approver measure the work against, so write them clearly.
The three roles
Three different people share responsibility for getting a deliverable approved. No one person can do all three jobs.
| Role | What they do | Constraint |
|---|---|---|
| Maker | Submits the evidence that the deliverable is done. | None — |
| Checker | Records a pass or fail against the acceptance criteria. | Must differ from the maker. |
| Approver | Approves or rejects the deliverable. | Must differ from the maker and the checker; can only approve after a passing check. |
The flow, step by step
- The maker submits evidence that the deliverable meets its acceptance criteria.
- A sign-off is requested via New sign-off at
/new/signoff. - The checker reviews the evidence and records a pass or a fail.
- The approver opens the decision page at
/approvals/<id>, reads the evidence package, and approves or rejects with a required rationale.
Approve is locked until the checker passes
The approver cannot approve a deliverable until the checker has recorded a pass. This is enforced by the server, not merely hidden in the interface — a failed or missing check can still be rejected or sent back, but it can never be approved. AI agents may read the evidence package, but they can never grant the approval themselves (rule G-004); a human must make the call.
See also
- Approving with evidence — the evidence package in detail
- The phase-gate lifecycle
- Getting started