Example Reconstruction
A concrete example of how fragmented operational history becomes a sealed, reproducible sequence.
Scenario
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.
Raw Intake
14:02:11 ORDER_7421 → CREATED
14:05:33 ADDRESS UPDATED
Ticket opened for order 7421
Customer requested delivery change
Shipment scheduled
Delivery attempt recorded
- Timestamp drift
- Non-uniform identifiers (ORDER_7421 vs 7421 vs free text)
- Missing cross-reference keys
- Events spread across unrelated systems
Canonical Envelope Normalization
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" }
} Event Chain Construction
Each event is hashed. The hash of the prior event is embedded in the next. Order is explicit.
Any change to the sequence breaks its integrity.
e1032 → hash: a94f...
e1033 → prev_hash: a94f...
e1034 → prev_hash: b221... Deterministic Reconstruction
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 across environments.
Independent Verification
The final output contains the full event sequence along with its integrity structure.
A third party can verify that the sequence is complete, ordered, and unchanged — without access to the original systems.
If any part of the sequence has been altered, the verification result will not match.
Generate a Verified Record
Upload a CSV to reconstruct and verify a complete event history.
View File Requirements
For demonstration purposes, the system expects a minimal set of fields that define an event:
- timestamp
- stream_id
- event_type
- actor
- object
- notes
These fields capture the essentials needed to reconstruct a reliable event sequence: when something happened, what occurred, and what it affected.
Column order does not matter. All required fields must be present.
This example uses a simplified input format to keep the reconstruction process clear and predictable.
In real deployments, data can include additional fields and more complex structures. Those are mapped into the system during integration.
Timestamps must be ISO 8601 with timezone.
Example: 2024-01-01T10:00:00Z
Prima Veritas does not modify or infer missing data. Inputs must match the required format to ensure reproducible results.
Do not upload sensitive or personal data. Files are processed for demonstration purposes only.