Separate four different events
| Event | Question it answers |
|---|---|
| Demonstration | Did a stated workflow run against an identified environment and input? |
| Acceptance | Did an authorised buyer determine whether the agreed evidence meets the contract's condition? |
| Handover | Can the named owner access and operate the assets and knowledge that are meant to transfer? |
| Exception | What is still absent, disputed, risky, or due after the milestone? |
The UK government's Digital, Data and Technology Playbook recommends planning for activities, milestones, resources, roles, risks, dependencies, and digital, data, and knowledge assets. It is public-sector guidance, not a universal acceptance rule. Its useful lesson is that a payment milestone should not erase the work required to make a system operable.
Build one dated evidence packet
Use the evidence packet's acceptance worksheet to collect scope, workflow evidence, known defects, environments, access, exports, operating instructions, recovery boundaries, recurring charges, specialist questions, acceptance authority, and remaining obligations.
Every row needs a source, buyer owner, supplier owner, and state. “Included in handover” is not evidence. A missing row is an unresolved item, not a reason to assume zero work.
Demonstrate the exact agreed workflow
Define the workflow before the demonstration: input, role, environment, and expected result or failure. Retain a link to evidence, not merely a verbal confirmation. Do not turn a happy path into evidence for every integration, permission, scale condition, recovery path, or future release.
Name the acceptance and resolution owners
The person attending a demo may not be authorised to accept a commercial milestone. Name the acceptance role from the agreement and separately identify who can resolve an account, product, or handover issue. If authority is ambiguous, pause the conclusion; software cannot resolve it.
Treat exceptions as first-class evidence
For each exception, record what is missing, the consequence, the owner and target date, whether it blocks acceptance under the actual agreement, and the evidence required to close it. Do not quietly move exceptions into future support without making the owner, payment, and outcome visible.
Do a small dry run
Before using the packet for a real payment, complete its procedure on one non-sensitive test workflow. Leave a sample handover item unresolved and verify that it stays visible to the authorised buyer. The dry run checks record keeping, not the live system or a payment obligation.
Acceptance rule
A final-payment decision is ready for human review when the buyer can inspect the scope, actual evidence, asset and access boundary, remaining risks, and authorised path. Bring commercial, legal, security, and privacy advisers into the decision where the agreement or system requires them.