Map the promised action.
Write down what the workflow tells a patient or staff member. Then identify the artifact that supports that exact statement. Agree where evidence comes from before treating a conversational summary as an acceptance record. The outcome guide explains why reported milestones need precise meanings.
| Question or milestone | Evidence to discuss | Suggested owner |
|---|---|---|
| The requester may make this change. | The applicable permission rule and how it applies to this action. Authority evidence. | Security and access-policy owner |
| The request was received. | A request record with enough context to locate the intended work. | Integration |
| The appointment change was committed. | The authoritative appointment record or audit event for the intended milestone. | Application and integration owners |
| The person was informed. | The communication record for the promised notification, with its delivery limitations. | Patient access |
| The outcome remains uncertain. | A reconciliation process and an accepting owner for unresolved work. Ownership evidence. | Operations |
| This evidence covers the intended release. | Configuration version, relevant results and explicit scope exclusions. Acceptance questions. | Release owner |
This table is a proposed review aid. The records and responsibilities depend on the agreed workflow; no particular product has been inspected here.
A fictional appointment-change example.
A fictional assistant says, “Your request to change the appointment has been received.” The team can locate a request record, but it has not yet established a completed appointment change. The request-received milestone may be supported; the later milestone still needs its own evidence.
Ask the application owner which record confirms completion, the operations owner who handles unresolved requests, and the patient-access owner what the person should be told while waiting. Do not upgrade the recorded milestone simply because the conversation sounds complete. This example is authored for explanation and is not a test result.
Name the owners.
Before the decision meeting, ask each owner to bring the artifact, its current version and its limitations. Discuss what a reviewer can actually see and correct; the oversight guide provides questions for that discussion.
- Security: which action and requester does the permission rule cover?
- Integration: which record supports each reported milestone?
- Operations: who accepts work when the outcome is unclear?
- Release owner: what changed since the evidence was collected?
Keep the conclusion within the evidence.
A self-reported checklist records the team's answers. It does not replace the artifacts or an independent assessment. The existing cancellation-authority lab is a separate executed synthetic example; it does not establish the behavior of your scheduler. The appointment-change example above is fictional.
Use the assessment description to understand the scope and deliverables of a separate engagement. Acceptance remains a decision for the accountable organization.
Updated 12 September 2026: added a milestone-to-evidence table, a fictional example and questions for implementation owners.