The shape
Client onboarding — Riverside Fit-Out 9 of 14 done ▓▓▓▓▓▓░░░
─────────────────────────────────────────────────────────────────────
✓ Signed contract received Dana · 12 Aug
✓ Insurance certificate on file Priya · 14 Aug
✓ Purchase order raised Dana · 15 Aug
○ Site induction booked ops · due Fri ← outstanding, owned
○ Access codes issued ops
⊘ Parking permit n/a — no vehicles on site
─────────────────────────────────────────────────────────────────────
↑ not-applicable, with a reason
The properties that matter:
- A template, so the same items exist on every record and can be compared across records.
- An owner per item, because unowned items are the ones that sit.
- Attribution on completion. Who and when, or the tick means nothing.
- A not-applicable state with a reason. Without it, people tick things that did not happen — which is the moment the checklist stops being true.
- A rolled-up fraction on the collection view.
Why it is a different topology
A linear workflow answers where is this. A checklist answers what is still outstanding. Those are different questions and they need different data: one current stage versus a set of independent completions.
Trying to express a checklist as stages produces the familiar mess — statuses like "Partially onboarded" that mean different things to different people, and a spreadsheet on the side where the real state lives.
The not-applicable state earns its keep
This is the item most designs omit and the one that decides whether the checklist stays honest. With only done and not-done, a record that legitimately does not need item seven can never be complete — so somebody eventually ticks it. Once one item is ticked untruthfully, no item can be trusted, and the checklist has become decoration.
A third state, with a required reason, keeps the record both complete and true.
Getting it wrong
- Items with no owner, which are exactly the items that never get done.
- No not-applicable state, which trains people to tick untruthfully.
- No attribution, so nobody can ask a follow-up question about a tick.
- A template nobody can change, so ad-hoc reality gets recorded in email instead.
- Progress hidden inside the record, so nobody can see which of forty clients is stalled without opening forty records.
- A checklist used as a gate without saying so — if items block progress, that is a stage-gated workflow and it must be explicit.
Exemplars
Aviation and surgical checklists are the origin, and the transferable lesson is that the value came from making the list the same every time, not from the individual items. Consistency is what turned it into a safety system.
Mortgage and loan onboarding software is the clearest commercial example: dozens of independent documents and checks, several owners, and a completion fraction that drives the whole business's reporting.
GitHub pull request checks show the roll-up done well — many independent results, one summary state, and the failing ones surfaced without opening anything.
The extractable rule: a checklist is a template plus attribution. Without the template you cannot compare records; without attribution you cannot trust the ticks.