The phone view doesn't show that. We have installed program and fixture identities. I'll ask the technical contact which retained event information they need alongside the next occurrence.

Capture the ordinary condition that step expects as well. An apparently empty receiving nest does not tell you whether its confirmation was available to the routine.

Captured another stop with the technician's requested information. Nest looks empty. Active step is waiting for its ready confirmation, which the routine does not show as present.

Send the capture with that distinction intact. Physical appearance and the recorded confirmation are two observations, not proof that the input is faulty

Which fixture revision was installed for that occurrence? Would help the person comparing the logic with the bench.

Revision C fixture. The loaded recipe identifies B. Found that while putting the report together, not claiming it explains every earlier stop.

That is worth taking to the recipe owner. Ask them to compare what each revision expects, not just rename the screen entry so it matches the fixture.

And retain both configurations for their comparison. The wrong label alone wouldn't prove the underlying expectation is different

Recipe owner confirmed the loaded B definition waits on a different ordinary confirmation. Their controlled replay reproduces the captured wait. They've prepared the corrected C configuration for the normal approval and test process.

Who keeps B from being selected for that fixture again? Otherwise the next handover can recreate this.

Configuration owner has withdrawn that incompatible selection for this fixture. Approved correction and the defined changeover checks passed, including the captured failure case. Closed this ticket with both configurations and results attached. Thanks Grace, checking what the routine expected got us somewhere the video alone couldn't.