Core Thesis: Business observability cannot be reconstructed from technical telemetry alone. To understand a business while there is still time to act, its states, constraints, commitments, and available interventions must be instrumented where they actually change—in the workflows that perform the work—and then connected to the technical systems on which they depend.
At 3:20 p.m., a fulfillment operation has 18,400 accepted orders waiting for allocation. Of those, 11,200 carry same-day delivery commitments. Warehouse A can process another 6,000 units before its collection cutoff. Warehouse B has spare picking capacity but limited carrier capacity. Orders accepted from this point face a growing risk of delay, although rerouting remains possible for another 35 minutes.
This is the state of the fulfillment system. It is expressed in the language of the work itself: orders, commitments, capacity, constraints, deadlines, and available actions.
The telemetry platform sees something different. Checkout latency is rising. The inventory service is under contention. A warehouse API is returning more errors. A queue contains 40,000 messages, and a database shard is saturated.
These two views can be causally linked, but they represent different aspects of the system. Systems are inherently bounded by observers: one view describes the machinery; the other describes the operational situation.
That distinction is crucial because observability is not merely the collection of more data. A system is observable when its internal state can be deduced from its outputs over a finite duration. From this definition we establish four terms:
- Instrumentation is how a system emits local state changes.
- Reporting summarizes outcomes after the fact: revenue, conversion, SLA attainment, cost per transaction.
- Monitoring detects expected conditions and threshold breaches.
- Observability determines active states, emerging constraints, and likely trajectories of an unfolding situation.
Business metrics are for reporting.
Observability of a business system asks a different question:
what can we know while there is still time to act?
At 3:20 p.m., the fulfillment state can be determined directly from fulfillment outputs. The order book gives accepted volume. The commitment register gives delivery promises. Dispatch schedules give cutoffs. Carrier contracts give remaining capacity. When the workflow emits these facts at the moment they change, the situation is visible in real time and in the vocabulary of the operation.
Database latency alone cannot reveal the same state. To infer delivery risk from technical telemetry, the order book, commitments, schedules, and carrier capacity must be imported as external context. Technical telemetry provides genuine observability of the machinery; the delivery commitment belongs to a different observable system.
Most business-observability architectures try to bridge that gap downstream:
resource metrics → service indicators → application health → business KPI
Every arrow requires meaning supplied by the business domain. The process already possessed that meaning when the event occurred, yet its implementation emitted only lower-level records, leaving analytics to reconstruct what was lost.
In the fulfillment example, the situation arises at 3:20. The dashboard recovers at 4:00—minutes after the rerouting window has closed. The organization has incurred the cost twice: once by discarding the existing meaning, and again by rebuilding it. The result is historical data that lacks operational awareness. The situation is lost among the data.
This occurs because meaning diminishes as work transitions into implementation.
An HTTP request consists of a path, payload, and duration; the customer’s promise lives in the order’s sequence. A database write involves a key and latency; the warehouse cutoff is determined by the dispatch schedule. Consumer lag is an offset and a rate; tomorrow’s delivery commitments are embedded in the fulfillment plan.
APM, now often relabeled “observability,” has led many to believe that enough correctly correlated technical evidence can reveal the business. Distributed tracing, business transactions, and user journeys created valuable visibility into applications. But when latency, errors, throughput, and availability are grouped under a label such as “Order Fulfillment,” the dashboard still describes the systems that support fulfillment, not the state of fulfillment itself.
The architectural rule is simple: Instrument a phenomenon at the level where its state transitions occur.
CPU scheduling belongs at the scheduler. Database behavior belongs inside the database. Distributed service behavior belongs at the service level. Order fulfillment belongs in the order-fulfillment process.
Workflows are the natural instrument for business operations because they are state-transition systems:
accepted → allocated → picked → packed → staged → dispatched
As work moves through these stages, the workflow also carries promised completion times, required resources, remaining capacity, dependencies, priorities, delays, eligible routes, and possible interventions. Emitting those facts when they become true creates a live model expressed in the vocabulary of the operation itself.
This becomes especially important when we speak of capabilities. A capability is not a static label; it is the ability to achieve a purpose under current conditions. Order fulfillment depends on capacity, resources, accumulated work, alternative routes, recovery mechanisms, and time. To observe that capability is to ask:
- Can the system still meet its commitments?
- Which constraint is becoming dominant?
- How much operating margin remains?
- Which commitments are at risk?
- Which interventions are still available?
Those are questions of situation assessment, not retrospective reporting.
The aim is not to choose business observability over technical observability. The real value comes from connecting them while preserving the meaning of each level:
Business: same day commitments are at risk
Operational: allocation is below required throughput
Application: inventory reservation is degrading
Computational: database lock contention is rising
Resource: storage has entered saturationTogether these situations explain what is happening: storage saturation is increasing database contention, which is slowing inventory reservation, reducing allocation throughput, and putting delivery commitments at risk.
This suggests an architecture based not on one ever-larger hierarchy of metrics, but on connected systems of situations. Infrastructure exposes infrastructure situations. Applications expose application situations. Workflows expose operational situations. Business processes expose business situations. Each system retains the semantics of its own level; explicit relationships show how conditions propagate between them.
Business operations already contain signals, states, constraints, transitions, and intentions.
Technical observability explains the machinery on which they depend. The remaining design challenge is to represent both kinds of situation in a common structure without flattening either one. Instrument each phenomenon where its state changes. Then connect the resulting situations in a way that preserves what each level knows.