Received Is Not Done: Five States an AI Workflow Must Keep Separate

An instruction enters a queue. The interface says it was delivered. A worker begins. A human once approved the goal. A tool returns success. The final page loads.

Which of those facts means the work is done?

None of them on its own. They are evidence of different states. When an AI workflow collapses those states into one optimistic word, people can believe an action was authorized when it was only received, believe it happened when it was only attempted, or believe it succeeded because a server responded.

This field note comes from a recurring coordination problem: a delivery record was treated as acknowledgement, activity was treated as progress, and reachability was treated as completion. The precise lesson is simple: every consequential state needs its own evidence.

One word can hide five different facts

“Done” is useful in casual conversation. It is dangerous as a system model.

A person asking an assistant to format a private note may not need a formal trail. The standard changes when the assistant can publish, send, purchase, delete, deploy, modify access, or coordinate other workers. At that point, the human needs to know which transition actually occurred.

Age for AI proposes five states:

1. Received: the request reached the intended queue or system.
2. Acknowledged: a defined worker accepted responsibility for examining it.
3. Authorized: the current human permission, scope, target, and time boundary allow the action.
4. Executed: the tool or operator performed the requested side effect.
5. Verified: evidence shows that the intended result exists and protected areas remain healthy.

Blocked and failed are also valid outcomes. They should not be rewritten as “still working” merely because the desired result has not arrived.

Age for AI interpretation: a state label is a claim. A receipt is the evidence that supports that claim.

The five states and the evidence they require

Received answers: did the request reach the intended place? Useful evidence can be a queue identifier, timestamp, target, or durable intake record. It does not prove that anyone read the request.

Acknowledged answers: did a worker accept this exact task? Useful evidence names the worker, scope, and current state. It does not grant permission to take a consequential action.

Authorized answers: may this action happen now? Evidence should identify the human or role, target, permitted action, constraints, and any expiry or approval boundary. This is where an old instruction can fail even when receipt and acknowledgement are genuine.

Executed answers: did the system perform the side effect? Evidence might include a tool response, transaction identifier, commit, deployment identity, sent-message record, or audit event. It does not prove that the intended human outcome followed.

Verified answers: does the result match the request, and did anything protected break? Verification should inspect expected content or behavior. A web page returning HTTP 200, for example, proves reachability. It does not prove that the correct title, body, image, canonical URL, or unrelated page survived.

Accepted for processing is not completed

This distinction is not unique to AI. HTTP itself contains a useful warning. RFC 9110 defines the 202 Accepted status as a request accepted for processing whose processing has not been completed. It may or may not eventually be acted upon.

That standard concerns HTTP semantics, not human acknowledgement or AI governance. Still, it captures the core operational mistake: an intake response can be truthful without being a completion receipt.

The same caution applies to agent interfaces. “Queued,” “sent to worker,” and “tool call started” can all be accurate. None should silently become “done.” If an interface cannot distinguish them, the human has to reconstruct reality from logs, chat messages, and hope.

A concrete case: publishing a corrected public brief

Imagine an editor asks an AI workflow to publish a corrected public briefing.

1. The request is stored with the article slug and deadline. That proves received .
2. One editorial worker claims the task and reports the exact scope. That proves acknowledged .
3. The editor approves the final text, image rights, target route, and publication window. That proves authorized .
4. The deployment creates the article and activates a new runtime. The deployment receipt proves executed .
5. A public check confirms the full title, H1, canonical URL, body, citations, and image. A separate check confirms the homepage and an unrelated article still render correctly. That proves verified for the defined acceptance criteria.

If the page responds but still shows the previous text, execution may have occurred while verification failed. If the article is perfect but the editor withdrew approval before deployment, authorization failed. If the queue accepted the request but no worker claimed it, only receipt exists.

The workflow becomes trustworthy by naming the failed state precisely, not by protecting the appearance of momentum.

Build a small proof-of-state ledger

NIST's AI Risk Management Framework calls for defined and documented human oversight, ongoing monitoring, periodic review, and clear organizational roles and responsibilities. Its Playbook suggests maintaining histories and audit logs, clarifying delegated authority, assigning accountability, and documenting who will maintain, re-verify, monitor, and update an AI system.

Those recommendations do not mandate this five-state model. They support the underlying direction: consequential AI work needs visible responsibility and reviewable evidence.

A compact ledger can record:

