Our FR5 fixture verification ran while the laptop application crashed. On restart the pending file was sent again because pending means both not sent and no result saved. I need to untangle that before the next software test. The fixture may have completed work our file never heard about.
Stop treating uncertain work as unsubmitted work. Give requests persistent identities and establish how the receiving application reports an existing request before you allow automatic resubmission; a new local status name alone will not prevent another execution.
Changed startup so uncertain entries wait for reconciliation. Receiver currently has no lookup by request ID. Programmer is adding that to our application interface, but we haven't established which records survive its restart yet.
Test that persistence explicitly. If the receiver forgets a completed request after restart, the sender cannot infer that the work never happened from an empty lookup. That case needs an unresolved state and an agreed recovery process.
Who will reconcile those entries on shift? Give that person the request identity, the available execution evidence and the physical verification procedure. An indefinite pending list merely transfers the ambiguity from software to an operator.