Why did reconnect give us an extra accepted housing?

Yes, same job number in both saved rows. The monitor forgot its previous bit state and treated the first reading as a new completion. That's what the developer found, anyway.

Ask them to reproduce it from the captured data and check a result completed during the outage too, because that second case still needs recording once

Does that job number ever restart?

Yes, after maintenance resets. So matching the number alone has a catch. I've asked controls what identifies the run it belongs to.

There is a run value in the retained registers. The monitor doesn't save it with the result. Developer is adding that to the proposed fix.

And the old rows without it will need care; I'd leave any uncertain matches for review rather than have the new code quietly decide they are duplicates

Show that review state clearly and name who handles it. Recovery of the display should not issue new robot work or erase the retained job information.

Could you first reconcile the one pair you actually watched duplicate? It gives the reviewer a concrete example before they tackle the older rows with missing run information.

Yes, keep the change traceable; our totals get copied elsewhere, so correcting the source number without saying why can leave two different totals circulating

The watched duplicate is reconciled with quality. Offline tests now use run and job together and handle the two outage cases once each. Older uncertain rows remain flagged. Nobody cleared the PLC bit to make the screen look tidy.

Does the operator see which total still needs review, or is that only visible to the developer?