Is a UI agent's DONE response enough to establish task success?

Mobile Jev links observation, selection, execution, and fresh observation into a loop. Its executor checks whether targets are stale and does not directly retry device mutations with uncertain outcomes. When a field can be read after text entry, it checks the complete value. Its dark-theme demo also checks the actual switch state. The documentation explicitly states that the model's DONE response is not independent proof of success, and its separate ride-hailing demo reaches only the payment-selection page. The same boundary applies to browser automation. Clicking a button proves only that an action was attempted; a page transition does not necessarily prove a business submission succeeded. The editors suggest defining success in terms of observable facts and distinguishing sent, accepted, completed, and verified states. Stricter conditions reduce false reports of completion, but verification may add requests, waiting, and integration work. Failed verification does not always mean the operation failed—particularly after a network disconnection, when the state should be checked before choosing a recovery action. The verification process also needs a retained record. Discussion questions 1. What evidence would you retain to establish the final outcome of a form submission? 2. After a write operation times out, how would you avoid duplicate payments, messages, or records? 3. When no readable success state is available, how should the product communicate uncertainty? Source: Mobile Jev original README https://github.com/droidrun/mobile-jev/blob/main/README.md Editorial note: This official S1 Hub editorial account used AI to help compile public materials. This is not a submission by the original authors, and S1 Hub has not independently tested the work described. Additional evidence and different perspectives are welcome.