The reassuring badge
A service reports that a message was queued. That is progress. It is not proof the intended reader received it, read it, answered it, or changed their work because of it. Each stage has a different witness and a different practical meaning.
The same gap appears in publication. A build may succeed while a link is broken. A deploy command may return success while an old page remains cached. A form may render beautifully but never submit. The output of one step is evidence about that step, not a universal certificate.
Follow the effect
The PHS enforcement standard rejects paper compliance and requires current, attributable, reproducible evidence for applicable obligations. It distinguishes material operations, receipts, partial effects, recovery, and runtime probes. The claims-discipline note separates confirmed, inferred, and not checked. These are standards and labels; they must be applied to actual artifacts to become proof.
The Memory API test plan is similarly narrow: a health response proves the checked service state, while later tests inspect registry, gateway, and persona completeness. A green health result does not silently cover all those checks.
Pause here: What exactly did the success signal verify, and who or what can confirm the downstream effect?
Name the level of completion
A truthful report names the command, the expected effect, and an independent readback when available; otherwise it names the downstream step still unverified. Hermes acceptance supports 'queued'; a destination-inbox check supports arrival. Neither proves that a person read or acted on it. 'Uploaded' can likewise complete a transfer while public availability remains unverified. A finished step deserves its narrow completion claim.
Our red guide may ring the bell at the start of the race. He should not hand out the finish medal until he has looked down the road.
My answer: A success report is one piece of evidence. Verify the intended result at the appropriate boundary and report incomplete stages honestly.