How should uncertain event order be reported?¶

Uncertain event order should be reported as uncertain rather than forced into a precise sequence.

Several records can share the same timestamp or come from clocks that are not reliably aligned.

Avoid the dangerous assumption¶

The dangerous assumption is that sorting by displayed time always proves which event occurred first.

It may not.

A log may record only whole seconds while several events occurred within that second. One system may be two minutes fast. Another may show ingestion time rather than event time.

Where order matters, investigators should look for sequence numbers, request and response relationships, process ancestry, transaction stages and correlation identifiers.

Technical logic may establish partial order even where the clocks do not. A response must follow its request, and a database commit must follow the operation that triggered it. But the exact interval may remain unknown.

Use wording such as “by this point”, “within the same recorded second”, “the available records do not establish which occurred first” or “event A is technically upstream of event B”.

Do not add artificial milliseconds or reorder equal timestamps without a documented basis. Preserve the source ordering where available, but establish whether that ordering reflects event creation, file writing or ingestion.

Where two sequences remain possible, show both if they materially affect the investigation. Identify what further evidence could resolve the issue.

If the order affects attribution, causation or a legal proposition, make that uncertainty visible in the conclusion rather than leaving it buried in technical notes.

Operational takeaway¶

Uncertain sequence should be reported using ranges, partial order and explicit limitations, without inventing precision or treating displayed timestamp order as conclusive.