The receiver currently returns a result but exposes no request-history query. We can retain a durable identifier locally, yet that alone cannot establish whether the previous request executed. I will make the uncertainty explicit.

Correct, a local identifier becomes useful for reconciliation only if the other side preserves and reports the corresponding identity. Until that contract exists, define a supervised recovery route for unknown jobs rather than turning the absence of a query into permission to resend.

Name the recovery owner in the procedure. An unknown outcome left in a queue without an owner can still become somebody's guessed restart later.

Also distinguish a job never considered for dispatch from one whose dispatch began before a crash. A durable pre-dispatch record helps expose the uncertainty window, though it cannot make local storage and remote execution atomic.

I have changed the offline recovery model to retain dispatch intent before sending and hold incomplete attempts as unknown after restart. The production interface remains unchanged while we review receiver-side identity and the supervised reconciliation procedure.

Exercise crashes before dispatch intent, after intent but before sending, after sending, and after receiving the result but before saving it. The latter three may be uncertain locally even though their actual remote histories differ; that's the point the test should preserve.

Can I ask what the operator will see for that hold, rather than only what goes into the file? They need to know which inspection is in doubt.

The proposed view shows the plate identity, attempt identifier, last durable state and assigned recovery owner. Offline crash tests now prevent replay of unknown attempts. Receiver reconciliation and operator review are still outstanding, so this is not a completed production fix.

Include the reason for holding it, so an operator doesn't read unknown as failed.