Our UR5e bush-loading plan has two incompatible ready events

Machine side expects receipt to be recognised immediately. Integrator expects to wait for availability. Neither disputes the other event; they have put the same name on both.

Have both authors draw that one case with separate receipt and availability states, including who sets and clears each. Ask what lets the requesting side know its request was received. Agreement on a word does not establish agreement on the exchange.

Our screen once showed a lit request button and people read it as someone accepting the job. No one was being daft; it looked like confirmation. I'd want the operator's view beside the sequence, so the two events aren't separated in the developers' heads and merged again on the panel.

Who handles a request that gets no receipt, Sara? I would put that case on the review sheet rather than let it become the operator's unanswered phone call later.

I'd read a green ready lamp as permission to continue. Worth catching on paper first.

Could the authors walk a delayed receipt and a received-but-unavailable example using only the proposed operator page, without explaining the missing steps aloud as they go?

Does that page actually say waiting for receipt or waiting for space?

I don't want every internal state on the main page, but those two waits deserve different words. Otherwise the person covering the job will call the same person for two different problems and get bounced between teams.

Stepping back from a walkthrough made ours look much less finished. I kept supplying the missing sentence without noticing. Linda's paper test is worth doing with somebody who hasn't sat through all the interface meetings, even if the authors do the technical cases first.

What survives a restart on either side?

Joint sequence now separates receipt, availability and completion, with ownership and clearing stated. No-receipt handling and each side's restart are included. Controls owns the unresolved-request decision with the shift lead; the operator page distinguishes the two waits without listing every internal signal.

Did the covering operator understand those two waits without prompting, Sara? I'd be interested whether their next question was about what the state meant or who to contact.

They distinguished the waits but could not find the contact for missing receipt. We added that ownership beside the message and repeated the walkthrough. It now gives them an answer without a developer standing nearby.

Both teams have signed the revised sequence and operator explanation. Implementation and its verification are the next work package; this agreement covers the ordinary job interface, with the engineered safety functions handled separately. The contradictory ready definition is retired.