The Agent said done. Tests are green, files exist, and the task board shows success. This is the moment when it is easiest to relax. Then you open the product and press the button a real user would press, and the promised result does not appear. A login flow returns success but never reaches the workspace. A video render finishes without audio. An article is reported as published but exists only as an internal record. The problem is not necessarily that the Agent lied. The problem is that we treated signals far away from the user outcome as delivery itself.

Many teams stop at activity evidence. Code changed. A command ran. A log line appeared. A ticket was closed. These facts prove that activity happened, not that the goal was achieved. A parcel leaving a warehouse is not the same as the recipient holding it. Activity evidence matters, but it belongs at the beginning of the evidence chain.

The next layer is technical evidence. Unit tests, type checks, builds, and API responses are essential. They catch defects quickly and protect known behavior. But a test only answers the question encoded in its assertion. A risk that was never expressed does not disappear because the suite is green. Test identities, permissions, networks, and data also differ from the conditions faced by a real user.

The third layer is final-artifact evidence. Users do not receive source code or a test report. They receive a page, video, article, file, message, or completed action. Verification must therefore touch the final artifact. Open a video and check duration, picture, audio, captions, and cover. Open the actual article draft and inspect title, layout, images, and links. A template that parses does not prove the generated script runs. A correct source file does not prove the delivered binary is usable.

The fourth layer is user-action evidence. The decisive question is not what happened inside the system. It is whether a user can move from the starting point to the intended outcome. A login is not complete when an endpoint returns a token. It is complete when the user enters the correct workspace and can continue. An upload is not complete when storage accepts bytes. It is complete when the user can see, open, and use the file. Publishing is not complete when a job enters a queue. It is complete when the target channel contains an identifiable result.

The fifth layer is known-risk evidence. Every incident reveals a specific weak link. After fixing it, turn that risk into a repeatable acceptance check. If a previous video was silent, inspect the audio stream. If internal production notes leaked into public content, perform a second review from an ordinary reader's perspective. If local and remote revisions diverged, confirm the production runtime and main branch before dispatch. Risk replay is not ceremony. It stops the same failure from returning in a different costume.

One more layer is often ignored: external identity. When an internal database says success but users cannot find the content, we need an identifier from the outside platform: a URL, draft ID, upload ID, or publication receipt. External identity converts a self-reported state into a traceable fact. Without it, published may describe only an internal transition.

Put the layers together and the evidence chain becomes clear. Activity evidence proves work was attempted. Technical evidence proves local behavior met encoded expectations. Artifact evidence proves the deliverable can be used. User-action evidence proves the intended outcome can be reached. Risk evidence proves the known wound did not reopen. External identity proves the result exists in the destination world. No single layer represents the whole truth. Together they make completion durable.

How do you use this in everyday work? Stop writing completion criteria that describe only implementation activity. Replace complete the login API with a new user can sign in, enter the worksp…[truncated 23 chars]