Could one system record the start while another records completion?¶

Yes. One system may record when an action begins while another records when it completes.

Both records may describe the same wider activity but represent different stages.

Avoid the dangerous assumption¶

The dangerous assumption is that differing times or results mean the records contradict each other.

They may be entirely consistent.

A client application may record when a user submits a request. A web server may record when it receives that request. An application may record processing, and a database may record when the final change is committed.

Those stages can be separated by network delay, validation, queueing, retries and processing time. The result may also change as the action moves through the system.

A client may show “sent” while the server later records “rejected”. A firewall may allow a connection while the application denies access. A transaction may be accepted initially and later reversed.

Investigators should identify what stage each event represents. Ask whether the timestamp marks request creation, receipt, processing start, completion or final state.

Use request IDs, transaction IDs, session IDs and correlation IDs to test whether the records belong to the same operation. Preserve all available status and result fields rather than relying on the most convenient entry.

Do not describe the earliest event as proof of completion or the latest event as proof of the original user action. Each system should be reported according to its observation point.

Where no final outcome record exists, state that the action was initiated or received rather than completed.

Operational takeaway¶

Different systems may record different stages of one activity, so investigators must distinguish initiation, receipt, processing and completion before treating differing times or outcomes as contradiction.