Every few years the observability industry rediscovers the same problem. Systems are becoming too complex, telemetry volumes are exploding, engineers are overwhelmed, and existing tooling has reached its limits.
The proposed solutions repeat a small set of forms.
- Another storage engine.
- Another correlation layer.
- Another way of searching.
The diagnosis stays consistent because we’re still counting on the same idea: that gathering and reviewing enough evidence afterward will naturally bring clarity.
The error lies in a divide—separating observability from controllability. These issues are not independent. In control theory they are formal duals: a system’s controllability matches its dual’s observability (Kalman, 1960). The industry embraced one half and overlooked the other.
Controllability here has a precise meaning, matching the definition from control theory: a system is controllable when its state can be guided toward a target using available interventions. Steering, or the control loop, expresses this activity in simpler language; controllability names the property required for that process to function.
Observation serves steering. Steering determines what should be observed. Once disconnected from steering, observability grew into an industry organized around recording execution.
A Model That Governs Observation
Notice what the word observability originally meant. In control theory it names a question: can the internal state of a system be inferred from its external outputs? Inferring state presupposes a model whose state you are estimating. The industry kept the outputs (logs, metrics, traces) and discarded the state model that gives the term its meaning.
Control engineers begin with that model. It estimates the current state of the system, compares that state with its objectives, projects where the system is heading, evaluates possible interventions, and selects an action intended to move the system toward a more desirable future. Observation earns its value from these activities.
The controller decides what information is worth collecting. It determines which signals matter, what constitutes a meaningful deviation, and which uncertainties are important enough to reduce.
Observability, as the industry practices it, took its starting point from the opposite end — from what software could emit. Logs, metrics, traces, and events became the primitive objects from which understanding was expected to emerge. Once these became the primary representation, collection expanded on its own logic, governed only by the possibility that the data might someday prove useful.
Telemetry became an objective in itself. The representation dictated the workflow: search, correlation, and forensic analysis became the dominant operations, because they are the natural operations to run on historical records.
The industry accumulated evidence at scale while understanding stayed thin.
A Representation Built for the Past
Telemetry is an unsuitable base for projection—projection in the engineering sense, which allows us to ask where a system might go, what follows if a trend persists, or what occurs if I act now rather than later. Those questions sit at the heart of every control system. But a trace captures one execution, a log captures one occurrence, a metric captures one measurement. These objects are transient, describing individual episodes in the life of the system.
Projecting a trace forward raises an odd question: another thousand spans? another log line? another HTTP request with slightly different headers? Operators do not reason at that level. They ask: Is the queue beginning to overflow? Will this dependency become saturated? Is the deployment destabilizing the cluster? Is pressure continuing to build?
These are questions about situations — the evolving condition of the system — not about individual records.
How Humans Imagine
The human brain continuously projects possible futures. We imagine conversations before they occur, anticipate consequences, mentally rehearse actions, and ask what happens if circumstances keep unfolding as they are.
The cortex projects situations. Traffic is becoming heavier. The patient is deteriorating. The meeting is becoming hostile. The child is becoming frustrated. These situations are constructed from evidence, and in the process the evidence dissolves into something more meaningful. That abstraction is what gets projected forward.
Observability assumed that replaying increasingly detailed execution histories would eventually produce this same capability. It cannot: the representation carries a state space far too large for projection to work.
Projection Requires a Different Kind of Object
Telemetry’s state space is effectively unbounded.
Every request is different, every latency differs, every user behaves differently, every payload varies, every trace contains unique details. Projecting that forward runs into an infinity of possible continuations.
Situations carry a different structure.
Queues fill. Pressure rises. Confidence falls. Replication lag increases. Capacity shrinks. Availability recovers.
These are enduring conditions.
They evolve over time, they have recognizable trajectories, they possess futures — they are precisely the kind of object a controller reasons about. Controllers operate on state variables: quantities that persist over time and carry the system’s condition from one moment to the next. A controller reasons about proximity to an undesirable operating region. That reasoning depends on a representation whose objects exist across time, persisting beyond the moment.
One Model Across Past, Present, and Future
The model used to interpret reality is the same model used to imagine the future.
It explains what is happening now, organizes what happened before, and generates plausible futures — different temporal views of a single underlying representation. When one model spans past, present, and future, reasoning becomes continuous: evidence updates the model, the model projects possible futures, potential interventions are evaluated against those futures, new evidence arrives, and the model updates again.
This is controllability.
A representation suitable for control treats observation and simulation as the same kind of object.
The object that represents the current queue is the object that represents a projected queue; the same reasoning applies to evidence from the running system and to evidence from a hypothetical future. Separate representations for observation and simulation mark a fracture in control.
Logs, metrics, and traces record completed execution, holding a representation fixed in the past tense. Control requires representations that continue living into the future, carrying the continuity that projection depends on.
The Limits of AI Alone
This explains the limits of AI’s impact on observability.
Large language models search telemetry well. They summarize incidents, correlate logs, explain traces. They are extraordinarily capable historians. But inferring a control model requires a control model to exist first.
Projecting system behavior requires a representation designed for projection.
Steering a system requires its objectives, operating boundaries, commitments, and dynamics to already be represented explicitly. Representation comes first, and reasoning inherits its limits from the object it reasons about.
Set Points and Situations
Modern software already contains control loops. Autoscalers, circuit breakers, and SLO-based alerting each close around a single measured variable and a fixed threshold: a CPU percentage crosses a line and triggers a scaling action; an error rate crosses a line and opens a breaker; a latency percentile crosses a line and burns an error budget. Each loop carries one number as its entire state, and the response fires the moment that number crosses the line.
A situation reflects a gathered state—the cluster shifting, confidence fading, saturation nearing—shaped by multiple signals across time, carrying a history and a path. This is situational awareness in the established sense: recognition of a condition, projection of where it is heading, evaluation of an intervention against that projected path.
A situation-recognition loop closes around a condition that persists across the lifetime of an incident and gives engineers something to track, discuss, and project forward together.
The two loop types differ along three dimensions. A set-point loop carries state as a single measured variable, a horizon of the current instant, and action that fires at a threshold crossing. A situation loop carries state as an assembled condition with history, a horizon of a projected trajectory, and action that follows an evaluated intervention.
If you look at what’s already out there, Kubernetes reconciliation loops are a great match for this idea: they keep track of a desired state over time and take action whenever there’s a gap between what’s planned and what’s actually happening. The main thing they manage, though, is configuration—like how many replicas a deployment should have.
This post shares a loop that matches a stated goal with the current situation—keeping the same shape but shifting what we control. The essay explores how we can take that idea from infrastructure automation and apply it to the things engineers think about most: the application and business layers.
One Incident, Worked Through
We’ve noticed checkout latency picking up right after a deployment. Our system groups this into one friendly alert—checkout-path slowing down—complete with a confidence level and a few likely culprits: a cache-miss chain, a busy downstream service, or a database migration that’s still finishing up.
Our model looks a few minutes ahead for each possibility and checks which one best meets our goal: keeping checkout delays within the target range. Two scenarios are still neck-and-neck—a cache-miss chain and downstream overload. To tell them apart, the model asks for just the right clues: the cache hit rate from the past two minutes and the queue depth at the downstream service. Instead of sending every trace and log like a standard setup would, this approach focuses only on what helps clear up the uncertainty.
The latest data points to a cache-miss cascade. Our model compares two fixes—warming the cache versus rolling back the deployment—and shows that warming the cache brings latency back under the limit more quickly.
Consequences for Architecture
Extrapolated upward, the reconciliation pattern Kubernetes runs at the infrastructure layer becomes the structure for application and business logic too: declared objectives, continuously reconciled against observed state, with action driven by the gap between the two. This reverses today’s default assumption. Today’s systems emit everything on the chance that some of it becomes useful later. A control model instead emits evidence to close a specific gap between competing explanations of the current situation, and the volume of that evidence tracks the size of the gap, falling as the model converges on an account. Telemetry emission becomes a function of the model’s own uncertainty.
A minimal version of this mechanism needs three parts: a belief state holding a probability distribution across the candidate explanations for the current situation, a probe policy that selects the measurement most likely to separate the leading candidates, and an update rule that revises the belief state as each probe’s evidence arrives.
The same architecture collapses runtime monitoring and real-time simulation into a single engine.
A control model holds actual evidence and hypothetical projection as the same object type: the belief state the probe policy updates from real measurements is the belief state the model forks forward under a hypothetical intervention, using the same transition model in both directions. Evaluating an intervention before an incident fully manifests follows from that shared object — no second, separately built simulation layer. Moving from passive, event-emitting libraries to an explicit control model asks for architectural discipline that most engineering organizations still have to plan for.
Reuniting the Twins
The future of observability grows from reconnecting it with its missing twin.
Controllability shifts the focus—from what occurred to what must be grasped to guide the system.
The signals that matter are the ones that describe meaningful changes in the system’s situation, and the situations themselves become first-class objects, represented directly in the model.
Once that relationship is restored, today’s complexity settles.
The system gains a governing representation that distinguishes significance from noise, and much of what looked like accumulating complexity resolves through that structure.
For decades observability grew more about remembering what happened, and more distant from deciding what should happen next. Reuniting it with controllability is not an innovation. It is a return to the purpose of observability.