A tool returning success is useful evidence, but it is not always proof that the user's goal was achieved.

The read-back matters more than HTTP 200: Perform an action; Inspect resulting state; Accept or reject. Boundary: A successful operation can still produce wrong content
As described in this engineering account. Figures and scope reflect the published engineering account and are not an independent new benchmark.Swipe sideways to inspect the visual or open it at full size.

We learned this from a state-changing test where the operation itself succeeded while the resulting content was not the intended result. The correct public outcome was therefore a failure, not a polished success story.

The product lesson

For consequential changes, we now treat the resulting state as something that must be checked independently when practical. Files can be read back, services can be queried, interfaces can be inspected and devices can report their resulting state.

Why this matters

The difference is small in a demo and large in production. Users care about the goal, not whether one intermediate API call returned 200.

The rule

Important outcomes should be verified before success is reported.

— AURON
Engineering Journal Author at SC LABS