Event Log Centered Modeling¶

Preserve happenings as the primary record and derive entity state, relationships, places, periods, timelines, and summaries as reproducible projections of the governed event log.

Status and gap-fill context¶

This is a candidate full solution archetype generated for queue position 50, the accepted prime event_centered_modeling. The queue recorded zero direct, related, variant, or alias coverage. The pre-draft comparison found several supporting patterns but no existing archetype that makes governed events canonical and all entity, place, period, case, and state views replayable projections.

Practical summary¶

Preserve happenings as the primary record and derive entity state, relationships, places, periods, timelines, and summaries as reproducible projections of the governed event log.

The core move is not “collect more logs.” It is to choose a different center of gravity for representation. Instead of storing a person, object, place, case, or system as a timeless record and attaching changes as side notes, record bounded happenings with participants, roles, time, place or context, transformation, provenance, and status. Then derive current state, trajectories, timelines, period views, aggregates, and narratives through explicit projection rules.

A valid event-centered system can answer two questions at once:

What view do we need now? A current-state, historical, spatial, case, period, or aggregate projection can be optimized for its users.
How was that view produced? The projection declares the events, order semantics, projector version, frontier, corrections, conflicts, and completeness limits from which it was derived.

Why this is a full archetype¶

The parent owns a transferable problem–intervention–feedback loop rather than one artifact or method:

Problem: independently mutable entity and current-state records overwrite history, drift across views, and cannot reliably explain or reproduce how the present arose.
Intervention: make bounded event assertions the canonical substrate and make views versioned projections.
Feedback: replay, rebuild, frontier monitoring, reconciliation, completeness review, and correction lineage reveal whether the event model remains sufficient and trustworthy.

An event store, audit log, event bus, timeline, knowledge graph, CQRS library, process-mining tool, or event-sourced projection can implement part of this loop, but none is the archetype by itself.

Structural model¶

A minimally useful canonical event assertion carries:

an event identity and type;
participants or affected entities with explicit roles;
event time and record time, including intervals or uncertainty where needed;
place or context;
a transformation or evidentiary delta;
source provenance and confidence;
validity, dispute, correction, or adjudication status;
ordering and relation links to other events.

Entity, place, period, case, and state records are then functions over selected events. The same event history may support multiple legitimate projections, provided each view declares its rules and does not silently become an independent source of truth.

Intervention logic¶

State the decisions, explanations, histories, recoveries, and views that require an event-centered source rather than a current-state table.
Define event boundaries, event types, minimum evidence, granularity, and distinctions among occurrence, report, inference, correction, and adjudication.
Assign stable event identities and persistent participant references while preserving unresolved identity, merge, split, and successor cases.
Capture participant roles, event time, record time, place or context, transformation delta, provenance, validity status, and uncertainty.
Establish the canonical event log, source-of-truth scope, append authority, validation gate, access boundary, and integrity checks.
Declare total, partial, causal, source-local, and computational ordering relations separately; define concurrency and tie-breaking behavior.
Reject or quarantine malformed and duplicate records, and use idempotent acceptance so retry or replay does not multiply effects.
Correct through linked supersession, retraction, compensation, or adjudication records; preserve prior knowledge states unless a governed exception requires redaction.
Define each entity, place, period, case, timeline, aggregate, or current-state projection with inputs, projector version, order semantics, output contract, and uncertainty behavior.
Expose projection frontiers, lag, source coverage, unresolved conflicts, and completeness limits to consumers.
Provide deterministic or explicitly adjudicated replay and rebuild paths, including schema upcasting, snapshots, and validation against known invariants.
Handle late and out-of-order events by scoped reorder, rebuild, notification, or decision-time freezing rather than silent insertion.
Reconcile live projections against canonical history and repair or rebuild drifted views instead of patching them as independent truth.
Govern retention, minimization, redaction, differential access, archival preservation, snapshotting, compaction, and retirement across canonical and derived forms.
Audit who and what is absent from the event record, test for schema-bounded blind spots, and revise event and projection models without rewriting historical evidence.

Required components¶

Event Boundary and Type Contract¶

Defines what counts as one bounded happening, which event types exist, and which facts belong inside the event rather than in a later interpretation.

The contract prevents arbitrary rows, snapshots, and labels from being called events. It should state start and end semantics, granularity, admissible uncertainty, required roles, and whether a record represents occurrence, report, inference, correction, or adjudication.

Canonical Event Record¶

Carries the minimum durable representation of a happening: identity, type, participants and roles, time, place or context, transformation, provenance, and validity status.

The record is the canonical unit from which entity, place, period, case, and state views are projected. It should be immutable or governed by append-only correction rather than silently rewritten.

Event Identity Key¶

Distinguishes one event or event assertion from another across ingestion, replay, correction, merge, and deduplication.

Identity may be assigned, content-derived, source-scoped, or composite. It must remain stable enough to detect duplicates and preserve correction lineage without pretending uncertain reports are certainly the same occurrence.

Participant–Role Binding¶

Links people, objects, organizations, or systems to an event with explicit roles rather than undifferentiated membership.

Roles such as initiator, recipient, witness, owner, subject, instrument, or beneficiary carry meaning. A participant can hold multiple roles, roles can be disputed, and identity resolution must remain separate from role assignment.

