Event-Centered Modeling¶
Core Idea¶
Event-centered modeling makes events — bounded happenings carrying participant, time, place, and transformation — the primary nodes, so entities, places, and periods become projections of the event log rather than records carrying events as side-data.
How would you explain it like I'm…
What Happened Is The Hub
Instead of writing down a list of people and things, you write down what happened, and hang everything else off of that. Each happening tells you who was there, when, where, and what changed. To know a person's story, you just look at all the happenings they showed up in.
Happenings First
Event-Centered Modeling means making events, the things that happen, the main hubs that everything else connects to, instead of making people or objects the main thing with events as extra notes. Each event carries four pieces: who was involved and how, when it happened, where it happened, and what changed. Once events are the hub, a person is read as the trail of events they took part in, and a place is read as all the events that happened there. This is different from just having dates in your data: a date stuck on a person is only a label, but here the person has no date of their own; the event has the date, and the person connects to the event. A neat result is that you can spot contradictions, like two events claiming different things about the same person at the same moment.
Events As The Spine
Event-Centered Modeling is the structural choice to make events, bounded happenings with a time, place, and set of participants, the primary nodes through which everything else is connected, instead of making things, people, or places primary and treating events as side-data. Once events are the integration hub, an entity is read not as a static record but as a trajectory across the events it participated in, and a place or period is read as the union of the events it contains. The schema commits to four roles travelling with each event: participants (who was involved and in what role), time (when it occurred), place (where it occurred), and transformation (what state changed). This is not the same as having dates in your data: a date attached to an entity is merely a property, but an event-centered model inverts the wiring, so the entity has no direct date; it has an event, and the event has the date. The result is that entities, places, periods, and roles are all re-derivable as projections of the event log, and contradictions surface when two events claim incompatible facts about the same participant at the same time, which a property-on-entity model cannot detect.
Event-Centered Modeling is the structural choice to make events, bounded happenings with a time, a place, and a set of participants, the primary nodes through which everything else is connected, instead of making things, people, or places primary and treating events as side-data. Once events are the integration hub, an entity is read not as a static record but as a trajectory across the events it participated in, and a place or a period is read as the union of the events it contains. The schema commits to four roles travelling with each event: participants (who or what was involved and in what role), time (when it occurred or spanned), place (where it occurred), and transformation (what state was changed, who came into possession, what was produced or destroyed). Subtract any one of the four and what remains is not an event but a row, a calendar entry, a list of names, or a vague claim about change. This is not the same as having dates in your data: a date attached to an entity is merely a property, whereas an event-centered model inverts the wiring, so the entity has no direct date; it has an event, and the event has the date. The result is that entities, places, periods, and roles are all re-derivable as projections of the event log, and contradictions surface when two events claim incompatible facts about the same participant at the same time, a property a property-on-entity model cannot detect. The structural force is the inversion itself: by making the happening primary and the thing derivative, the model concentrates the representation of change into one place and makes history a first-class, queryable structure rather than an annotation overwritten on update. The pattern is substrate-neutral, governing a heritage object's provenance, a chain of legal title, an incident reconstruction, an append-only software event log, and a contact-tracing graph alike.
Broad Use¶
- Cultural heritage: an object's history is creation, acquisition, restoration, and exhibition events connecting persons, places, and dates.
- Historiography: databases connect actors through attested events rather than static biographical fields.
- Law: chains of title, where current ownership is a derived view over conveyance events.
- Incident investigation: occurrences modeled as events with participants, times, and state changes; causes found by walking the event graph.
- Software: event sourcing, where application state is computed by replaying an append-only event log.
- Epidemiology: exposure, onset, and contact events drive contact tracing, with a person read as the events they appear in.
Clarity¶
Supplies one domain-independent test — "which event is this fact a projection of?" — that exposes a system silently losing history whenever load-bearing facts are stored as entity properties rather than projected.
Manages Complexity¶
Concentrates the bookkeeping for change into one place: history queries become cheap and uniform because history is the model, at the bounded cost of a projection step for current-state queries.
Abstract Reasoning¶
The four roles let a reasoner see one skeleton across an acquisition record, an adverse-event log, and a commit log, so practices like immutable logs and snapshots port directly between historiography and software.
Knowledge Transfer¶
- Software → historical records: event-sourcing discipline (immutable logs, snapshots, projections) applies to provenance systems.
- Historiography → software: treating events as primary evidence applies to audit logs.
- Museums → epidemiology: the four-role skeleton governs both provenance chains and contact-tracing graphs unchanged.
Example¶
An append-only account ledger stores no balance on the account; the balance is a fold over the events naming it, so the full history survives and two events contradicting at one time-slice are detectable.
Not to Be Confused With¶
- Event-Centered Modeling is not Temporal Dynamics because it is a representational choice about schema wiring, whereas temporal dynamics is a theory of process describing how a system's variables move under a law of motion.
- Event-Centered Modeling is not Provenance because it is the underlying wiring that makes lineage queryable, whereas provenance is one query and property the wiring serves.
- Event-Centered Modeling is not Narrative because it is a neutral, append-only substrate over which many narratives project, whereas a narrative selects and emplots events into one chosen, interpretive thread.