Skip to content

Entity-Trajectory Projection

Derived projection / read-model — instantiates Event-Log-Centered Modeling

Derives one entity's path through time by gathering every event it took part in — resolving its identity across records and stitching cross-referenced layers into a single ordered trajectory.

The event log is organized by when things happened, but people usually want to know what happened to this one thing. Entity-Trajectory Projection answers that question by reading the log entity-first: it collects every event a given entity participated in — across event types, systems, and identifier changes — and orders them into a single coherent trajectory, the entity's story as a path through time. Its defining difficulty, and its real content, is identity: the same customer, shipment, or patient appears under different keys in different events, so building the trajectory means resolving "which events actually belong to this one entity" and indexing across the log's layers to find them all. Where a projection like periodization slices the log by time, this one slices it by subject — producing not current state but a history, the ordered arc of one entity's participation.

Example

A logistics company wants each parcel's full journey. A single parcel generates events across a dozen systems and carriers, and — the crux — under different identifiers at each handoff: the merchant's order_id, the origin carrier's tracking_number, a partner carrier's waybill, and the last-mile courier's stop_id. No single key runs through the whole log. Entity-Trajectory Projection builds the journey anyway. Its identity-resolution rule links these keys into one parcel identity (matching on handoff references, address, and time), and a cross-layer index lets it pull every event tied to any of those keys out of the scan layer, the customs layer, and the delivery layer.

The result is one ordered trajectory: label created → picked up in Memphis → cleared customs in Frankfurt → out for delivery → delivered, signed. A support agent viewing a "where is my package" query sees the whole arc, including the customs delay that explains the holdup — even though those events were scattered across systems under four different ids. The projection is disposable: when the identity-resolution rule improves (a better match for a tricky carrier handoff), the trajectory is simply rebuilt from the log, no source data touched.

How it works

The projection is distinguished by being subject-indexed and identity-driven:

  • Resolve the entity's identity. Apply rules that recognize when events under different keys refer to the same real entity — the hardest and most consequential step, since a bad match splices two entities' histories or splits one.
  • Index across layers. Use a cross-layer index to locate every event referencing the entity, wherever it lives in the log's event types and systems.
  • Order into a trajectory. Sequence the gathered events into the entity's path through time, so the output is an arc, not a snapshot.
  • Rebuild on demand. As a derived view, it is regenerated from the log when identity rules or indexing improve, rather than being edited in place.

Tuning parameters

  • Identity-match strictness — how confidently two keys must match to be fused into one entity. Strict matching avoids splicing distinct entities but leaves trajectories fragmented; loose matching yields complete arcs but risks merging two different subjects.
  • Layer coverage — how many event types and systems the projection reaches across. Broad coverage produces a fuller journey but costs indexing and can pull in weakly-related events; narrow coverage is cleaner but partial.
  • Trajectory grain — every event versus milestone events only. Fine grain shows the complete path; milestone grain gives a readable summary but hides detail that may matter.
  • Ordering basis — event time versus record time for sequencing the arc. Event-time order reflects real-world sequence; record-time order reflects the order the system learned things, and mixing them scrambles the story.
  • Rebuild cadence — live-updated versus periodically regenerated. Live trajectories are current but costlier to maintain; periodic rebuilds are cheap but lag the log.

When it helps, and when it misleads

Its strength is that it makes the log answer the question people most often actually have — "what is the history of this one?" — by turning scattered, differently-keyed events into a single legible arc. It is what lets a case worker, an investigator, or a support agent see an entity's whole journey rather than a disconnected pile of records.

It misleads chiefly through identity. Resolution is inference, not fact: fuse two keys wrongly and you splice a stranger's events into someone's history; split one entity's keys and you show a truncated arc that hides what happened — and both errors produce a confident, coherent-looking trajectory that is simply about the wrong entity.[1] Ordering is the other trap: sequencing a subject's events by the wrong clock tells a scrambled story that reads as if it were chronology. The discipline is to treat every identity match as a probabilistic claim with a confidence, keep the resolution rule inspectable and rebuildable, and always state which clock the trajectory is ordered on.

How it implements the components

Entity-Trajectory Projection realizes the subject-oriented derivation side of the archetype — the components that gather one entity's scattered events into a path:

  • entity_identity_resolution_rule — it decides which events, under which keys, belong to the same real entity, so a coherent trajectory can be assembled.
  • cross_layer_index — it locates every event referencing the entity across event types, systems, and layers of the log.

It builds one entity's history but does not discover the process model or guarantee reconstruction: control-flow across all cases is Process Mining / Trace Analysis, bit-exact rebuild is Deterministic Replay Protocol, and slicing the log into periods is Periodization Projection.

Notes

The projection's honesty depends entirely on the identity-resolution rule, which is a model, not ground truth. Because the output looks so coherent — a clean, ordered arc — a wrong match is unusually convincing and unusually damaging: it presents one entity's life as another's. Keeping the resolution rule explicit, versioned, and confidence-scored is what separates a trustworthy trajectory from a plausible fabrication.

References

[1] Entity resolution (also record linkage) is the task of determining that records referring to entities under different identifiers denote the same real-world entity. It is inherently probabilistic, and its errors — false merges and false splits — propagate directly into any history built on top of it. ↩