Event Time and Record Time¶

Separates when a happening occurred or was valid from when it was observed, reported, entered, corrected, or adjudicated.

This dual-time distinction supports late events, retrospective evidence, historical reproducibility, and bitemporal queries. Intervals, approximate dates, partial order, and uncertainty should be allowed when exact timestamps are unjustified.

Place and Context Binding¶

Links each event to the physical, institutional, jurisdictional, digital, or conceptual context in which it occurred.

Place is not always a point. Boundaries, names, jurisdictions, and contexts can change over time, so the binding should be versioned and uncertainty-aware rather than back-projecting modern geography.

Transformation Delta¶

States what changed through the event, including created, transferred, modified, destroyed, authorized, measured, or reclassified properties and relations.

The delta distinguishes an event from a calendar item or co-occurrence record. It can be explicit, inferred, partial, or disputed, but its status must be visible and tied to identity-preserving modification rules where relevant.

Event Ordering and Concurrency Rule¶

Defines the supported total, partial, causal, source-local, or domain-specific ordering relations among events.

The rule must not manufacture a global order when evidence supports only concurrency or uncertainty. It should identify tie-breakers used for computation separately from claims about historical or causal precedence.

Entity Identity Resolution Rule¶

Determines when participant references across events point to the same continuing entity, a successor, a role, a collective, or an unresolved candidate.

Event-centered modeling reduces pressure on static entity records but does not remove identity ambiguity. The rule needs merge and split lineage, persistent identifiers, confidence, and human review for consequential cases.

Event Log¶

Stores the governed sequence or graph of canonical event records and their correction lineage as the authoritative historical substrate.

Reuse the indexed Event Log component, but strengthen it here from temporary diagnostic capture to the canonical event substrate. The log may be append-only, ledger-like, graph-based, or source-federated so long as authority, order, provenance, and correction are explicit.

Provenance Record¶

Records the source, observer, acquisition method, custody, transformation, confidence, and evidentiary status supporting each event or event assertion.

Reuse the indexed component from Data Integrity Preservation, Layered Record Accumulation, Source Provenance Triangulation, and Versioned Evolution. Provenance is required to distinguish occurrence from report, inference, and later adjudication.

Correction and Supersession Rule¶

Defines how erroneous, incomplete, disputed, or reinterpreted event records are corrected without erasing what was previously recorded or believed.

Prefer linked correction, retraction, supersession, or compensating events. Destructive edits require an explicit legal or safety exception and an external evidence trail where feasible.

Projection Definition¶

Specifies how a named entity, place, period, case, timeline, aggregate, or current-state view is derived from selected event types and ordering semantics.

A projection declares inputs, filters, role interpretation, transformation logic, schema version, output contract, and uncertainty behavior. It is derived and replaceable rather than an independently writable source of truth.

Projection Frontier¶

Exposes the latest event sequence, time, partition, or evidence state fully represented by a derived view.

The frontier makes lag and incompleteness visible. A view should not present itself as current when late events, failed partitions, unprocessed corrections, or unresolved conflicts lie beyond its known frontier.

Replay and Rebuild Path¶

Reconstructs a projection from canonical event history under a declared projector version and validation rule.

Replay is both recovery machinery and a test of whether events truly contain enough information. Rebuilds must be deterministic or explicitly versioned when interpretation is probabilistic or human-adjudicated.

Late and Out-of-Order Event Policy¶

Determines how newly arrived, delayed, backdated, or concurrently observed events affect existing orderings and projections.

The policy should state acceptance windows, reorder scope, affected-view rebuilds, stakeholder notification, and whether decision-time views remain frozen for reproducibility.

Projection Reconciliation Check¶

Tests whether derived views correspond to the canonical event history, projector version, and declared frontier.

Checks can compare counts, hashes, invariants, sampled trajectories, or independent recomputation. Divergence must lead to repair, rebuild, or a visible degraded mode rather than silent manual patching.

Retention, Redaction, and Access Policy¶

Governs which event details are retained, minimized, sealed, redacted, disclosed, or deleted across canonical and projected forms.

Event histories can become surveillance infrastructure. The policy must handle purpose limitation, consent, rights, legal retention, historical value, differential access, projection deletion propagation, and proof of compliant redaction.

Optional or context-dependent components¶

Causal and Correlation Link¶

Connects events with explicit relation types such as caused-by, enabled-by, responds-to, follows, co-occurs-with, or merely shares evidence.

Sequence alone is not causation. Links should carry justification, confidence, direction, and the distinction between computational dependency and historical causal claim.

Uncertainty and Conflict Record¶

Preserves competing dates, participants, locations, transformations, source claims, and adjudication states without forcing one false canonical value.

This component is essential in historical, investigative, and scientific domains where evidence is incomplete or contested. Projections should declare how conflicts are included, filtered, or summarized.

Event Completeness Statement¶

States which event classes, sources, periods, populations, and blind spots the ledger does or does not cover.

The statement prevents the recorded world from being mistaken for the whole world. It should address missing sources, unlogged labor, censoring, destruction, access limits, and schema-bounded blind spots.

