Received means the system recognized input; produced means a result exists

What it is

Acknowledgement versus completion distinguishes two facts: received means the system recognized and accepted an input; produced means processing occurred and the expected result now exists. A pressed state, queue entry, or local form save can acknowledge receipt. A delivered message, downloadable file, or data visible in its destination is completion. They may nearly coincide for a tiny synchronous action, but networking, queuing, computation, review, and cross-device synchronization require separate expression.

Why it happens

An asynchronous chain has multiple stages that can fail or delay. Input reaching a client, reaching a server, validation, execution, committing a result, and making it visible are not equivalent. An undifferentiated “success” makes users interpret any early stage as final; acknowledgement alone leaves them unsure whether they must wait. Distinct stages establish agency early while reserving outcome claims for a verifiable moment, preventing duplicate submission and bad decisions.

Studying it

Compare ambiguous success, explicit received, pending, and completed states on the same task. Measure stage judgment, repeated action, waiting strategy, error discovery, and trust. Insert rejection, network interruption, delayed completion, and cross-device delay; happy paths are inadequate. Ask concrete questions—can you close the page, can another person see the result, where will failure appear—to establish whether people distinguish the states.

Where it stops holding

Brief, reversible tasks with results at the action point need not expose redundant stages. Conversely, consequential or irreversible work must not use receipt as a substitute for verifiable completion even when the backend is fast. Some external systems cannot guarantee final completion; say “handed to the service” rather than imply delivery. More stages are not automatically better: retain those that change user decisions.

Applying it

• Define received, processing, completed, failed, and cancelled semantics for asynchronous flows, with real technical evidence for each.
• Make acknowledgement fast, light, and near the action; use completion language only when result can be checked, with a route to check it.
• Explain what continues after leaving, when notification occurs, and where cross-device work can be tracked.
• In fault-injection tests, ask users what they can do now. “I thought it was done” and “I do not know whether to wait” are evidence of state conflation.

Related

• Within the group: D1.11.2 Conflation makes slow work look complete · D1.11.3 Receipt should be faster and simpler · D1.11.4 Long tasks need an intervening state
• Adjacent: D1.01 Immediate operation feedback · D1.16 Verifiability of results
• Search terms: input acknowledgement · completion feedback · asynchronous operation