Event Sourcing Guide

Guide
Persistence Pattern

The Architecture of Memory

Traditional systems suffer from amnesia—forgetting the context of every change the moment it is saved. Intelligence Spaces require Event Sourcing: a persistence model that preserves the complete history of intent, enabling traceability, evolution, and deep reasoning.

Time Travel
Immutable Facts
Multi-Lens Projections
Core Principles
01

The Philosophy: Truth vs. State

In a standard "row-based" system, when a Thinker updates a concept, the previous understanding is overwritten. This is amnesia by design. For an Intelligence Space, the process of reaching a conclusion is as valuable as the conclusion itself.

Persistence Layer
Immutable Record
PRINCIPLE 01

History is the Source of Truth

We do not store "State"; we store "Facts" (Events). The current state is merely a derivative (projection) of the history.

PRINCIPLE 02

Amnesia is a Bug

Overwriting data is destroying knowledge. Every change must be additive. We preserve the path taken to reach the answer.

PRINCIPLE 03

Intent Precedes Fact

We capture the user's Intent (Command) separate from the Outcome (Event). This allows us to understand why a change happened.

PRINCIPLE 04

Evolutionary Schema

The model will change. We design for evolution (Upcasting) rather than rigid migrations. Old history is never broken; it is re-interpreted.

The Core Shift

Traditional

"Status: Complete"

Storage
Event Sourcing

"TaskCompleted"

Traditional

"Lost immediately"

Context
Event Sourcing

"Preserved in Metadata"

Traditional

"Last write wins"

Truth
Event Sourcing

"Sum of all events"

Technical Implementation
02

The Architecture of Memory

To achieve "Intellectual Honesty," the system requires provenance. Event Sourcing embeds this into the atomic unit of storage. Every change is signed, timestamped, and causally linked.

The Anatomy of an Event

interface EventMetadata {
  readonly eventId: string;       // Unique ID
  readonly timestamp: number;     // When it happened
  readonly causationId?: string;  // What triggered it (Command ID)
  readonly correlationId?: string;// The wider context (Thread/Process)
  readonly userId: string;        // Who did it
}

You cannot mutate data without leaving a trace. The structure forces accountability.

03

Evolutionary Architecture

Mental models evolve. What we thought was a "Note" today might become a "Hypothesis" tomorrow. Traditional databases require destructive migrations to rename columns. Event Sourcing uses Upcasting.

The Problem

You rename name to title. In a SQL database, you must migrate every row, risking downtime or data loss. The history of the old schema is lost.

The Solution (Upcasting)

Keep the old events as they were (immutable). Register an Upcaster that transforms v0 events to v1 shape on the fly when reading. The past remains pristine; the present evolves.

Patterns & Practices
04

Intent-Based Interaction

We separate Intent (Command) from Fact (Event). This enforces "Thinker Sovereignty"—the Thinker proposes a change, and the system acts as a steward, validating the intent before recording it as fact.

Command → Event Flow
Pipeline Active
1
CommandIntent

"I want to merge these concepts."

RejectableCarries User ID
2
DecisionValidation

System checks invariants: "Are they compatible?"

Aggregate LogicBusiness Rules
3
EventFact

"ConceptsMerged"

ImmutableForeverTimestamped
05

Decoupled Intelligence

A single model cannot capture all dimensions of a complex problem. Event Sourcing naturally supports the Lens architecture via Projections—read-optimized views built by folding over immutable facts.

Source
Event Streams

Multiple streams (one per aggregate). Each stream is a consistency boundary.

Active
Structural Lens
Graph of Concepts
Pragmatic Lens
Competence Scores
Evolutionary Lens
Velocity of Change

The Pattern

Each aggregate instance owns its own event stream (one task = one stream). Projections subscribe to events across all streams, building consolidated read models optimized for specific queries. The same events can feed multiple projections—each lens sees the same facts through a different perspective.

Interactive Laboratory
System Online

The Event Sourcing Workbench

This workbench is a hands-on experiment designed for tinkering. Manipulate the core concepts of Event Sourcing—Time Travel, Concurrency, and Projections—to build a deeper, intuitive understanding of how the pattern works.

Temporal Replay
Rewind system state
Schema Evolution
Test upcasters live
Concurrency
Simulate race conditions
Projection Tuning
Adjust lens parameters
Advanced Topics
06

Public Verifiability & Blockchain

In a decentralized world, truth cannot be administered; it must be verified. Event Sourcing is the native architecture of the Blockchain. A Smart Contract is simply an aggregate that accepts Commands (Transactions) and emits Events (Logs).

Trustless Auditability

"Don't trust, verify." Because the entire history of events is public and immutable, anyone can replay the stream to prove the current state is correct. No "admin" can silently alter the database.

Efficient Persistence

Storing full state on-chain is expensive. Emitting Events (Logs) is cheap. We keep the "Truth" (Events) on-chain, while the "Intelligence" (Projections) runs off-chain in Indexers (e.g., The Graph), maintaining cost-efficiency without sacrificing integrity.

Reference
07

Knowledge Inventory

01

Event Sourcing

A persistence pattern where state is derived by replaying a sequence of immutable events, rather than storing the current state directly.

Enables "Time Travel" and absolute traceability of thought.

02

State

The current condition of a system at a specific point in time. In Event Sourcing, state is a derivative (Left Fold) of history.

State is ephemeral; History is permanent.

03

Event

An immutable fact that happened in the past (e.g., "HypothesisValidated"). It cannot be rejected or changed.

The atomic unit of truth.

04

Command

An intent to change state (e.g., "ValidateHypothesis"). It can be rejected by the system.

Captures the "Why" before it becomes the "What".

05

Aggregate

A cluster of domain objects that can be treated as a single unit. It enforces consistency boundaries.

The guardian of invariants.

06

Projection

A read-optimized view of the event stream. Multiple projections can exist for the same data (e.g., Structural vs. Pragmatic).

Allows us to see the same reality through different Lenses.

07

Upcasting

Transforming legacy events to the current schema on-the-fly during read. Non-destructive migration.

Allows the ontology to evolve without breaking history.

08

Provenance

The metadata tracking the origin, cause, and context of a piece of data.

Intellectual Honesty requires knowing where an idea came from.

09

Immutability

The property of being unchangeable. Events are never modified, only appended.

Ensures the integrity of the historical record.

10

Causation ID

A link to the Command or Event that caused this Event.

Builds the causal chain of reasoning.

11

Correlation ID

A link grouping related events into a transaction or conversation.

Preserves the context of complex operations.

08

Concept Translation

We ground our architecture in established computer science and distributed systems theory.

The foundational persistence pattern.

Enterprise Application Architecture"Event Sourcing"
CQRSAdopted

Separating the Write Model (Aggregate) from the Read Model (Projection).

Software Architecture"Command Query Responsibility Segregation"

Structuring the code to match the mental model.

Software Engineering"Aggregates / Ubiquitous Language"

Handling valid-time vs. transaction-time.

Database Theory"Bitemporal Data"

Append-only storage structures for high throughput.

Database Internals"LSM Trees"