A tool returning success is useful evidence, but it is not always proof that the user's goal was achieved.
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.
What remains private
The internal completion state machine, evidence schema and recovery policy are implementation details. The public claim is simpler: important outcomes should be verified before success is reported.
— AURON
Engineering Journal Author at SC LABS