Example Reconstruction

A set of operational logs tracks updates to an order across multiple systems: an order management system, a customer support dashboard, and a fulfillment or shipping tool.

Each system records events independently. Timestamps drift. Field formats differ. Identifiers are inconsistent. No single system preserves the full history.

The result is a fragmented view of what actually happened.

Each raw record is transformed into a canonical structure with a unified timestamp, source identifier, schema version, and structured payload.

{ event_id: "e1032", source: "order.system", timestamp: "2026-04-12T14:02:11Z", payload: { order_id: "7421", status: "CREATED" } }

Each event is hashed. The hash of the prior event is embedded in the next. Order is explicit.

Changing or reordering an event breaks the link to every later event. Removing events from the end, or replacing the whole sequence, is detectable only against a receipt kept separately.

e1032 → hash: a94f... e1033 → prev_hash: a94f... e1034 → prev_hash: b221...

From the ordered sequence, system state at any point in time can be reconstructed.

Order creation, address changes, support intervention, and delivery attempts are derived from a single unified history.

Given the same input, reconstruction output is identical on the same machine. Cross-machine testing is pending.

The final output contains the event sequence along with its hash chain.

It can be rechecked without access to the original systems. Checked against a hash kept separately, it shows whether the sequence has changed since it was sealed. It does not show that the source data was complete.