1. task identifier and requested outcome;
2. current state and the time it changed;
3. worker responsible for the next transition;
4. human authority, scope, target, and expiry;
5. evidence reference for execution;
6. acceptance checks and protected canaries;
7. blocked or failed reason;
8. rollback or recovery path when the action is reversible.

The ledger does not need to expose private reasoning or raw conversation history. It should preserve the minimum evidence another authorized person needs to understand what was requested, what happened, and what remains unproven.

Traces help, but they do not prove the human outcome

OpenTelemetry describes a trace as the path a request takes through an application. Spans can show units of work, timing, relationships, events, and status. That makes tracing useful execution evidence in a distributed system.

A trace still has a boundary. It can show that a publish request moved through an API and storage service. It cannot, by itself, prove that the public article contains the correct claims, that the intended reader can reach it, or that another page was not damaged. Those are acceptance questions outside the trace's technical path.

OWASP's guidance on excessive agency adds the authorization boundary. It recommends limiting agent functionality and permissions, requiring human approval for high-impact actions, and enforcing authorization in downstream systems rather than asking the language model alone to decide what is allowed.

Together, these sources point to two complementary controls: trace what the system did, and independently govern what it was allowed to do.

Use a practical completion protocol

For consequential AI-assisted work, a human or team can use this short protocol:

1. Name the current state. Do not report “in progress” when the truthful state is received, blocked, or awaiting approval.
2. Attach one state-specific receipt. A queue ID supports receipt; a named worker supports acknowledgement; an approval record supports authorization; a tool record supports execution; an acceptance check supports verification.
3. Do not skip authorization because execution is easy. Tool access is capability, not consent.
4. Verify content or behavior, not only transport. Check the expected title, amount, recipient, file, record, or user-visible outcome.
5. Check one protected canary. Confirm that an unrelated area expected to remain stable is still healthy.
6. Return failure honestly. A precise blocker protects the next decision better than an optimistic status.

This protocol is deliberately small. The goal is not to turn every assistant interaction into bureaucracy. It is to stop one ambiguous status word from carrying more certainty than the evidence supports.

What remains unknown

No five-state model can define the right evidence threshold for every action. A reversible change to a private draft needs less proof than a payment, medical decision, access change, public statement, or production deployment.

A receipt can also be incomplete or misleading. Logs may be missing. Timestamps may disagree. A worker can acknowledge the wrong scope. A human can approve without understanding the evidence. Verification can test the wrong outcome. The model improves clarity; it does not remove judgment.

This article does not claim that current AI products share a universal state model, maintain durable authorization records, or can independently prove real-world completion. Those capabilities must be demonstrated in the system being used.

The five-state model and completion protocol are Age for AI's practical proposal, derived from an abstracted coordination lesson. RFC 9110 supplies the technical distinction between accepted and completed processing. NIST supplies voluntary governance guidance. OpenTelemetry documents technical traces. OWASP supplies security guidance on agent authority. None of these sources proves that a specific AI product implements this model or guarantees a successful outcome.

Completion is a claim that deserves evidence

A trustworthy AI workflow does not need to sound certain. It needs to make the current state visible and show the receipt that belongs to it.

Received is not acknowledged. Acknowledged is not authorized. Authorized is not executed. Executed is not verified.

That separation gives humans something more useful than confidence: a clear place to inspect, intervene, approve, stop, or ask what is still missing.

For the time boundary on authorization, read When an AI Instruction Expires . For knowledge boundaries, continue with A Personal AI's First Rule: Never Pretend to Know . For evidence before operational action, see A Root-Cause Hypothesis Is Not Evidence .

Sources and evidence boundary

1. RFC 9110, Section 15.3.3: 202 Accepted. Used for the distinction between acceptance for processing and completed processing.
2. NIST AI Risk Management Framework Core. Used for documented human oversight, ongoing monitoring, periodic review, and defined roles and responsibilities.
3. NIST AI RMF Playbook: Measure. Used for suggested histories, audit logs, delegated authorities, accountability, and re-verification.
4. OWASP, LLM06:2025 Excessive Agency. Used for guidance on limiting functionality and permissions, human approval, and downstream authorization.
5. OpenTelemetry, Traces. Used for the definition of a trace as a request path and for the role of spans as technical execution evidence.

No source-owned image is reused. The five-state flow and proof matrix are original Age for AI visual concepts.