How should contradictory logs be handled?¶

Contradictory logs should be preserved, compared and explained rather than selecting whichever record best fits the preferred account.

Apparent contradiction is often an investigative clue.

Avoid the dangerous assumption¶

The dangerous assumption is that one of two conflicting logs must be false or manipulated.

They may record different stages, clocks or perspectives.

A client may record an action as sent while the server records it as rejected. A firewall may allow traffic while the application later denies access. One system may use UTC and another local time.

The contradiction may also result from delayed ingestion, parsing error, duplicated identifiers, stale directory information or incomplete exports.

Investigators should identify exactly what conflicts: time, account, device, action, result or sequence. Obtain field definitions and raw source records for both systems.

Check whether the records genuinely relate to the same event using session, request, transaction or correlation identifiers. Do not assume that matching usernames and approximate times are sufficient.

Consider the reliability and observation point of each source. A server may provide stronger evidence of receipt than a client application, while the client may be the only source showing the user-facing action.

Record the contradiction openly in the timeline or report. Explain possible causes and identify what further evidence could resolve it.

Where it cannot be resolved, state the limitation rather than choosing one account without justification.

Operational takeaway¶

Contradictory logs should be treated as different system observations requiring source, stage, timing and identifier analysis, with unresolved conflict reported rather than hidden or forced into one narrative.