I'm splitting pending because it currently means two quite different things. Our FR5 housing-inspection application crashed after sending work but before saving a result, and startup resends pending entries. The robot might have carried on. How should I represent that uncertainty without quietly declaring the housing inspected?
Give uncertain submission its own durable state. Do not resubmit it automatically. Define reconciliation using the job identity and whatever retained execution evidence the actual interface provides.
I've removed automatic resend for those entries. The awkward bit is our identifier: it identifies the housing, not an inspection attempt. Two attempts can therefore produce the same label in the file.
Separate the physical housing identity from the attempt identity. Retain their relationship. Also define which component owns the decision that an uncertain attempt has been reconciled.
The software maintainer is drafting that decision with quality. We've added distinct attempt identities in the bench version, but old entries cannot acquire missing execution evidence by being renamed. Those are still held for review.
Include crashes around each durable write in the bench tests. A clean restart alone will not exercise the interval that caused this ambiguity. The older held entries remain a separate disposition question.