The only labelled state is inspection busy. The screenshot already shows the selected fixture name. Nothing explains where it came from.

Get the program dependencies as well as the screen explanation. The fixture name could come from a setup routine or retained configuration, and neither is visible in a picture of the main routine.

Liam, a named shortcut. Integrator supplied the dependency list: an initialisation routine selects a fixture configuration before the main routine. That routine is absent from our handover export.

Does that initialisation routine contain the configuration, or read it from another file? Worth asking before they send one missing routine and call the folder complete.

And is the selection retained between starts? I'm asking because the screenshot might show yesterday's choice rather than what that shortcut selected.

Alex, a separate configuration file. Nina, the selected name is retained, but initialisation validates it against that file. Both were missing from the supplied inventory's attachments.

What happens on a start with no retained selection?

Have the author explain that state. Do not turn the visible name in the screenshot into a default setting to fill the gap; the installed validation logic needs to remain part of this handover.

This is where our old bench notes fell over. The writer had used the same fixture for months and thought its name was just part of the screen. We rebuilt the PC and suddenly the first page of the notes described a state we couldn't reach. Nothing exotic had failed. A setup file had lived outside the backed-up folder, and only one person knew it existed. Robin's dependency list is worth finishing before anyone pretties up the pictures.

Matching initialisation routine and configuration file supplied, with their revisions. Author confirms no retained selection leads to a selection-required state. That case is now included in the handover.

Can someone unfamiliar follow it from that state?

Give them the ordinary empty-fixture and uncertain-coupon cases too. A clean start is only one place the screen can leave someone wondering what it wants.

The draft walkthrough exposed another gap. The covering technician could select the fixture but could not tell whether a retained pending coupon meant uninspected or outcome unknown.

Who can resolve the unknown outcome? The instruction should name that responsibility alongside what the operator sees, rather than asking them to infer it from the pending label.

Nina, your awkward-case suggestion earned its place. Robin, keep those two meanings separate in the revised wording; a covering person shouldn't have to decode the program history to choose a next step.

The application owner resolves the uncertain outcome. Revised wording distinguishes it from known uninspected work and gives the contact and hold instruction. No automatic resend added.

Repeated walkthrough passed from no selection, ordinary empty fixture and uncertain coupon. The technician found the matching program and configuration revisions in the handover. Missing files and missing decisions both closed.