Platform

A simple operating model behind the commercial promise.

EntityFlow is easiest to understand when you frame it as four moves: ingest events, extract the key, attach them to one entity timeline, then expose history and state in an operationally useful way. In practice that means lining up concrete moments like parcel ready, shipment created, carrier scan or delivery exception around the same business identifier.

Core formula
events + entity key + mappings = operational timeline
How it looks in product terms

Four product moves, one operational result.

Mini-diagram
parcel readyshipment createdcarrier scandelivery exception
ERP: shipment created01
WMS: parcel ready02
Carrier: hub scan03
Support: delay ticket04
Entity anchor
Parcel PX-2048
Timeline
ready
shipped
scan
issue
Before hover
Four disconnected signals. No usable case yet.
On hover
One reconstructed case file ready for investigation.
01
Ingest
Kafka, API, CDC, webhook
02
Normalize
Entity key, mapped fields
03
Rebuild
Ordered timeline per ID
04
Expose
Search, projections, views
Live
Example output
Parcel PX-2048
4 sources merged
Shipment creation, parcel-ready event and carrier scan attached to the same parcel
Delivery exception already aligned with the customer support ticket
One readable parcel history instead of four systems to inspect

Event ingestion

Bring in Kafka events, API payloads, CDC streams and the other operational signals that already exist.

Mapping and normalization

Define the entity key, map useful attributes and normalize event structure without forcing upstream rewrites.

Timeline reconstruction

Attach each event to the right identifier and rebuild the timeline in the order operations actually need to inspect.

Operational outputs

Expose history, current state and investigation-ready views for users who need to act, not just analyze later.

Start with one identifier

Reconstruct its history. Decide what comes next.

Tell us which identifier matters and which sources already describe it.