CHAIN is a maturity model for measuring reflectivity in Observable Reflective Architectures. It helps you capture what happened and why, by linking outcomes back to causes. Take the term chain literally. Each link represents a step in how and why the system changed from one state to another. If a single link is missing, the explanation breaks. The system becomes harder to understand, and eventually harder to trust.
CHAIN is a new model, created specifically to guide ObzenFlow’s development. It’s not an established industry standard. CHAIN and ObzenFlow shape each other. The model gives us a framework to be honest about tradeoffs, and the implementation tests whether the theory holds. ObzenFlow doesn’t sit at the highest maturity level in every category. In some, it’s still emerging. We’ll be transparent about that as we go.
This matters because, as Leslie Lamport notes in his Turing-Award-recognized work on distributed systems (including TLA+ and logical clocks), to paraphrase, “a bug occurs when a system reaches a state that violates an invariant.”
An invariant is a predicate over the system’s state that is true in the initial state and preserved by every valid transition. For example, if we declare that a bank account balance must never be negative, then any state where the balance drops below zero represents a violation of that invariant, which is a bug in the system’s logic as it violates the system’s spec.
For safety properties, TLC explores all reachable states in the model, looking for one in which an invariant is not satisfied or deadlock occurs (there is no possible next state).
In essence, we can think of every failure in a system as the result of a transition between states that should never have happened according to the system’s spec. This means that if we can trace all state changes and understand the invariants they rely on, all the way from the beginning of time until now, we gain visibility into how the system makes decisions, if its logic consistently enforces its spec over time, and why certain outcomes unfold the way they do.
Yet most systems aren’t built to offer that level of clarity. To change that, teams need a practical model they can follow. CHAIN provides that model. Each link plays a specific role. Together, they form the foundation for systems that can be understood, explained, and trusted.
The CHAIN Links
Each link addresses a different dimension of reflectivity. The following chapters explore each one in depth.
Causality
Current state can always be reconstructed through state changes.
- Causality must be preserved
- No gaps in connecting commands to consequences across services and time
- Expose why something happened, and connect that why (and all related whys)
History
Past state should accumulate, not vanish. Facts must survive time, failure, and refactoring.
- History must be durable
- Persist all state transitions, not only the current snapshot in time
- Overwriting the past should be treated as data corruption
Agency
Agency belongs to humans, services, and AI. The system must know who (or what) took action.
- Record agency clearly
- Log who acted, under what authority, and in what context
- Treat both human and machine actors as first-class citizens, but trust no one
Intent
Intent may be rational or unpredictable. It can come from experts, automation, or hallucinating AI.
- Capture intent explicitly
- Make goals visible, whether human or machine, external user or internal service
- Observing behaviour is not the same as understanding motivation
Narrative
The system should tell a coherent story of what happened, why it happened, and who made it so.
- Narrative must be reconstructable
- Stitch together causality, history, agency, and intent into a human-readable chain
- A system that cannot explain itself is a system that cannot be trusted
From Observability to Reflectivity
The five CHAIN principles – Causality, History, Agency, Intent, and Narrative – work together to guide architecture in support of “observable, reflective architectures”, or ORA, which we covered in the previous chapters.
In essence, CHAIN helps us build systems that are not only observable, but also reflective by design.
- Observability tells us what happened. Think metrics, logs, traces, and events that describe a system’s behaviour.
- Reflectivity goes deeper. It helps us understand why something happened. Reflective systems encode context, decisions, and intent as first-class citizens. They expose the reasoning behind change rather than emit raw telemetry.
This shift from raw visibility to structured understanding is what CHAIN enables.
The Maturity Model
Each CHAIN link has five maturity levels, from Level 0 (absent or opaque) to Level 4 (enforced and verifiable). The following chapters explore each link and level in detail.
| Link | L0 | L1 | L2 | L3 | L4 |
|---|---|---|---|---|---|
| Causality | Opaque | Single-Writer Journals | Causal Linking | Graph Navigation | Enforced Causality |
| History | Basic Archival | Durable History | Deterministic Replay | Evolvable History | Time-Travel Provenance |
| Agency | Unattributed | Logged | Bound | Authorized | Verifiable |
| Intent | Implicit | Described | Attached | Modeled | Validated |
| Narrative | The Blank Page | Operationalized Speculation | Structured | Reconstructable | Explainable |
You don’t need to reach Level 4 across every dimension. The model helps you assess where you are, decide where you need to be, and make incremental progress. Some systems will prioritize Causality and History for audit requirements. Others will focus on Intent and Narrative for AI accountability. CHAIN gives you the vocabulary to have that conversation.
So let’s begin where all reasoning starts, with cause and effect.