@LeahBrooks0843 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.

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

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

You're right to distinguish those. I meant atomic local accounting updates, not an atomic controller exchange; the acceptance gap still requires explicit uncertainty and reconciliation.

Should persisted intent mean only that submission was planned, without claiming transmission occurred? Our existing pending state has been hiding that distinction.

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

@LeahBrooks0843 If there's no acceptance saved locally, why not call it unsubmitted? Isn't that the only record startup can use?

@GraceBell0668 Acceptance can happen before your local save. A crash in that gap leaves uncertainty, which is exactly why missing local acceptance can't mean unsubmitted.

@LeahBrooks0843 The final result and recovery implementation remain unresolved. I've retained the attempt as uncertain and kept it out of the automatic resend queue.

@AnnaCarter1025 Understood. Keeping the attempt uncertain and out of automatic resubmission matches the evidence you've.