Why does replaying our FR5 inspection export add accepted brackets?

Yes. It loads the old number and increments for every pass row. There are item identities, attempt identities and quality decisions in the export. The counter uses almost none of them.

I inherited one like that. It was written as a live display, then somebody added import without changing the counting logic. Do not repair it by subtracting a guessed number of retries. Build the total from the item decisions and make importing the same event again harmless.

Who decides which retry result is current?

And keep an unresolved decision out of accepted. A later raw pass may still be waiting for quality to review it.

Quality owns the current decision, Nina. The reviewed retry has a decision reference; an unreviewed pass does not replace the earlier rejection. I've given those examples to our programmer.

Only inspected brackets are in the export. The batch list is separate. We cannot call the absent ones accepted or rejected just because there is no row.

Toby's point is useful for the screen: show planned, accepted and still requiring a decision without pretending those are all inspection attempts. The old attempt history can stay available below the item view.

Test a decision changing away from accepted as well. I've seen a counter handle retries beautifully and then refuse to go down when quality puts an item back on hold.

Rebuild now matches quality's item list. We replayed the export twice, restarted the application, and replayed it again without changing the total. Earlier failed attempts are still visible under each bracket.

Anil's hold test found one more bug: the item label changed but the accepted set didn't. Programmer corrected that, and accepted-to-hold-to-accepted now updates the total once at each change. That closes our counter fix.

Thanks for including the hold test result; that is a useful example for our students, who tend to assume progress counters only ever go up.