Observability for Insight

Observability is the first property ORA designs for. It’s how a system exposes its internal state and behaviour in a way that both humans and machines can understand. This chapter examines what observability actually requires, how the concept of wide events has reshaped the field, and how architecture can amplify observability far beyond what most systems achieve today.

Defining Observability

Observability is about whether a system can reveal its internal state and behaviour through external signals. In practical terms, a system is observable when you can answer these questions using its own telemetry:

• What happened?
• Why did it happen?
• Who or what made that decision?
• What was supposed to happen next?

Some systems are designed to expose their internal behaviour. Others obscure it through poor design choices or a lack of structure altogether. Most systems fall somewhere in between.

The observability tooling industry emerged to address this gap, and it has transformed how teams understand production systems. Modern observability platforms provide powerful capabilities for capturing signals, surfacing patterns, and helping teams reason about complex distributed behaviour. For many organisations, these tools represent the most practical path to visibility.

Even so, observability tooling faces a fundamental constraint. When state is overwritten, context is discarded, and causality is hidden at the application level, the tools are left reconstructing meaning from incomplete signals. They can surface what changed, but the why behind that change often remains elusive because the system never captured it in the first place.

Wide Events as a Substrate

Charity Majors and the Honeycomb team have been instrumental in advancing this thinking through the concept of wide events, which are arbitrarily wide structured events that capture full context about a state change in a single record.¹

This insight is foundational to ORA, CHAIN, and ObzenFlow alike. In a sense, the philosophical underpinning of everything you’re reading is a combination of immutable journals, event sourcing, and wide events. When your system captures rich, structured events with full context, every other form of observability (metrics, logs, dashboards, traces) can be derived from them. The reverse is never true. You cannot reconstruct the original event from an aggregated metric.

ORA takes this principle and makes it architectural. In an ORA-aligned system, wide events are the fundamental unit of observability. Every state transition is captured as a structured event with its cause, context, and outcome preserved. These events are durable, replayable facts recorded in an immutable journal. The same wide events that power your dashboards and alerts also serve as the system’s source of truth, available for replay, audit, and analysis long after the original request completed.

Architecture Amplifies Observability

This perspective builds on long-running concerns in distributed systems literature. In Immutability Changes Everything, Pat Helland writes that “facts are what happened”, and highlights the value of preserving historical state as immutable records rather than mutating over time.² Caitie McCaffrey, in The Verification of a Distributed System, emphasizes that traces and logs are often the only source of truth in a running system, which places operators in the role of forensic investigators rather than observers of intent.³ Martin Kleppmann, in Turning the Database Inside Out, proposes a model where systems treat logs of state changes as primary, rather than byproducts, reversing the typical flow of data to support better reasoning and traceability.⁴

When systems are designed to preserve every state transition as a durable, structured event, observability becomes a natural property of the architecture. Tooling still matters, and it matters enormously. But it operates on a richer substrate, one where every question about system behaviour has a complete answer waiting in the journal.

Observability helps you see what’s happening. But seeing isn’t understanding. The next chapter explores reflectivity, the property that allows a system to understand itself and learn from its own behaviour over time.