Why does reconnecting count the same FR10 coupon completion again?

Application stores the job name and its own row number. PLC retains the job name. We reuse the name for successive coupons, so it doesn't identify the attempt.

That resembles our delayed-completion problem: the receiver attached whichever reply arrived to the active attempt. Does yours count immediately on connection, or only after the operator selects the current job?

Immediately on connection. Selecting a job isn't needed. I checked that in the saved replay, not by sending another inspection.

Can the replay show the old completion without incrementing the total?

That is a useful display case, Noah, with the retained observation distinct from a newly accepted result; controls still needs a reliable attempt-matching rule rather than using the screen change to settle ownership.

Quality is reconciling the earlier entries, Callum. The draft display holds retained observations separately. The interface owners are defining an attempt reference that survives the relevant restarts.

Does that include the producer restarting and reusing its sequence, Priya? A new field can still repeat if its lifetime is shorter than the record it identifies.

And make the producer-restart case part of the agreed examples, Jonas, with old and new observations both present; it is easier to review that than an abstract promise that the identifier is unique.

Producer restart is now in the examples. Thank you Jonas. We had described application restart in detail and left the other side as 'retained as normal'.

What happens to an observation that still cannot be matched?

It stays unresolved in the draft, visible but excluded from accepted totals. Quality handles the affected coupon separately. Offline checks of that path are still outstanding.

When those checks run, include an old completion that was legitimately accepted before the outage. The useful behaviour is retaining that one acceptance without earning a second one.