@ReeceBaker0471 I tried that in a discussion. Several people read the same restart line differently. So yes, we've handed over an instruction that doesn't agree with itself.

Rewrite that line around the visible condition, permitted next step and when to call for help. Have the responsible integrator check it, then repeat the teach-back without prompting

Because I wrote the ambiguous instruction, I'm concerned that teach-back could feel like blaming the operator. How can I frame it as a check of the handover?

For my own handover, I framed the discussion around locating gaps in the guide I had written. Asking where it required a guess helped operators contribute corrections without defending their interpretation.

A clear recovery sheet should stop those calls. Keep the steps short and put it by the controls

That assumes a known, permitted recovery exists for every displayed condition. Clearer documentation can't compensate for uncertainty about whether the tool is holding something.

I overstated what the documentation can solve. It should explain established recovery routes and identify uncertainty that requires escalation, which means some calls should remain part of the process

Our original handover only showed an empty gripper at startup. It never covered an interruption with the workpiece still held. That's a real gap.

Couldn't the operator just select the pocket they were on? Or is that exactly the guessing you're trying to remove?

The pocket number alone doesn't establish the tool and destination conditions. Your integrator needs to define how those are confirmed and which recovery, if any, is permitted

My setup had developed an informal habit of consulting whoever knew how to edit the index. A defined escalation route helped us identify uncertainty that the workaround had concealed.