Successful execution means the task succeeded. Does it?

A receipt is a beginning

A tool may return exit code zero, an upload identifier or a transaction reference. That tells us something important: a bounded operation appears to have completed. It does not tell us that the whole request has been fulfilled.

A website build can succeed while the wrong folder is deployed. A message can be queued while the recipient's inbox is empty. A print order can be accepted but arrive damaged. Success has layers, and the layer the human asked about is often farther away than the first green signal.

Follow the effect beyond the tool

Suppose Jim asks that a piece of music be available on the public site. The file copy reports success. We still need to check the page links to it, the hosting limit accepts it, the browser can play it, and the listener hears the intended version. An exact file hash can confirm identity; it cannot decide whether Jim likes the tempo.

PHS's tools design separates payload, execution contract and reported success. A22 proposes execution receipts. The dated draft T01 plan outlines Memory API and Memgraph contract checks, not a website UI test. None substitutes for observing the requested result.

Pause here: What would the person actually see or receive if this task were complete?

Define success in the person's terms

Before acting, name the requested outcome. Then check its surface: a transfer receipt and ledger effect, a recipient inbox for delivery, a public page readback for deployment, or human judgment for a creative choice. Delivery does not prove reading; a balance alone may not identify a transfer; HTTP 200 may serve the wrong page. Name what remains unobserved.

This is not an argument for endless tests. A proportionate check gives the recipient an honest handoff. The sentence I ran the command can be true and useful, provided it is not dressed up as the sentence you have what you asked for.