Core Thesis: The observability industry has exploited the concept of “unknown unknowns” to turn boundless data collection into a lucrative business model, shifting away from sound engineering principles. While capturing wide, high-cardinality events originally served to prevent the premature loss of useful telemetry, it has evolved into a culture of data hoarding driven by the fear that any uncollected attribute might be crucial in a future, unforeseen incident. Because there is no natural constraint or principled stopping point to what might be useful, this cycle of “unbounded description” and “unbounded fear” traps organizations into perpetually expanding their telemetry surfaces, ultimately benefiting the vendors who monetize this endless stream of uncertainty.
Observability has long urged engineers to gather every detail: every request, span, log, metric, operation, service, and dependency. Collecting everything about everything captures the true meaning behind the wide-event movement.
A conventional telemetry system has at least one natural constraint: the amount of activity occurring inside the system. There are only so many requests, database calls, queue operations, jobs, model invocations, and network exchanges taking place. Wide events break through that constraint. Once every operation can carry an arbitrary number of attributes, the potential telemetry surface becomes effectively unbounded.
Why stop at 20 attributes? Why not 100? Why not 1,000?
Add the deployment. Add the Kubernetes labels. Add the cloud tags. Add the customer. Add the feature flags. Add the runtime configuration. Add dependency metadata. Add security attributes. Add business metadata. Add request context. Add the model prompt. Add retrieved documents. Add tool calls. Keep going.
If the justification is that something might be useful later, there is no principled stopping point. You could eventually justify capturing half the machine. And the industry calls this sophistication. It is closer to an admission of failure.
The Why of data hoarding
There’s a valid technical history here. Traditional metrics were rigid. You had to decide beforehand what to measure, which dimensions to retain, and which aggregations to calculate. When an incident arose that didn’t align with those assumptions, the missing distinction simply vanished. You couldn’t ask a new question of information you had already discarded. High-cardinality events addressed this limitation. Keep more dimensions. Delay aggregation. Preserve the ability to ask questions that were not anticipated when the instrumentation was written. That seemed useful.
The issue arose when a solution to premature aggregation became an architectural philosophy of perpetual non-discrimination. The initial lesson was to avoid destroying useful distinctions until you understand their significance. Instead, it became to maintain every distinction because you might never know which one will gain importance. This shift matters. Rigid metrics risked discarding information too early. Wide-event thinking creates an architecture with almost no internal pressure to discard information, and it has no meaningful natural ceiling.
“Unknown Unknowns” Is the Perfect Fuel
The strongest defense of wide events is the appeal to unknown unknowns. You do not know what the next incident will look like. You do not know which dimension will distinguish the failing requests. You do not know which question the engineer will need to ask. Therefore, preserve as much as possible.
Look carefully at the structure of that argument.
- Unknown unknowns represent unbounded possibility. → Almost anything might happen.
- Wide events offer unbounded description. → Almost anything can be turned into an attribute.
Those two ideas fit together remarkably well. Anything can happen, so anything may matter. Therefore, anything may deserve representation. Therefore, anything may deserve collection. There is no stopping rule inside that logic.
You can’t prove that attribute XYZ will never be relevant. You can’t prove that a configuration piece will never explain a future outage. You can’t prove that a currently irrelevant relationship won’t become decisive during an unforeseen event. Therefore, every omission, whether through sampling, transformation, aggregation, deletion, or compression, can be seen as a risk exposure. What if the removed item was the one we needed? This question cannot be definitively answered because the item being referenced is inherently unknown. This is where the concept of unknown unknowns transcends its engineering significance and becomes a potent economic tool.
An uncertain future provides an endless justification for ever more growing data collection.
Unbounded Description Meets Unbounded Fear
There are two expanding spaces operating together.
The first is the space of possible description: attributes, dimensions, labels, tags, payloads, relationships, metadata, configuration, execution state, business state, user state, infrastructure state. The second is the space of possible futures: incidents, correlations, questions, failures, edge cases, emergent interactions, operational surprises.
The more possible futures you imagine, the more attributes appear worth retaining. The more attributes you make available, the more future questions become imaginable. That creates a reinforcing loop: unknown possibilities lead to fear of missing data, which in turn prompts a broader data collection. This expanded collection increases the representational possibilities, making it more conceivable that there are still unknown possibilities.
Wide events are where unbounded description and unbounded fear become billable.
This is why the unknown-unknown argument deserves much more scrutiny than it usually receives. It is frequently presented as humility: We cannot anticipate everything. But engineering still requires boundaries.
A mature observational system should answer questions such as:
- What do we know?
- What remains uncertain?
- Which states matter?
- Which transitions matter?
- Which relationships matter?
- Which evidence distinguishes those states?
- Which information has already served its purpose?
- Which information has declining value?
- How much uncertainty is economically justified to retain?
Without such a model, unknown unknowns becomes a substitute for a theory of relevance. And when there is no theory of relevance, the safest commercial answer is always: collect more.
The Insurance Policy You Can Never Finish Buying
Wide-event observability resembles an insurer offering an ever-growing catalogue of possible coverage. You might need this. You might need that. You certainly would not want to discover during an emergency that you failed to include some obscure protection. So you add another item. And another. And another. The analogy becomes increasingly uncomfortable when we consider that serious insurance relies on actuarial models. These models are designed to estimate risk, model exposure, calculate probability, define coverage, and price classes of uncertainty.
Wide-event observability has something considerably less disciplined: We don’t know what will matter, so keep it.
There’s no adequate theory of significance that guides customers on when to stop. No robust model identifies which states are significant. There’s no language to describe meaningful transitions. No principled account explains which relationships should already exist in a system model. Furthermore, there’s no clear boundary separating operational evidence from structural knowledge. As a result, uncertainty becomes a strategy for consumption.
And ingestion becomes a bill.
The fear can never be fully satisfied. There is always another possible incident. Another possible question. Another possible attribute. Another possible missing fact. The customer is effectively buying protection against an open-ended epistemic condition: not knowing what might matter someday. That condition has no completion point.
Metadata Is Not Context
Wide events sound sophisticated because of the word context. The following is often called context. It is metadata.
service=checkout
region=eu-west-1
deployment=8347
customer=premium
feature_flag=new-payments
node=k8s-7234Human context is relational and situated.
- What is this service doing?
- What does it depend upon?
- What changed?
- What normally happens here?
- Which condition preceded this one?
- Which actors are affected?
- What state is the surrounding system currently in?
- Which relationships are relevant to the situation?
A pile of labels doesn’t provide the answers to those questions. Instead, it offers downstream material from which context can be reconstructed. This distinction is crucial. Metadata can serve as the material for contextualization. However, labeling metadata as “context” obscures the remaining work that needs to be done.
Adding more metadata doesn’t necessarily guarantee better context. It simply creates more potential relationships for humans or machines to consider. This becomes particularly significant when AI comes into play.
More attributes provide more material for reasoning, but they don’t necessarily ensure greater relevance.
Every Event Becomes a Tiny, poor Model of the World
Once records are expected to stand independently, they start carrying copies of the world around them. This leads to duplication of deployment information, infrastructure information, service information, customer information, topology fragments, and configuration. Slow-moving state gets attached to fast-moving operations again and again.
Instead of continuously maintaining a comprehensive model of the world and its changes, we repeatedly emit partial snapshots of the world along with operations. This process is repeated millions or even billions of times. This is context replication at an industrial scale. There’s a reason behind this. The telemetry system has limited memory, weak semantics, and a weak representation of state. It also has limited capacity to determine the significance of data before it reaches the backend. Consequently, every record is forced to carry enough information to survive independently.
The width of the event compensates for the poverty of the model.
“Collect Everything” Has Reached Its Logical Extreme
Traditional collect-everything observability operated primarily along one axis: collect every operation. That already created enormous telemetry volumes, but the volume was tied to activity. There are only so many operations taking place. Wide events introduce a second axis: collect everything about every operation.
Now the scaling function becomes: operations × potentially useful attributes
The first term is bounded by system activity. The second is bounded largely by imagination. That changes the economics profoundly. Collecting everything once meant every event could be significant. However, wide events make everything related to them relevant, expanding the attribute space beyond the available operation vocabulary.
This eliminates one of the few inherent constraints telemetry economics previously held.
Then You Pay to Hide What You Just Paid to Collect
Once organizations create gigantic, high-dimensional datasets, humans struggle to navigate them.
Now another product problem appears.
- How do you search all of this?
- How do you query it?
- How do you discover the right dimensions?
- How do you correlate it?
- How do you summarize it?
- How do you find the three fields that matter among the 300 you were encouraged to retain?
Conveniently, the observability platform has an answer.
You need: high-cardinality databases, sophisticated query languages, dynamic faceting, schema exploration, correlation engines, anomaly detection, query assistants, AI summaries, and investigation agents.
So the customer pays to create the complexity. Then the customer pays for the machinery required to manage it.
You collected 500 attributes so an expensive query engine could eventually tell you which three were relevant. At some point, somebody should ask why relevance was not modeled earlier. This creates a remarkably effective flywheel:
collect more → increase complexity → require stronger tooling → make more collection practical → collect more
The product increasingly solves a difficulty generated by the representational philosophy of the product itself.
AI Narration
AI now offers the industry another layer.
The telemetry data has become excessively large for human comprehension. So we feed it to a large language model (LLM). Provide the model with the traces, logs, wide events, prompts, retrieved documents, tool calls, and surrounding metadata. Finally, present it with everything. Then, celebrate when the model turns it into a single paragraph.
But the AI still has to determine:
- What matters?
- What changed?
- Which evidence is relevant?
- Which relationship is meaningful?
- Which association is accidental?
- Which condition is significant?
- What situation is developing?
The system has postponed interpretation until the most computationally expensive point in the stack.
Another issue arises when the model receives a larger input. This increased input provides the model with more potential associations, which can lead to ambiguity. Moreover, additional metadata can dilute the relevance of the information. As a result, the model receives more data but gains less clarity on what truly warrants attention.
We’ve built systems that collect vast amounts of weakly interpreted evidence and then demand another massive system to later reinterpret its significance. It’s essentially semantic debt with a GPU attached.
The Missing Layer Is Significance
Modern observability is exceptionally effective at collecting evidence. Its drawback lies in determining its significance.
A measurement like “queue_depth=12,417” serves as evidence. Understanding what queue depth signifies provides semantics. Recognizing “SATURATING” adds significance. Representing “Checkout queue is saturated” creates status. Comprehending that checkout capacity is being depleted while payment throughput is declining during launch traffic creates a situation. That progression makes all the difference: evidence → semantics → sign → status → situation.
Current telemetry architectures flatten data into records and attributes, requiring humans, query engines, statistical models, or LLMs to reconstruct the hierarchy. This leads to data growth as the system lacks mechanisms to acknowledge understanding, distinguish observations, summarize states, or highlight significant relationships.
A system that learns should compress. A system that develops semantics should become more discriminating. A system that recognizes significance should turn many observations into fewer meaningful representations.
Much of observability has been built around accumulation instead.
Wide Events Are Semantic Procrastination
This is ultimately what wide events embody.
- Interpretation is deferred.
- Significance is deferred.
- Modeling is deferred.
- Context construction is deferred.
- Situation recognition is deferred.
The system captures enough raw data to make those activities theoretically possible later. Someone else will work it out. A query. A developer. An engineer. An AI agent. Someday. That is semantic procrastination. And because deferred interpretation requires the original evidence to remain available, semantic procrastination becomes an infrastructure requirement. Then storage. Then indexing. Then networking. Then querying. Then compute. Then tokens.
Semantic uncertainty becomes billable infrastructure.
Observability Has Industrialized Uncertainty
This is the industry’s most uncomfortable incentive. Customer uncertainty justifies more collection. More collection creates greater complexity. Greater complexity requires more powerful tooling. More powerful tooling makes additional collection practical. And every stage consumes more infrastructure. The flywheel looks like this:
uncertainty → fear → collection → complexity → tooling → greater collection
No conspiracy is required. Economic systems can reward the persistence of a problem without anybody deliberately designing them to do so. The structural incentive is enough.
When vendor revenue grows with ingestion, cardinality, retention, querying, and analytical complexity, an architecture built around permanent uncertainty deserves scrutiny. Especially when it presents ever-expanding collection as an engineering virtue. Observability has built an economic model around keeping significance unresolved, justifying more evidence, infrastructure, and tooling as complexity increases. Unresolved significance feeds the entire stack.
This Is Telemetry, Not Observability
Much of what the industry calls observability is telemetry infrastructure. It records, transports, indexes, stores, retrieves, and correlates data, offering strong forensic tools. Those functions are valuable, but observation demands more. It requires discrimination, a model, semantics, and inference. It also needs some capacity to judge which change carries more weight. Ultimately, the system must build an account of its situation.
A system that cannot determine significance and compensates by retaining everything has postponed observation.
Wide events are semantic procrastination converted into billable bytes. The deeper mechanism is simple: unbounded description meets unbounded fear. The “Unknown Unknown” provides an unlimited future to fear. The wide event provides an unlimited surface on which to insure against it. And the observability platform sits between them, charging for the evidence that might someday make the unknown knowable.
A genuinely observational architecture should do something more demanding.
- It should learn what matters.
- It should build semantics.
- It should maintain state.
- It should model relationships.
- It should recognize significance.
- It should form situations.
- It should become more selective as understanding improves.
Observability aims to generate understanding. Collecting more data is valuable only when it advances that goal.