Source-of-Truth Reference¶

Declares which event ledger, source federation, or adjudicated subset is authoritative for a given projection and decision context.

Reuse the indexed component from Layered Record Accumulation and Strategic Caching. Authority can be scoped and time-dependent; one source need not be universally sovereign.

Timestamp or Sequence Marker¶

Provides the event-time, record-time, source-local sequence, or computational ordering marker used by the relevant projection.

Reuse the indexed Layered Record Accumulation component. Markers must not be overinterpreted beyond their clock, source, and uncertainty semantics.

Snapshot and Compaction Policy¶

Controls acceleration, archival summarization, and deletion of old event detail while preserving enough lineage and replay capability for declared uses.

This specializes the indexed Compaction Policy. Snapshots are derived checkpoints, not replacements for event authority unless the policy explicitly closes the replay horizon and records the resulting loss budget.

Cross-Layer Index¶

Indexes event identities, participants, places, times, sources, and projection memberships for retrieval across the historical substrate.

Reuse the indexed Layered Record Accumulation component. The index improves discovery but must not become a hidden second authority whose stale links are treated as canonical facts.

Common mechanisms¶

Append-Only Event Store¶

Persist accepted events and linked corrections in a durable order or graph while preventing silent in-place mutation.

Implements: event_log, event_identity_key, correction_and_supersession_rule.

Event Capture Template¶

Require event type, participants and roles, time, place or context, transformation, source, uncertainty, and identifiers at capture time.

Implements: event_boundary_and_type_contract, canonical_event_record, participant_role_binding, transformation_delta.

Event Knowledge Graph¶

Store events as primary nodes and connect participants, places, sources, periods, and transformations through typed edges.

Implements: canonical_event_record, participant_role_binding, place_and_context_binding, cross_layer_index.

Bitemporal Event Register¶

Record occurrence or valid time separately from observation, entry, correction, or adjudication time.

Implements: event_time_and_record_time, late_and_out_of_order_event_policy, correction_and_supersession_rule.

Versioned Event-Schema Registry¶

Register event types, field semantics, compatibility rules, and upcasters so older events remain interpretable after schema evolution.

Implements: event_boundary_and_type_contract, canonical_event_record, replay_and_rebuild_path.

Deterministic Replay Protocol¶

Reapply a declared event order through a pinned projector version and compare the result with expected state or invariants.

Implements: event_ordering_and_concurrency_rule, replay_and_rebuild_path, projection_reconciliation_check.

Event-Sourced Projection¶

Build and rebuild a query-specific entity, place, period, case, or state view from canonical event history.

Implements: projection_definition, projection_frontier, replay_and_rebuild_path.

Entity-Trajectory Projection¶

Assemble an entity history and current state from its role-bearing participation in ordered events.

Implements: entity_identity_resolution_rule, participant_role_binding, projection_definition.

Place-History Projection¶

Derive a place’s changing occupancy, boundaries, uses, events, and meanings for a declared time frame.

Implements: place_and_context_binding, projection_definition, event_time_and_record_time.

Periodization Projection¶

Group events into periods according to explicit boundary criteria while preserving alternative periodizations.

Implements: projection_definition, event_ordering_and_concurrency_rule, uncertainty_and_conflict_record.

Compensating-Event Correction¶

Append a linked correction, retraction, reversal, or supersession event instead of deleting prior history.

Implements: correction_and_supersession_rule, provenance_record, projection_reconciliation_check.

Event Replay Deduplication¶

Use stable event identities and idempotency records to prevent duplicate ingestion or replay from multiplying effects.

Implements: event_identity_key, replay_and_rebuild_path, projection_reconciliation_check.

Snapshot Plus Replay¶

Restore a projection from a validated snapshot and replay the remaining event suffix while retaining the event ledger as authority.

Implements: snapshot_and_compaction_policy, replay_and_rebuild_path, projection_frontier.

Projection Rebuild and Diff¶

Recompute a view from canonical events and compare it with the live projection to detect drift or non-determinism.

Implements: projection_reconciliation_check, replay_and_rebuild_path, projection_definition.

Projection-Frontier Dashboard¶

Expose processing frontier, lag, unresolved corrections, failed partitions, and rebuild status for each projection.

Implements: projection_frontier, late_and_out_of_order_event_policy, projection_reconciliation_check.

Process Mining / Trace Analysis¶

Analyze case-linked event traces for actual paths, waits, loops, handoffs, and conformance gaps.

Implements: event_log, event_ordering_and_concurrency_rule, event_completeness_statement.

Provenance-Weighted Event Reconciliation¶

Compare competing event assertions, sources, confidence, and adjudication status without erasing unresolved alternatives.

Implements: provenance_record, uncertainty_and_conflict_record, correction_and_supersession_rule.

Log Compaction¶

Reduce operational storage or replay cost under a declared retention, snapshot, provenance, and loss budget.

Implements: snapshot_and_compaction_policy, retention_redaction_and_access_policy, event_log.

Parameter dimensions¶

An event-centered model is not one fixed data shape. The design should name at least these dimensions:

