Our FR5 spacer handover ends at the first unexpected empty pocket

Tray identity is visible on the tray, Steven; pocket names on screen don't match the physical row labels yet. Lucy, yes, I'm asking them to define the responses. My original sheet effectively sent every decision back to me.

We had a handover with a very reassuring contact number, which was my own phone. The cover tutor could find it perfectly and still couldn't run the lesson without me. We replaced that with named roles and a deputy, then watched her find the right person for an uncertain part instead of calling the person who happened to write the page.

Fiona, did you use a real interruption for that exercise, or just ask her where she'd look?

A prepared example from a retained interruption, with its part and displayed state identified. She had to follow the handover, not recall the answer from our conversation. Her first attempt found a contact who wasn't covering that shift, which was exactly the sort of missing detail we needed to catch.

Use the actual empty-pocket and interrupted examples for an early paper walkthrough with the operator, then verify the agreed behaviour against the installed job; a beautifully explained page may otherwise describe a response the program does not support.

Lead and integrator have separated expected empty pockets, unexpected missing spacers and uncertain interrupted transfers. The draft gives each a reason and responsible role. They are also aligning the screen's pocket names with the tray, not asking the operator to translate column numbers in their head.

Who takes the unexpected missing spacer question, Mei?

Keep that distinct from an unconfirmed placement after interruption, since the programmer may know the source pocket was empty without knowing where a different pending spacer ended up.

Shift lead owns the missing-spacer check; unresolved transfer goes to the maintainer with quality owning the part disposition. Linda, there's now an identified hold location and record, so the physical spacer doesn't become a loose bit while the software question gets attention.

Have the covering operator point out the named pocket on the actual tray. Reading the same words on two sheets won't expose a reversed row.

First walkthrough found exactly that row-orientation problem on the drawing. It's corrected against the physical tray. The operator found the three responsible roles unaided, but we are repeating the tray-identification case before accepting the handover.

Did the revised drawing make sense from the operator's usual position, not only from where the demonstrator stands?

Yes, repeat done from the normal position with the covering operator. They identified tray and pocket, distinguished planned empties from unexpected ones, and followed the agreed hold route for the interrupted example. Integrator checked the matching installed behaviour. Handover accepted; thanks, Steven, the physical pointing check caught something my tidy page missed.

Useful result. Keep those three examples with the handover checks so the next wording change doesn't compress them back into check tray