What does it take for Stop to actually stop?

A Stop acknowledgment says the request was accepted. It does not, by itself, establish that the task was running or that it ended.

For our simulated cube-to-tray task, we needed to observe progress, cancel that same run, check that its worker ceased, and recover the result afterward.

First find a run that is still running

Earlier attempts had already finished or offered too short an observed window. We did not send the conditional Stop in the short-window case. Those checks demonstrated execution, but left interruption unanswered. The iPhone Reach checks had the same problem: completion came before observation of a live Stop control.

The connected-Mac check used the existing nominal cube controller, without adding delay to make cancellation easier. Its first run succeeded. Only after its evidence was intact and its worker had ceased did the second run start.

Follow one identity through the whole chain

Check on the second run	Observed result
Establish progress	Retained progress was observed at 0.1 simulated seconds.
Address that active run	Stop used its original request key and was accepted.
Establish the outcome	The same run finalized as aborted at 100 control steps and 0.2 simulated seconds.
Establish cessation and recovery	Both workers ceased. Reopening the host recovered the original keys, details and byte-identical run files.

Each observation rules out a weaker explanation. Progress shows the task had begun. The terminal result and cessation go beyond acknowledgment. Recovery shows the account survived beyond live memory. The first run's files were also unchanged after the second.

The script recorded about 0.055 seconds from its first positive progress observation to preparing a summary after cessation and reading the terminal file. That is not Stop-request-to-cessation latency or a response-time guarantee.

This was one scripted software-interruption check in simulation. It did not establish a human tap window, portable-device stopping performance or physical emergency stopping. For interface builders, the useful pattern is the chain of observations tied to the same run, with a result that remains inspectable after it ends.