Event granularity: micro-action, transaction, episode, institutional act, historical episode, or composite event.
Temporal model: instant, interval, uncertain range, partial order, source-local sequence, valid time, record time, or bitemporal pair.
Authority topology: one canonical ledger, federated sources, adjudicated subset, domain-scoped authority, or contested assertion graph.
Identity strength: stable identifier, probabilistic match, role-only reference, collective identity, successor lineage, or unresolved candidate.
Ordering strength: total, partial, causal, logical, ingestion, or projection-specific order.
Transformation semantics: explicit before/after delta, relation creation or removal, transfer, production, destruction, observation, report, or interpretation.
Projection type: current state, trajectory, timeline, spatial view, period view, case trace, aggregate, narrative-support view, or decision-time view.
Consistency contract: synchronous, ordered asynchronous, bounded lag, eventual convergence, or fixed historical snapshot.
Correction model: retraction, supersession, compensation, adjudication, redaction, merge, split, or reinterpretation.
Evidence model: observed, reported, inferred, disputed, corroborated, rejected, or adjudicated, with source confidence.
Replay horizon: full history, snapshot plus suffix, archived history, or explicitly closed reconstruction window.
Retention and access: public, role-restricted, purpose-restricted, sealed, redacted, minimized, time-limited, or archival.
Completeness claim: exhaustive within a bounded source, sampled, best effort, known incomplete, or contested.

Invariants to preserve¶

Every canonical event or event assertion has stable identity, type, provenance, validity status, and explicit temporal semantics.
Participant roles, place or context, and transformation are represented rather than hidden in free text or inferred from record location.
Given the same canonical history, order semantics, and projector version, a deterministic projection rebuilds the same result.
Corrections and reinterpretations preserve lineage to prior records and prior knowledge states.
No derived view silently becomes an independently authoritative source of truth.
Projection frontier, lag, unresolved conflicts, and coverage limits remain visible to users and downstream systems.
Late, duplicate, concurrent, and out-of-order events are handled through declared rules rather than ad hoc patches.
Event sequence is not presented as causation without separate evidence.
Identity merges, splits, successors, and unresolved matches remain auditable and reversible where feasible.
Retention, redaction, access, and deletion policies propagate to derived projections and indexes.
Snapshots and compaction preserve the declared replay and evidentiary horizon or disclose the loss budget.
Absence from the event log is not interpreted as absence from reality without an explicit completeness claim.

Target outcomes¶

Current state and historical trajectories can be explained and rebuilt from accepted event history.
Entity, place, period, case, and aggregate views remain consistent with a common historical substrate.
New questions can be answered through new projections without rewriting canonical history.
Corrections, late evidence, and revised interpretations remain reproducible and auditable.
Projection drift and replay defects become detectable through rebuild and reconciliation.
Historical, operational, and analytical views can coexist without pretending they are the same interpretation.
Identity, chronology, provenance, and uncertainty become explicit rather than scattered across records.
Recovery from corruption or schema change improves because views are rebuildable.
Privacy, access, retention, and archival decisions become enforceable across source and projection layers.
The model exposes blind spots and missing event classes instead of hiding them behind complete-looking entity records.

Recognized variants¶

Operational Event Sourcing¶

Use a governed event history as the operational source of truth and rebuild current state and query views by replaying versioned projectors.

Use when: Current state must be explainable from a durable sequence of accepted changes.; Multiple read models or services need different projections of the same operational history.; Correction, retry, replay, and auditability matter more than minimizing write-path complexity.

Distinctive feature: The event ledger drives live operational state rather than serving only as a historical research record.

Why it remains under the parent: Events remain canonical, state remains derived, and replay plus projection versioning remain the core architecture.

Historical Event Graph¶

Represent people, objects, places, institutions, and periods through their typed participation in evidence-linked historical events.

Use when: The same actors, objects, or places appear across many changing contexts.; Researchers need to reconstruct trajectories without forcing one static entity record to carry all temporal meaning.; Conflicting sources and uncertain dates must remain visible rather than silently harmonized.

Distinctive feature: Events serve as the integration hub for historical entities and evidence, with trajectories and periods derived from event participation.

Why it remains under the parent: It preserves the parent event core, role bindings, temporal anchors, transformations, projections, and correction lineage.

Bitemporal Event Model¶

Track both when an event is understood to have occurred and when the record became known, valid, corrected, or superseded.

Use when: Events arrive late, are corrected retrospectively, or have uncertain occurrence intervals.; Users must reproduce what was believed at an earlier decision time as well as what is believed now.; Regulatory, scientific, or historical questions require valid-time and record-time separation.

Distinctive feature: Every event carries two temporal axes and projection queries declare which axis governs the result.

Why it remains under the parent: Canonical events and reproducible projections remain the governing model.

Process-Trace Event Model¶

Model work or behavior as case-linked event traces so actual paths, waits, loops, handoffs, and deviations can be reconstructed.

Use when: Formal workflow descriptions differ from observed execution.; Cases can be correlated across event records without unacceptable privacy or identity error.; Bottlenecks, variants, loops, and conformance must be analyzed from actual traces.

Distinctive feature: A case or episode projection organizes events into executable traces for conformance and process analysis.

Why it remains under the parent: Case state and process paths are projections from canonical events rather than independently maintained truth.

