Why would startup repeat an inspection whose result we lost?

No query available. It returns a result while connected, then our app saves it.

Then keep those interrupted attempts held for a defined review while you agree how to reconcile them. The receiver may have completed the inspection, and a second send could repeat work rather than recover the missing result.

What does the operator see after restart? Pending sounds like ordinary queued work to me. I would not know it meant somebody has to investigate.

Currently pending. Proposed label is outcome unknown, with automatic replay disabled for those entries.

How will the application distinguish never submitted from a crash during dispatch? That's the boundary I'd test before relying on the new label.

Developer proposes a durable dispatch-intent entry before sending. Incomplete attempts after that point stay unknown.

Who can resolve an unknown attempt, and what evidence must they check before choosing any recovery action?

Test a crash after intent is saved but before the actual send too. That record will be uncertain locally even if nothing reached the receiver; the recovery procedure must allow for both possibilities.

We had an operator interpret unknown as failed and repeat a check. Put the reason for the hold beside the label so that distinction does not depend on remembering a training talk

Shift lead will own review with the integrator's recovery procedure. The procedure is not finished yet.

Will the screen show which bracket and attempt need review? A general warning would leave me hunting through the queue.

Yes. Bracket identity, attempt, last saved stage and review owner in the proposed view.

Did the developer run the crash cases offline? Include a received result lost before local saving, since that is another route to a completed physical inspection with an uncertain local record.

Does the restart also retain decisions already saved by the reviewer?

That is worth checking as a separate saved update, especially if the review screen and inspection-event handler write the same record.

Our team found a short walkthrough with an operator helpful here; they asked what happens when the named reviewer is absent, which the developer had not considered

Offline crash tests hold uncertain attempts and retain saved review decisions. No production change installed yet.

Backup review owner added. Receiver history and the recovery procedure still need agreement before deployment.

Please bring back the finished screen wording. I would like to see whether someone on shift can understand the hold without reading the software notes first.