I restarted our FR10 inspection application after a crash and its helper offered to send the pending plate again. The original request had already gone out. We just lost the application before it saved a result.
I stopped the automatic retry because the plate could have been inspected while our file stayed unchanged. Now I'm helping rewrite the recovery notes. What should pending be split into so the next person isn't invited to repeat work simply because the local record is incomplete?
We found the same word covering never sent and sent but unknown. Give those different states, and keep uncertain attempts out of the automatic send queue. Does your receiver retain an attempt identity or result you can look up?
Only the plate label in the current record. It was reused in earlier checks, so the retained result cannot settle this attempt by label alone. The existing plate stays held for review.
Then have the interface owner define a separate attempt identity and what survives reconnect or receiver restart. Keep the old incident uncertain where the evidence runs out; the new design cannot repair an identity that was never recorded.
Put Oscar's ownership question in the recovery screen as well as the notes. People need to know who can resolve the hold, not only that an application developer considers the state ambiguous.
Quality and controls own the review; the screen names that route without resubmitting the job. The revised contract uses attempt identity and leaves failed lookups unresolved. Offline cases are being checked. The original result still cannot be assigned confidently.