The machine team annotated its trace and confirms ready means request queued, not preparation complete; I've put that beside the robot transition which currently assumes access is available

That trace makes the mismatch visible, thank you; ask them to name receipt and preparation completion separately, with the ordinary sequence interface kept distinct from the safety-related permission requirements.

Who owns a request that is accepted but never finishes preparing? That isn't a rare philosophical edge case. Somebody will have to explain the timeout to the operator and decide what recovery is permitted.

Include that stalled-preparation example in the same review, since a normal successful trace won't settle who detects the wait or who clears the outstanding request.

Both teams are reviewing the normal trace and a preparation timeout now; the machine team says it can expose a separate completion condition, but the reset and interruption behaviour is still being agreed

Who removes the completion condition after a transfer, and before the next request?

Have they actually agreed a new interface, or only agreed that another signal is possible? Those are different milestones. The operator recovery instructions depend on the finished transition definitions.

I read the update as an available option, not a completed agreement; the clearing question above needs an answer before the normal trace itself is fully defined.

Option only, yes; I've marked the interface draft unresolved and removed the robot transition based on request queued from the approved proposal, pending the joint definition and review