Topics / Engineering practice
A software checklist should show the work behind the tick.
A useful checklist names the work, the evidence that completes it and what happens when that evidence changes. Start with one repeatable engineering process.
Make completion inspectable.
“Tests reviewed” leaves the next engineer guessing. Which tests, which revision, and what was decided? Give each step an owner or authorized actor, a completion rule and a link to the resulting record. Separate an action completed from a result accepted.
Order matters when later work depends on an earlier decision. Recovering a requirement is different from approving it; running a test is different from resolving its failure. A skipped step should retain its reason instead of looking completed.
Turn an authorization checklist into evidence.
Illustrative example
A tenant export adds a background worker.
The endpoint checks the requesting administrator, but the new worker performs the export later. The checklist must follow tenant identity through the queued job and resulting download, rather than stop when the endpoint returns an authorization status.
| Step | Evidence to retain | Completion rule |
|---|---|---|
| Agree on the access rule | Approved actor, tenant and export permissions | The responsible owner resolves job execution and download permissions |
| Check each access boundary | Results for own-tenant, foreign-tenant and missing-identity requests, jobs and downloads | The planned scenarios ran on the candidate revision |
| Inspect consequential effects | Export contents and observations of data access for denied cases | The results support the agreed tenant boundary, not only an HTTP status |
| Resolve remaining gaps | Named findings, exceptions and review decision | No unresolved blocker under the applicable policy |
These are proposed checklist items, not a built-in Proof release policy. If the worker or download path changes later, revisit the evidence for that boundary. A prior endpoint check cannot stand in for an untested background operation.
Start with a checklist you can reuse
Use one record per step. Keep the test outcome separate from the decision: a passing check may still leave a requirement unresolved.
Download the plain-text template, or select and copy it here. This worksheet works with your existing tools.
Change and candidate revision:
Behavior that must change:
Behavior that must stay the same:
Step and owner:
Inputs and prerequisites:
Check to run or decision to make:
Expected result:
Observed result and evidence link:
Requirement and code revisions checked:
Execution: not run / passed / failed / skipped
Decision: pending / accepted / rejected / waived
Reason and authority for any skip or exception:
What would require this step to be checked again:For the export worker, name the tenant identity carried by the queued job, the forbidden cross-tenant request and the observed data access. Revisit those results when the worker or access rule changes.
Use Proof to retain the process state.
Proof’s named checklists record ordered steps and their dependencies. The CLI shows the current state and eligible work. Checking a checklist re-runs configured verification commands for confirmed steps by default; it does not invent verification for a step with no such command.
proof checklist list
proof checklist show onboard_v1
proof checklist check onboard_v1Confirm a step after doing its work and retaining its evidence. Use a reasoned skip when appropriate, or reset a step when its basis no longer holds. A recorded confirmation alone is an attestation, not proof of behavior. Your CI and approval policy decide which incomplete steps block delivery.
Try it on your software
Bring one checklist your team actually uses.
We can identify which ticks need evidence, which decisions need an owner, and what the next engineer should inherit.