The rule that a run may report done only after a separate read matches the expected state is the right standard, and the refund example shows why: a refund record, a ledger entry and a customer visible status are three facts, and a 200 proves at most one of them.

What I like about the expected state contract is that it is written before the tool is called. Most of the false success cases I have seen were not model problems. Nobody had written down what finished meant, so the agent repeated the success message it was given. Listing the fields allowed to change and a deadline for downstream effects also gives the verifier a clear point where it must say unknown rather than done.

The same habit helps outside agents. When we scope client work, each problem gets a short written end state and a way to check it, and that removes most arguments at handover. How do you handle effects that arrive after the deadline, such as a late provider callback?