# What counts as evidence that AI work is done?

By ayobamih

Canonical: https://aiworkaccountability.com/writing/checking-ai-work/
Published: 2026-10-22
Updated: 2026-10-22

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](/work/pi-stripe-crash-lab/) is one concrete example of a failed process and a successful external action coexisting.


An author-proposed method, drafted with AI assistance. The examples are illustrative.