The previous chapter established that observability lets you peer into a system. Reflectivity determines what the system does with that visibility. This chapter explores how systems move beyond passive observation toward genuine self-understanding.
Defining Reflectivity
Reflectivity is the property that allows a system to understand its own behaviour over time. It’s about learning from change rather than simply reacting in the moment. A reflective system can explain what just happened, trace it back to its cause, and adjust how it responds in the future. Specifically, reflectivity is the system’s ability to:
- Encode and preserve intent
- Trace cause and effect
- Expose the rationale of its decisions, not only final outputs
- Learn from its own behaviour over time based on the above
If observability is signal, reflectivity is meaning. Observability can surface patterns in a dashboard, but it can’t internalize them. Reflectivity can, for example by training a micro-model on a foundation model using real system experiences. That’s a system learning from itself. But none of this is possible without a journal of facts, from present time to time immemorial.
Value of events: they are facts. They are 100% accurate. This happened. You can’t dispute it.
Events as the Foundation
In a reflective system, events act as the foundation for reasoning and learning. They record what happened, in what order, and in response to which decision. This timeline allows the system to reconstruct its behaviour, compare outcomes, detect drift between ideal outcome and actual outcome, and then evolve. All of that depends on events becoming the lingua franca of your data substrate.
Consider a music streaming service. A reflective system builds a listener profile from facts: what was played, when, in what order, and in what context. Each interaction becomes part of the learning surface.
This is how machine learning works. Models are trained on structured features, which are built from event histories. Real-time signals influence the next decision, but they also feed back into the system to refine its internal understanding. Reflection depends on this loop. It allows the system to improve the quality of future choices by learning from past ones.
In an observable, reflective system, each state transition becomes a feature that can be used for training purposes. Each causal relationship becomes a labelled data point. A complete and well-structured event log improves the system’s ability to self-reflect.
Until now, reflectivity was possible but prohibitive. The infrastructure for machine intelligence was punishing. Hadoop clusters, MapReduce jobs, Lambda architectures with dual codebases. It required specialised data engineering expertise, and ML frameworks didn’t fit the batch processing paradigm well. Not mainstream, and not accessible, but that is changing fast.
From Events to Machine Intelligence
Events serve as the raw material for machine intelligence. When every state transition is captured with its cause, context, and outcome, the system accumulates a structured corpus that can be used to train, fine-tune, and continuously improve decision-making. This is what reflectivity actually delivers in practice.
Consider what becomes possible when your event journal is complete and causally linked.
Fine-tuning with LoRA
Train domain-specific models from your own system's decisions and outcomes.
- The journal provides labelled examples for fine-tuning a foundation model on your domain
- Low-Rank Adaptation (LoRA) trains a lightweight adapter on top of a base model
- Without a complete event history, you’re hand-labelling data or guessing
Multi-armed bandits
Learn which strategy performs best for which event profile over time.
- Events record which strategy was chosen, what context it operated in, and what outcome it produced
- A bandit algorithm uses this history to continuously improve routing decisions
- Multiple strategies (different models, prompts, or processing paths) compete on real data
Adaptive routing
Shift traffic toward strategies that demonstrate better outcomes.
- Every routing decision becomes a data point in the journal
- The system accumulates experience and shifts toward better-performing strategies for specific event patterns
- The full history needed to evaluate and compare alternatives is always preserved
Counterfactual analysis
Replay the same inputs through different logic and compare the outcomes.
- What would have happened with a different model, threshold, or prompt?
- Without events, these questions are unanswerable
- With them, they become routine
None of this is possible without events as the foundational data structure. Think about what this looks like in the alternative architectures. In a CDC-powered system, you have row diffs from a mutable database, before-and-after snapshots of state with no cause, context, or intent attached. You can’t train a model on “this row changed” because you don’t know why it changed or what decision led to the change. In an async spaghetti architecture, messages flow through queues and handlers with no durable record. The events are ephemeral. By the time you need them for training, they’re gone.
Connecting to CHAIN
This connects to CHAIN, the maturity model for such systems that we will introduce in a later series:
- Causality must be preserved
- History must be recorded
- Agency must be made explicit
- Intent must be captured before action
- Narrative must be encoded in a way the system can reason about
ORA ties these principles together, and CHAIN helps you measure your level of maturity. Their combination ensures that intent is expressed, decisions are logged, effects are linked to causes, and state transitions are never lost without explanation. It creates the groundwork for reflection.
So why isn’t reflectivity the norm already? Because the ability to truly reflect is new. Ten years ago, AI and large language models were still research projects. Now they’re productionised. You can fine-tune a model on your own system’s behaviour. Architecture is just catching up to what’s now possible.
But designing systems to be reflective doesn’t happen by accident. It requires architectural intent: deliberate choices about how state is stored, how events are structured, and how the system exposes its own reasoning. That brings us to architecture itself, and the question of what architecture actually means when you look at it honestly.