Evidence-Weighted Contested Event Model¶

Retain competing event assertions, source provenance, confidence, and adjudication status instead of forcing one premature canonical account.

Use when: Sources disagree about whether, when, where, or how an event occurred.; The cost of erasing minority or later-vindicated accounts is high.; Users must distinguish observed, reported, inferred, disputed, and adjudicated events.

Distinctive feature: The canonical layer can hold multiple claims about an event and projects views according to declared evidence or adjudication policies.

Why it remains under the parent: The unit of organization remains the event and all views are still governed projections of event assertions.

Spatial Event Atlas¶

Derive the changing meaning, occupancy, use, and boundaries of places from the events that occurred or were attributed there.

Use when: Places change identity, jurisdiction, occupancy, or meaning over time.; Spatial and temporal questions must be answered together.; Users need to see multiple event layers without treating modern boundaries as timeless.

Distinctive feature: Place records are temporal projections of event participation rather than static containers with events attached.

Why it remains under the parent: Event records remain canonical and place views remain rebuildable projections.

Boundary distinctions¶

Layered Record Accumulation¶

Preserves successive layers or records so history remains readable. Event-Log-Centered Modeling additionally makes bounded events the integration hub and requires role, time, place, transformation, projection, replay, and correction semantics.

Versioned Evolution¶

Tracks explicit versions of a subject. An event model records happenings that may affect many subjects and derives versions or current state as projections rather than making versions canonical.

Access Optimized Redundant Representation¶

Optimizes recurring reads with governed redundant projections from any canonical source. It may use Event-Sourced Projection as a mechanism, but does not define the event ontology or require events to be canonical.

Data Integrity Preservation¶

Protects accuracy, consistency, and traceability across a record lifecycle. It supplies integrity controls but does not choose event primacy or replayable projection as the representation architecture.

Traceability Linking¶

Links sources, requirements, decisions, actions, and consequences. It may connect event evidence but does not reconstruct entity, place, period, or state views from a canonical event log.

Stratigraphic Time-Ordering Inference¶

Infers chronology from preserved layers and disturbance evidence. It reconstructs event order from strata rather than defining a governed event source and projection system.

Periodization Frame Design¶

Defines meaningful temporal periods and boundary criteria. Periods can be projections over events, but periodization does not own event capture, identity, replay, or correction.

Narrative Construction Audit¶

Audits selection, omission, causality, and framing in stories. It consumes event representations but does not establish the canonical event substrate.

Discrete–Continuous Model Selection¶

Chooses whether discrete events are an appropriate representation. Event-Log-Centered Modeling applies after a defensible event representation has been selected.

Shared State Consistency Contract Design¶

Governs consistency among shared-state views and replicas. It can protect projections but does not require event history to be the canonical source.

Order-Independent Processing¶

Redesigns operations so outcomes do not depend on order and includes Event Sourcing with Commutative Handlers as a mechanism. The current archetype instead governs event identity, history, order semantics, and projections whether or not handlers commute.

Tradeoffs¶

Historical fidelity and replayability increase storage, schema, and operational complexity compared with direct current-state updates.
One canonical event substrate supports many projections but shifts complexity into event design, identity resolution, ordering, projector governance, and rebuild operations.
Append-only correction improves auditability but can make simple facts harder to read and can preserve harmful or sensitive history longer than necessary.
Partial ordering is epistemically honest but makes some queries, summaries, and operational decisions harder than a convenient total order.
Rich provenance and uncertainty improve interpretation but increase capture burden and can slow ingestion.
Derived views reduce duplication of authority but introduce projection lag and eventual-consistency behavior.
Fine event granularity supports new analysis but creates event explosion, privacy exposure, and high replay cost; coarse events hide important transformations.
Snapshots and compaction improve performance but reduce the reconstructable horizon unless loss is explicitly governed.
Stable event schemas aid replay, while evolving concepts and historical interpretations require versioning and upcasting.
Centralized event authority simplifies consistency but can concentrate surveillance, governance power, and exclusionary schema choices.

Failure modes and mitigations¶

Pseudo-event records¶

Cause: Rows, snapshots, labels, or notifications are called events without participant roles, context, transformation, evidence, or bounded occurrence semantics.

Mitigation: Enforce the event boundary and type contract; reject or reclassify records that do not satisfy the minimum event assertion.

Identity collapse or fragmentation¶

Cause: References across events are merged too aggressively or treated as separate despite representing one continuing entity.

Mitigation: Use explicit identity-resolution rules, confidence, merge and split lineage, persistent identifiers, and human review for consequential joins.

Total-order fiction¶

Cause: One timestamp or ingestion sequence is presented as the true historical or causal order despite concurrency, clock differences, or uncertain dates.

Mitigation: Represent partial order, intervals, source-local sequence, and computational tie-breaks separately; label causal claims independently.

Duplicate or replay multiplication¶

Cause: Retries, import overlap, source repetition, or rebuilds apply the same event more than once.

Mitigation: Use stable event identities, idempotent acceptance, deduplication records, and replay tests.

Non-deterministic projection¶

Cause: Projectors depend on mutable external state, current time, undocumented defaults, or unpinned code and reference data.

