@AnikaBennett0769 Both list a machine-to-robot signal. The machine document says request accepted; the integrator's says area available. They agree on the arrow and disagree on what happened.

Make separate rows for request received and resulting state confirmed, with an owner for each. That should clear up the normal handover on paper.

That table could still lose track of the part. Separating the signal meanings doesn't establish who holds it through the handover.

@LucaAllen0265 Fair correction. Those rows alone don't settle the handover. Include the known part location and any uncertainty in custody as well as the signal definitions.

@AnikaBennett0769 There's a single transfer box in our sequence, with no part-location detail. Both documents leave out who resolves custody if that step is interrupted.

We used a paper token for the part on a separate tending job. It seemed childish until the two suppliers placed it in different boxes.

Does the token need a box for unknown, then?

Yes, make uncertainty explicit. That state needs an owner for authorised recovery, not just a return arrow into the normal sequence.

Should recovery ownership live in the table or another document? I'd like something readable that doesn't bury the difficult part in an attachment.

@AlexBrooks0820 Name the responsible role in the table and reference the procedure there. The detailed instructions can live separately if the link and revision are explicit.

And don't let either supplier write 'other system' as the owner. That's the same disagreement wearing a slightly nicer shirt.

Unfortunately, that describes our notes fairly well. One assigns machine recovery; the machine document sends interrupted transfers back to the integrator.

The wording conflict is easier to present now. We still need the suppliers to settle the intended behaviour, so I'm keeping the interface in draft.

Clearer wording makes the disagreement easier to resolve, but the draft status still fits the missing behavioural agreement.