Event Sourcing and AI

Most analytics and AI initiatives still start from data at rest: snapshots are pulled from operational databases, cleaned, and fed into reports or models. But a business does not operate in snapshots. It operates in actions, decisions, and outcomes – in events. A system that stores only its current state has already thrown away most of what an analysis would need.

Snapshots Forget, Events Remember#

A traditional database answers the question what is true right now. When a book is returned, its status changes from borrowed to available, and the loan is gone. Nobody can later ask how long it was out, whether it came back late, or whether the reader extended the loan twice before.

An event-sourced system keeps all of this, because it stores every change as a fact: book-borrowed, loan-extended, book-returned, late-fee-charged. For analysis and AI, this history has properties that snapshots cannot offer:

• Business language. Events are named in the words of the domain, so the data carries its meaning with it. A data scientist does not have to reverse-engineer what a status code meant.
• Immutable history. Nothing is overwritten, so any dataset can be reproduced exactly – the one a model was trained on last year included.
• Complete timelines. Every change has its place in time, which makes trends, seasonality, and sequences visible that an overwritten value would hide.
• Traceable inputs. Every number derived from the history can be traced back to the events it came from. Even when a model itself remains a black box, the origin of its inputs does not.

From Events to Insights#

The path from raw events to insights runs through a few recurring steps. Each builds on the previous one, and each can be repeated at any time, because the history underneath stays intact.

1. Capture the facts. It starts with well-modeled domain events that describe what happened, in the language of the domain – see Modeling Events.
2. Shape them for analysis. Analytical projections turn the event stream into structured datasets: time series, histories, statistics.
3. Derive features. From those datasets come the measurable variables that models learn from – see Features from Events. Throughout, point-in-time correctness makes sure that no example sees what was not yet known.
4. Share the results. Datasets and features become most valuable when other teams can find and rely on them, as data products with a clear owner and a documented meaning.
5. Close the loop. Predictions lead to actions, and actions produce new events. Recording both makes it possible to measure what a model actually achieved – see Closing the Loop.

Questions Nobody Planned For#

The most important questions of a system are often the ones nobody thought of when it was built. With a snapshot, a new question needs new data, and that data only starts to accumulate from the day someone asks. With an event history, the data is already there.

In a library, for example, the same history of loans can answer questions that arise years apart:

• Borrowing patterns – which genres are in demand in which season?
• Member history – how punctual is a reader, and how likely is a late return?
• Title popularity – how will demand for a title develop, and when should more copies be ordered?
• Fee patterns – how do book type, loan period, and late returns relate to each other?

None of these questions has to be anticipated when the events are written. A new analysis or a new feature can be derived months or years later, by replaying the history that has been there all along.

Start Small#

Working with events does not require a large data platform. The basic shape is simple: events feed projections, and projections feed analyses and models. A first step can be a single projection and a simple classifier, for example one that predicts which loans are likely to be returned late.

As needs grow, the same history supports more: forecasts, anomaly detection, recommendations, and the conversational exploration of data with language models. Nothing that was built early has to be thrown away, because every later step starts from the same events.

Explainability and Domain Understanding#

A recurring problem with AI is understanding why a model produced a certain result. Event Sourcing does not make a deep neural network transparent. But it ensures that:

• Every input can be traced back to a specific sequence of events.
• Domain experts can check whether a feature makes sense in business terms, because it is expressed in business terms.
• Every model can be audited and reproduced with exactly the historical data it was trained on.

This tight link between data and domain language leads to results that people can understand, question, and trust – which matters as much as accuracy once a model starts to influence decisions.

Two Ways to Ask#

There are two complementary ways to get insights from an event history. The first is the pipeline: projections, features, and models, built once and run continuously. It is the right choice for automated decisions, recurring reports, and production models, because it is repeatable and scales.

The second is the conversation: a language model with access to the events answers questions in plain language, without a projection having to exist first. It is the right choice for exploration, ad-hoc questions, and prototypes – see LLMs and Event Streams. What proves valuable in conversation can later become part of a pipeline.

Designing for Analysis#

Everything in this stage depends on the quality of the events. Events that name what happened in the language of the domain, that record decisions and not just their results, and that are versioned with care stay useful for analyses nobody has imagined yet. Events that merely mirror database updates – status-updated, record-changed – lose most of their value the moment someone asks why.

Design your events as if someone will want to learn from them later. Sooner or later, someone will.