Mitigation: Pin projector versions and dependencies, isolate side inputs, record deterministic seeds or adjudication decisions, and run rebuild-and-diff tests.

Projection becomes hidden authority¶

Cause: Teams patch read models or snapshots directly because rebuilding is inconvenient.

Mitigation: Restrict writes, require canonical correction events, expose lineage and frontier, and reconcile or rebuild rather than patch.

Schema evolution breaks history¶

Cause: New event fields or meanings make old records uninterpretable or replay differently without a version boundary.

Mitigation: Use versioned schemas, compatibility rules, upcasters, migration tests, and preserved projector versions.

Destructive correction¶

Cause: Erroneous or politically inconvenient events are edited or deleted without preserving what changed and why.

Mitigation: Use linked correction, retraction, supersession, or compensating events; permit destructive redaction only under governed safety or legal rules.

Late-event corruption¶

Cause: Backdated or delayed events are inserted without rebuilding affected projections or preserving decision-time views.

Mitigation: Apply the late-event policy, scope reorder and rebuild, preserve bitemporal knowledge states, and notify material downstream decisions.

Recorded-world completeness fallacy¶

Cause: Users assume that unlogged actors, informal work, destroyed evidence, or excluded populations did not exist.

Mitigation: Publish event completeness statements, coverage metrics, source gaps, schema-blind-spot reviews, and alternative evidence channels.

Sequence-to-causality overreach¶

Cause: Temporal precedence is treated as sufficient evidence of cause, intent, or responsibility.

Mitigation: Use separate causal relation types, evidence requirements, counterfactual review, and uncertainty annotations.

Surveillance accumulation¶

Cause: The event model captures every action indefinitely because storage and future analytical value are treated as unlimited goods.

Mitigation: Apply purpose limitation, data minimization, access tiers, retention horizons, redaction propagation, independent oversight, and deletion verification.

Compaction destroys replay or evidence¶

Cause: Old events are summarized or deleted without a declared reconstruction horizon or loss budget.

Mitigation: Validate snapshots, retain provenance and correction anchors, test rehydration, document irrecoverable loss, and preserve legally or historically necessary archives.

Event explosion and unusable granularity¶

Cause: Every minor observation becomes an event, overwhelming users and projectors.

Mitigation: Define event granularity by decision and reconstruction needs, group low-value micro-events, and retain raw telemetry outside the canonical semantic event layer when appropriate.

Projection frontier concealment¶

Cause: A lagging or partially failed projection is presented as complete and current.

Mitigation: Expose frontiers, lag, failed partitions, unresolved corrections, and degraded-mode indicators at the point of use.

Ethical and safety guardrails¶

Collect the minimum event detail required for declared purposes; event primacy does not justify universal capture.
Separate occurrence, report, inference, and adjudication so records do not launder allegations into facts.
Provide access, correction, contestation, and explanation paths where event projections affect rights or opportunities.
Preserve marginalized or dissenting evidence without exposing vulnerable sources or subjects unnecessarily.
Document missingness, destruction, censoring, and schema exclusion as part of the model rather than as footnotes.
Use role-based and purpose-based access, especially for health, employment, education, policing, and human-rights records.
Review identity linking and place inference for re-identification and collective harm.
Do not use temporal sequence as sole evidence of intent, responsibility, or cause.
Ensure redaction and deletion propagate to projections, caches, indexes, snapshots, training datasets, and exports where required.

Concise examples¶

A museum derives each object’s custody, location, condition, and claim status from creation, acquisition, loan, damage, restoration, and restitution events.
A commerce platform reconstructs an order from accepted, paid, allocated, shipped, delivered, returned, and refunded events, while each service maintains a versioned read projection.
A historical database treats a person as a trajectory through births, appointments, affiliations, migrations, correspondence, trials, and deaths rather than one timeless biography row.
A healthcare record distinguishes when an exposure occurred from when it was reported and derives clinical, billing, and research views from the same governed events.
A permit office analyzes actual case paths from submission through review, revision, decision, and appeal while exposing unlogged and manually handled steps as coverage gaps.
A supply-chain system derives custody and condition from production, inspection, transfer, storage, transformation, recall, and disposal events.

Extended example¶

A cultural-heritage consortium needs to model the history of artifacts held across museums, private collections, archaeological sites, and restitution claims. Existing object records contain one current owner, one location, and prose notes; each institution has a different timeline, and corrections overwrite prior claims. The consortium first defines event types such as creation, excavation, acquisition, transfer, loan, exhibition, conservation treatment, damage, seizure, claim, adjudication, and restitution. Every event receives an identity, event-time interval, record time, place context, participant-role bindings, transformation delta, source provenance, confidence, and status such as reported, corroborated, disputed, or adjudicated. An event ledger stores assertions and linked corrections without silently deleting prior records. Entity-resolution rules preserve uncertain object matches and split or merge lineage when catalog identifiers change. A historical-event-graph projection reconstructs each object trajectory; a place-history projection shows events associated with changing jurisdictions; a claims projection includes only event assertions meeting a declared evidence policy; and a decision-time projection reproduces what an institution knew when it acquired an object. Projection frontiers expose which archives and date ranges have been processed. Late archival discoveries trigger scoped rebuilds and notices when ownership or display claims materially change. Public projections minimize sensitive source details, while restricted researchers can inspect fuller provenance. Snapshot and compaction policies accelerate common queries without replacing the event ledger. The result is not one final narrative: it is a governed historical substrate from which multiple transparent, reproducible, and contestable views can be derived.

