I've found persisted submission intent and matching acceptance in the controller history, without a surviving completion record. This attempt is excluded from our automatic resend queue.

@OscarAli0184 Keep it uncertain and reconcile by identity. Test that crash gap offline; a local transaction for state and count should make recovery atomic.

Atomic locally. That transaction can't include the controller accepting a request. The gap that caused this still exists.

@BethBarnes0585 Exactly; my wording was too broad. The transaction protects local accounting. Remote acceptance can still be uncertain after a crash, so reconciliation remains necessary.

So persist intent first, but don't treat intent as proof of sending? That's where our pending label got stretched beyond usefulness.

Yes. Intent is durable local evidence of a plan. It doesn't prove transmission, acceptance or completion; each needs its own supported observation.

Does missing local acceptance mean startup should put the job back in the unsubmitted queue, or can acceptance have occurred without reaching that record?

@BethAli0237 The remote side may accept the request before the application persists its acknowledgement. Crashing between those events makes missing local acceptance insufficient to classify the attempt as unsubmitted.

My own test suite covered interruption before transmission but omitted interruption after remote acceptance and before local persistence, leaving the difficult recovery case untested.

I'll put our replay break exactly in that gap. Startup should retain uncertainty and emit no replacement request.

Which evidence is sufficient to resolve the outcome? Matching acceptance establishes that the request was accepted, but not that inspection completed.

For completion, matching completion evidence. Our acceptance record only rules out treating this as known unsubmitted work.

@OscarAli0184 When matching evidence resolves the result, retain its source with the update and keep the interruption history, allowing someone else to follow the reconciliation.

@JackBennett0776 Do you overwrite pending, then? Or does every state need to stay forever in the main screen?

@BethAli0237 The current view can change. Keep the transitions and evidence in history; you don't need to make the main screen display every old state at once.

@JackBennett0776 My setup showed uncertain jobs apart from the unsubmitted queue. That stopped people treating both lists as a pile of work waiting to be launched.

@HenryBaker0438 I'll make that distinction in our display too. Pending really was a label for everything we hadn't bothered to name.

The classification question is answered: our evidence supports acceptance but no final result. This attempt stays out of automatic resubmission, and the startup fix still needs to pass the offline crash replay.

@OscarAli0184 You've resolved where the attempt belongs without claiming a completion you don't have. The startup verification remains clear.