The bracket-inspection application timed out and restarted under the same job label. PLC, controller and Python timestamps disagree. I have kept each local sequence, but the merged report gives an acknowledgement to the new attempt just because its time looks closest. I don't trust that assignment.
I would inspect the original events before adjusting the clock comparison. Does any shared request or attempt identity link that acknowledgement to an outgoing request? The friendly label can stay the same while the actual attempts differ.
PLC has an exchange number, but the Python export omits it. We are checking the original application journal rather than using the merged timestamp order.
Did the original journal retain it? If so, check the number's scope across restart too; a counter that starts again can still need a session identity beside it.
Journal retained neither exchange number nor a shared session reference. We cannot recover the link. The acknowledgement is now explicitly unassigned, with the known local sequences sent to the authors for the timeout investigation.
That's the honest limit for this occurrence. Have the next recorder retain the relationship before sending the request, with restart and late-reply cases in its tests, rather than relying on better clocks to supply identity.