Non-examples¶

A spreadsheet that stores only each object’s current owner and last-updated timestamp.
A meeting calendar with no transformation, provenance, correction, or derived-state semantics.
A system that logs every click but treats the log only as telemetry and maintains authoritative state elsewhere.
A static timeline manually edited to fit one narrative without preserving sources or alternative orderings.
A current-state database with an audit trigger that cannot rebuild the state from logged changes.
A process-mining dashboard whose case identifiers and missing-event assumptions are undocumented.

Review guidance¶

The most important human review is the boundary between a canonical event assertion and a mere log row, plus the privacy and power consequences of retaining event history. Reviewers should also test whether the event source actually supports deterministic or explainable rebuilds, whether a partial order is being flattened for convenience, and whether missing or contested events remain visible.

Common Mechanisms¶

Append-Only Event Store — An immutable, ordered store that only ever accepts new events and never edits old ones, serving as the single source of truth from which all state is derived.
Bitemporal Event Register — Records every fact along two clocks — when it happened and when the system came to know it — with the source of each assertion, so you can ask what was believed as of any past moment.
Compensating-Event Correction — Corrects a mistaken event not by editing it but by appending a new reversing or adjusting event, so the erroneous record and its correction both remain in the history.
Deterministic Replay Protocol — Reconstructs a past state or sequence by re-applying the same events in the same order through the same logic, so the rebuild is reproducible down to the last detail.
Entity-Trajectory Projection — 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.
Event Capture Template — A standard shape for recording a happening — its type, what changed, who took part, and where — so a raw occurrence becomes a well-formed, self-describing event rather than a bare timestamped row.
Event Knowledge Graph — Materializes the event log as a queryable graph, linking events, participants, and entities across layers with typed participation and causal-or-correlation edges.
Event Replay Deduplication — Lets a consumer process an at-least-once event stream safely by keying on stable event identifiers, so a redelivered or replayed message never applies its effect twice.
Event-Sourced Projection — Builds a read-optimized view by folding an append-only log of events, so the same history can be replayed to produce many views — or rebuild any of them from scratch.
Log Compaction — Reclaims space by keeping only the latest or still-necessary record per key and discarding superseded history, under a retention policy that must never break the ability to rebuild state.
Periodization Projection — Derives named periods from the event log by cutting the timeline at the transformations that mark one regime turning into the next.
Place-History Projection — Assembles the full history of a place by gathering every event bound to it into one time-ordered account, resolving the many names a single place goes by.
Process Mining / Trace Analysis — Reconstructs the real process from event traces — discovering the actual control flow, its variants, and where reality deviates from the intended path — that the log reveals but no diagram admits.
Projection Rebuild and Diff — Rebuilds a projection from the log and diffs it against the live view, treating any disagreement as evidence the view is wrong, never the log.
Projection-Frontier Dashboard — Shows how far each projection has consumed the log, turning invisible replication lag and coverage gaps into watched, actionable numbers.
Provenance-Weighted Event Reconciliation — Resolves conflicting, duplicate, and late event claims by weighting each by the trustworthiness of its source, while keeping the disagreement on the record.
Snapshot Plus Replay — Rebuilds current state fast by starting from a periodic snapshot and replaying only the events since, instead of the whole history.
Versioned Event-Schema Registry — Versions event type contracts so producers and projections can evolve their schemas without silently breaking each other or the old history.

Compression statement¶

Define a valid event as a bounded happening with identity, type, participants and roles, event time, record time, place or context, transformation, provenance, and validity status; append accepted events and linked corrections to a governed canonical log; state explicit ordering and concurrency semantics; resolve entity identity without flattening uncertainty; define versioned projections for each entity, place, period, case, timeline, aggregate, or current-state view; expose each projection frontier; rebuild views through deterministic or adjudicated replay; handle duplicate, late, out-of-order, corrected, disputed, and schema-old events; reconcile projections against the log; preserve completeness limits and alternative accounts; and govern retention, redaction, access, snapshots, and compaction so convenience views never silently replace the historical substrate.

Canonical formula: Let L be a governed partially ordered set of event assertions e=(event_id, type, participants×roles, valid_time, record_time, place/context, transformation, provenance, status). For projection definition Pᵥ and frontier f, view Vᵥ,f=Pᵥ(L≤f). A valid architecture preserves: reproducibility of V from L and Pᵥ; explicit ordering and uncertainty; correction lineage rather than silent overwrite; visible frontier and completeness limits; and the ability to discard and rebuild V without losing canonical history.

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (9)

