the inspection dashboard gains work when it reconnects

The saved row has a job number. The replay makes a second row with the same number, so it's a straightforward duplicate in this case.

Add a case where the monitor disconnects before the result is saved. You need that result recorded once after reconnect. Otherwise a fix that suppresses all startup completions can pass your first example and lose genuine work.

Does your job number survive equipment restart without being reused? I don't know your interface, but that would change the comparison.

Yes, establish that before treating the number as permanently unique. Our offline records included a run identifier because the local counter restarted. Yours needs a documented identity rule, not necessarily the same implementation.

We have a retained run identifier already, but the monitor drops it when saving results. I'll have that omission reviewed. Existing rows can't all be matched confidently after a counter reset.

Keep those older ambiguous rows distinct from the known reconnect duplicate. You can correct the confirmed duplicate with an audit trail without claiming to have reconstructed every historical result.

The instructor display also needs a defined state for unresolved history. A total with an unspoken caveat is likely to be copied into records. Decide who can reconcile it and what evidence they must review.

Was the extra row created immediately on connection, or after you pressed anything on the dashboard?

That is worth capturing in the reproduction steps. A reconnect event and a manual refresh might share code, but they are different triggers and should not be assumed equivalent.

Immediately on connection, no button pressed. Manual refresh didn't add a row in the captured test. I've recorded the trigger and retained the old results file for comparison.

Have you tested a result saved just before the connection drops? The save and local bookkeeping might finish at different times.

That case duplicates too in the old monitor. The revised offline version keys the saved result by run and job, and both reconnect cases now record it once. Historical uncertainty is still a separate review item.

Useful progress. The live acceptance check still needs the agreed interface and display behaviour verified with the controls owner; the offline replay establishes the application response to those supplied records.