A completion message is a useful starting point. To review the work, I also want a record that connects the original request to what happened at its destination.
This is the short template I would use for a bounded engineering or automation task. It is a proposed method rather than a validated universal standard.
1. Write the acceptance condition#
Describe the observable result before executing. “Add a contact form” leaves room for ambiguity. “A visitor can submit an enquiry, the intended destination receives it, and failures show a useful message” gives the reviewer something to inspect.
2. Identify the action#
Record the repository, deployment, document or external operation. Keep a stable identifier so an interrupted attempt can be distinguished from a new one. Note the version or commit where it matters.
3. Inspect the destination#
A successful command can establish that a request was accepted. It may not establish the business result. Check the deployed page, saved document or provider record that the action was supposed to affect.
For example, a publishing workflow should retain both its submission response and a link or readback of the destination post. That example is illustrative; each provider's guarantees need their own investigation.
4. State what was checked#
Keep checks narrow enough to assess. A screenshot supports what was visible in that view. A passing test supports the scenario and assertions it exercised. An archive hash supports byte integrity. None automatically establishes every other property of the system.
| Field | What to record |
|---|---|
| Request | The intended result and authorised scope |
| Action | What ran, where, and its operation or version identifier |
| Observation | What was found at the destination |
| Evidence | A usable link, result or artefact |
| Gaps | Unchecked conditions and uncertain outcomes |
| Owner | Who reviews the result and handles the unresolved parts |
5. Preserve uncertainty#
If a response was lost, record that uncertainty before retrying an external action. If a check failed, preserve the output and explain its implications. A truthful partial result is more useful than a completion label that hides the next decision.
The Pi/Stripe experiment is one concrete example of a failed process and a successful external action coexisting.