My sleeve program picks, places and advances through two trays. Clean runs work, but stopping between those actions can leave the saved pocket disagreeing with what's actually there. How should I represent the interrupted transfer before normal production depends on a counter that might be telling half the story?
Treat source removal, held-piece state and destination placement as separate facts tied to an identified transfer and trays; a saved pocket alone cannot establish which physical actions completed, especially when a stop separates action from confirmation.
We save the destination pocket before picking, then advance it after place returns. There is no durable transfer record between those points. After a restart the screen offers that pocket again, without telling the operator whether the sleeve might already be there.
Replay those boundaries offline before adding recovery buttons. Include loss after physical placement but before its result is stored. The software should preserve unknown state there, not decide the pocket is empty because a write did not happen. Have the integration owner define how the actual piece and trays are reconciled before any further movement.
That replay reproduced the duplicate destination offer. The revised design retains a transfer identity and stage before dispatch, and marks an unconfirmed outcome as unresolved instead of offering the pocket again. We also found tray replacement was invisible to the saved counter, so tray identity is now part of the recovery design.
The draft shows the identified source and destination trays, attempted pocket, last confirmed stage and what is still unknown. It does not tell the operator where the sleeve must be. The integrator and shift lead are defining the authorised physical reconciliation and restart procedure before installed testing.
Include a failure to persist the transfer record in that assessment too; the application should not initiate work under an identity it cannot retain, and the operator-facing explanation should distinguish that from an uncertain physical outcome.
And keep the original late-save replay as a regression case. The new labels are clearer, but the important software result is that an unresolved transfer no longer produces an automatic second offer. Installed recovery still needs its separate authorised assessment.