I found that our inspection application's restart routine resends every pending bracket job, even where the last process crashed after dispatch; I want to distinguish never-sent work from an attempt with no saved outcome, because that second bracket may already have been inspected.
Treat the uncertain attempts as requiring reconciliation before they can be resubmitted. Start by tracing one saved incident through the application and receiver records; don't test your theory by sending it again on the live setup.
The saved incident has a dispatch entry but no corresponding result entry, and the receiver record available to me doesn't identify individual attempts; I've asked the software owner to pause that automatic replay path while we review recovery.
That evidence supports uncertainty, not completion or non-execution. The recovery design needs a way to correlate durable attempt identities and outcomes where supported, plus an explicit human decision path when the records cannot establish what happened.
What will the operator see for the affected bracket? Give them the sample identity, the uncertainty and the recovery contact. 'Pending' usually tells us to wait, and it would be a rotten label for something that needs a decision.