Data Integrity: Accuracy and consistency preserved.
Event-Centered Modeling: Making events the primary nodes through which entities, places, and periods are connected, so that everything else is derived as a projection of the event log.
Identity-Preserving Modification: An entity undergoes an event that changes some of its properties while an identity-condition licenses calling the after-state a continuation of the same entity rather than its replacement.
Projection: Map a richer object onto a lower-dimensional target along a chosen direction, discarding the rest.
Relation: Describes associations or dependencies.
Replay: After live experience, a system reactivates captured sequence-traces in a decoupled offline window, and that rerun — not the original experience alone — writes durable structure into memory or skill.
Representation: Model complex ideas.
State and State Transition: Captures system condition and evolution.
Temporal Dynamics: System outcomes depend fundamentally on timing, sequencing, duration.

Also references 25 related abstractions

Accountability: Responsibility for actions.
Causality: Cause-effect relationships.
Collective Memory: Shared narratives.
Completeness: No gaps in structure.
Event Lifecycle Phases: Decomposing a hazard-bearing event into pre-event, event, and post-event regimes and treating each phase, not the event, as the primary unit of intervention design.
Eventual Consistency: Distributed copies of shared state are allowed to diverge under local updates, with a deterministic merge guaranteeing they reconverge once updates stop.
Interoperability: Systems function together.
Located-In Relation: One entity is situated within the region of another at a time, without that entity being a part of, or strictly contained by, the location.
Object Permanence: A system maintains persistent internal state for entities it cannot currently observe, modeling them as continuing to exist and re-binding them on re-emergence.
Observability: Infer internal state externally.

▸ Show 15 more

Variants¶

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Operational Event Sourcing · domain variant · recognized

Use a governed event history as the operational source of truth and rebuild current state and query views by replaying versioned projectors.

Distinct from parent: The parent is domain-general and can model historical or evidentiary events; this subtype adds command acceptance, operational consistency, failure recovery, and service-level projection concerns.
Use when: Current state must be explainable from a durable sequence of accepted changes; Multiple read models or services need different projections of the same operational history; Correction, retry, replay, and auditability matter more than minimizing write-path complexity.
Typical domains: software systems, financial operations, order fulfillment
Common mechanisms: append only event store, event sourced projection, snapshot plus replay, event replay deduplication

Historical Event Graph · domain variant · recognized

Represent people, objects, places, institutions, and periods through their typed participation in evidence-linked historical events.

Distinct from parent: This subtype emphasizes archival evidence, contested accounts, approximate dates, and historiographic interpretation.
Use when: The same actors, objects, or places appear across many changing contexts; Researchers need to reconstruct trajectories without forcing one static entity record to carry all temporal meaning; Conflicting sources and uncertain dates must remain visible rather than silently harmonized.
Typical domains: history and historiography, archives, cultural heritage
Common mechanisms: event knowledge graph, bitemporal event register, entity trajectory projection, place history projection

Bitemporal Event Model · temporal variant · recognized

Track both when an event is understood to have occurred and when the record became known, valid, corrected, or superseded.

Distinct from parent: The parent requires explicit temporal semantics; this subtype makes dual time mandatory and query-visible.
Use when: Events arrive late, are corrected retrospectively, or have uncertain occurrence intervals; Users must reproduce what was believed at an earlier decision time as well as what is believed now; Regulatory, scientific, or historical questions require valid-time and record-time separation.
Typical domains: legal records, financial reporting, historical databases, clinical records
Common mechanisms: bitemporal event register, versioned event schema registry, projection rebuild and diff

Process-Trace Event Model · domain variant · recognized

Model work or behavior as case-linked event traces so actual paths, waits, loops, handoffs, and deviations can be reconstructed.

Distinct from parent: The parent can support arbitrary event graphs; this subtype emphasizes cases, activities, handoffs, and process conformance.
Use when: Formal workflow descriptions differ from observed execution; Cases can be correlated across event records without unacceptable privacy or identity error; Bottlenecks, variants, loops, and conformance must be analyzed from actual traces.
Typical domains: operations, healthcare pathways, public administration
Common mechanisms: process mining trace analysis, entity trajectory projection, projection frontier dashboard

Evidence-Weighted Contested Event Model · governance variant · recognized

Retain competing event assertions, source provenance, confidence, and adjudication status instead of forcing one premature canonical account.

Distinct from parent: The parent can operate with accepted events; this subtype makes claim plurality and evidence status structurally mandatory.
Use when: Sources disagree about whether, when, where, or how an event occurred; The cost of erasing minority or later-vindicated accounts is high; Users must distinguish observed, reported, inferred, disputed, and adjudicated events.
Typical domains: historical research, investigations, human rights documentation
Common mechanisms: provenance weighted event reconciliation, event knowledge graph, projection rebuild and diff

Spatial Event Atlas · domain variant · recognized

Derive the changing meaning, occupancy, use, and boundaries of places from the events that occurred or were attributed there.

Distinct from parent: The parent treats place as one event role; this subtype makes spatial transformation and boundary change central.
Use when: Places change identity, jurisdiction, occupancy, or meaning over time; Spatial and temporal questions must be answered together; Users need to see multiple event layers without treating modern boundaries as timeless.
Typical domains: historical geography, urban history, archaeology
Common mechanisms: place history projection, periodization projection, event knowledge graph

Near names: Event-Centered Modeling, Event-Centric Modeling, Event-First Modeling, Event-Log-Centered Representation, Event-Sourced Modeling, Event-Graph Modeling, Activity-Centered Modeling.