Our last durable entry is submission intent. Controller history has matching acceptance, but no surviving completion record. I've kept it out of the resend queue

@SaraAbbott0026 Preserve the uncertain attempt and use matching evidence for reconciliation. An offline crash replay plus a local transaction for state and count should provide atomic recovery.

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.

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.

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

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.

On my ledger, we simulated crashes before send but forgot the gap after remote acceptance. All the restart tests passed for the easy half.

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

And what evidence ends uncertainty? A matching acceptance still doesn't tell you the inspection finished.

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

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