@ChloeAdams0135 Found it. i can split our Python log into two sessions. Still no attempt match for that PLC acknowledgement, though.

Start with the session split and each source's own ordering, leaving that acknowledgement unassigned. The timestamps beside those entries should establish a combined sequence.

Those clocks disagree. No offset or causal link, no established combined order.

@NaomiBrown0941 You're right to challenge that. The timestamps can suggest matches, not prove them. Keep source order intact and label cross-system links uncertain unless there's supporting evidence.

i'll leave it unassigned. A tidy timeline would be nice, but the nearest timestamp would still be a guess.

@TobyBrown0927 I had a clock adjustment make a merged incident view look plausible on my setup. The original per-source order was what let us correct the interpretation.

Would monotonic time fix it? Or only inside one process?

@FelixBrown0893 Use monotonic time for durations within a running process. It doesn't supply a shared clock across machines or restarts; keep session identity and wall-clock reference alongside it.

Stable job ID, separate attempt ID for each try? Is that what our reused label is missing?

That's the useful split. A job ties the work together; an attempt distinguishes each try. Record both with the event source and session.

Does the documented PLC interface support a correlation value? Application identifiers alone won't create matching identifiers in another system's records.

i can't see a correlation field in our export. i'll need the interface owner's input, and that won't retroactively identify the entries i already have.

This resolves how i'll present the incident: separate source sequences, application sessions identified, and the unmatched acknowledgement left uncertain. i'm not claiming that establishes the job's final outcome.

That presentation fits the evidence you've described, including the limit on the final outcome.