Jonas, can a shared event help estimate an offset? I agree about keeping uncertainty, but I wouldn't throw away a clear common event merely because the displayed times differ.

Yes, if it is independently identifiable as the same event. What I would not do is use the disputed acknowledgement as the anchor, then claim the aligned times prove which attempt owns it.

Python has separate process-start entries and local order. PLC trace has the repeated label but no process identity. I can separate the application's attempts, not yet assign the acknowledgement across sources.

Make that distinction visible in the incident note. The next shift should not read two well-ordered application attempts as proof that the receiver distinguished them too.

What is the reused label supposed to identify: a logical inspection job or each submission attempt? That definition matters before you change the future record format.

And keep the old label as recorded. A new naming rule can prevent a repeat, but renaming these old entries would make later readers think the receiver saw identities it never received.

It was used for both meanings. Maintainer is separating job and attempt identity in the proposed logging contract, including restart lifetime. The incident copy still carries the original label and unassigned acknowledgement.

That is a sensible place to leave the old evidence. Can your future offline test replay a delayed acknowledgement after restart without allowing its old job label to select the new attempt?

Added that ordering to the maintainer's tests. No new correlation code completed yet, and the historical acknowledgement remains unresolved rather than attached to the nearest timestamp.