The Observability Gap: Why You Monitor Your AI at the Wrong Altitude

Your dashboards were green the entire time. That is not reassuring. That is the problem.

In March 2024, Air Canada lost a case in a Canadian civil tribunal over something its own chatbot had said.

A passenger had asked the airline's virtual assistant about bereavement fares. The chatbot told him he could book a full-price ticket and apply for a discount retroactively within 90 days. That was not the airline's policy. The chatbot had invented it.

When the passenger tried to claim the refund, the airline refused. Its defence, remarkably, was that the chatbot was a separate legal entity responsible for its own actions. The tribunal disagreed, and the airline was ordered to pay.

What interests me about this case is not the legal reasoning. It is a question nobody seemed to ask publicly.

How long had that chatbot been telling passengers things that were not true?

Not one passenger. How many? Over what period? Because the failure did not surface through monitoring. It surfaced through a lawsuit.

Every dashboard was almost certainly green. Uptime was fine. Response latency was fine. Error rates were fine. The system was healthy by every metric the platform team was tracking.

And it was confidently telling customers policy that did not exist.

That gap, between a system that is healthy and a system that is correct, is what I want to talk about this week. Because it is not a monitoring gap. It is an altitude problem. Most organizations are watching their AI systems from a level of abstraction where the failures that matter are invisible.

The three altitudes of observability Observability is not one thing. In practice, organizations observe their systems at three distinct altitudes, and most stop at the first two.

The first altitude is infrastructure observability. CPU, memory, network, container health, node status. This tells you whether the machine is running. It is necessary and completely insufficient for AI. The second altitude is service observability. Latency, throughput, error rates, saturation. The classic golden signals. This tells you whether the service is responding correctly in a technical sense. Requests are being served. Responses are being returned. Nothing is timing out. An AI system can be perfectly healthy at both of these altitudes while producing outputs that are catastrophically wrong. The Air Canada chatbot was, by every measure at altitude one and two, working exactly as designed. It received requests. It generated responses. It returned them within acceptable latency. Zero errors.

The third altitude is decision observability. What did the system decide? What information did it have when it decided? Is the pattern of decisions consistent with what the system is supposed to do? Has that pattern changed? Almost no organization has built this. And it is the only altitude at which AI failures are visible before they reach a customer, a regulator, or a courtroom. Why decision observability is architecturally different It is tempting to think decision observability is just more logging. Capture the inputs, capture the outputs, store them somewhere queryable. Problem solved.

It is not that simple, for three reasons.

The first is that decision observability requires capturing context, not just payloads. When an agent makes a decision, what matters is not only the request it received but the full state of the world it was operating in. Which data sources responded and which timed out. How fresh was each piece of retrieved context. Which version of which model was serving the request. Which tools were available and which were degraded. A logged input and output tells you nothing about whether the agent was reasoning over complete information or partial information. And a decision made on partial information can look identical to a decision made on complete information, right up until it is wrong. The second is that decision observability requires a baseline to be meaningful. A single decision, viewed in isolation, is almost never obviously wrong. The Air Canada chatbot's answer was fluent, plausible, and specific. Nothing about that individual response would have triggered an alert. The signal only exists in the aggregate. What proportion of responses reference policies that exist in the source documentation? Has that proportion changed? What is the distribution of decisions this agent is making, and has that distribution shifted since deployment? Decision observability is fundamentally statistical. It requires you to know what normal looks like before you can detect abnormal. The third is that decision observability requires an opinion about what correct means. Infrastructure observability does not require this. A node is up or down. Service observability does not require it either. A request succeeded or it failed. But you cannot observe decisions without first defining what a good decision looks like for this agent, in this context, against what ground truth. This is the part that stops most organizations. It is not a technical problem. It is a governance problem that happens to require technical implementation. Someone has to own the answer to the question: what is this agent supposed to decide, and how would we know if it stopped? What decision observability actually captures

If you are building this, four categories of signal matter most.

The first is the decision record itself. Not just the output text or the classification label. The structured decision: what action was taken, against what entity, with what confidence, at what timestamp, by which agent version. This is the atomic unit. Without it, nothing else is queryable.

The second is the context snapshot at decision time. What was retrieved. From where. How stale was it. Which upstream services responded within their expected latency envelope and which did not. Whether the agent operated with the full context it was designed to have, or a degraded subset it did not know was degraded. This is the single most valuable and most commonly missing signal in enterprise AI observability. When an agent makes a decision on partial context and does not know it, nothing downstream can detect the difference without this snapshot.

The third is the behavioral distribution. Rolling statistics on what the agent is deciding. Approval rates. Classification distributions. Confidence distributions. Tool invocation frequencies. Response characteristics. None of these tell you whether an individual decision was correct. All of them tell you whether the agent's behavior has changed. This is where intent drift becomes visible, weeks before it becomes visible anywhere else.

The fourth is the grounding trace. For any agent that retrieves information to inform a decision, capture whether the response was actually grounded in the retrieved sources or whether it went beyond them. This is the signal that would have caught the Air Canada chatbot. A response asserting a bereavement fare policy that appears in no retrieved source document is a detectable event, if you are checking. Most systems are not checking. They log the response and consider the job done.

Why platform teams must own this

There is a natural argument that decision observability belongs to the AI team. They built the agent. They understand its logic. They should monitor it.

I think this is wrong, and I think it is one of the more consequential organizational mistakes being made in enterprise AI right now.

Decision observability is platform infrastructure. It has the same characteristics as every other observability capability that platform teams already own. It must be consistent across every agent in the estate, or it produces incomparable signals. It must be instrumented at the infrastructure layer, or individual teams will implement it inconsistently or not at all. It must be independent of the team that built the system it observes, or it becomes a self-report rather than a control.

That last point matters more than the others. An observability capability owned by the team whose work it observes is not a governance mechanism. It is a self-assessment. The value of platform-owned observability is precisely that it produces an independent account of what the system is doing, one that does not depend on the builders' assumptions about what it should be doing.

The organizations getting this right are building decision observability into their platform layer the same way they built distributed tracing. Every agent that runs on the platform is instrumented by default. The signals flow into a common store with a common schema. The platform team owns the pipeline. The AI teams own the interpretation. Governance owns the thresholds.

The organizations getting it wrong are letting each AI team decide what to log. Within eighteen months they will have twelve agents in production, twelve different logging schemas, no comparable signals across them, and no ability to answer the only question that matters: is any of this behaving the way we said it would?

Your 30-day and 90-day plan

30 days: Find your altitude

Take your most consequential AI system. Ask a simple question of whoever monitors it: if this system started producing confidently wrong outputs tomorrow, at what point would we know?

Then trace the answer honestly. Would infrastructure monitoring catch it? No. Would service monitoring catch it? No. Would anything catch it before a customer complained?

For most organizations, this conversation produces an uncomfortable silence. That silence is the finding.

Then inventory what you currently capture for that system. Is there a structured decision record? Is there a context snapshot at decision time? Do you have any behavioral baseline at all? Can you answer what the agent's approval rate was in its first month of production?

Document the gaps. You now know your altitude, and you know how far you are from the altitude that matters.

90 days: Instrument the decision layer

For your highest-consequence agent, build the four signals.

Structured decision records emitted by the platform, not by the application code, with a schema that will be consistent across every future agent.

Context snapshots capturing what the agent could see at decision time, including which dependencies were degraded.

Behavioral distribution monitoring with a baseline established from the first thirty days of production behavior, and alerting when the distribution shifts beyond a defined tolerance.

Grounding traces for any retrieval-based agent, flagging responses that assert claims not present in retrieved sources.

Then establish ownership. The platform team owns the pipeline and the schema. The governance function owns the thresholds and the escalation path. The AI team owns the response when a signal fires.

At 90 days, you should be able to answer, for your most consequential agent, what it decided last Tuesday, what it could see when it decided, and whether that pattern of decisions has changed since the day it went live.

If you cannot answer those three questions, you are not observing your AI. You are watching its infrastructure and hoping.

The question for your next platform review

If our most consequential AI system started confidently telling customers things that are not true, would anything on our dashboards change?

Air Canada's dashboards did not change. The signal arrived as a legal filing.

That is what monitoring at the wrong altitude costs.

Next issue

We have covered data ownership, domain boundaries, integration coupling, non-functional foundations, and now observability altitude. Five structural conditions that determine whether AI can be trusted.

Next issue I want to examine what happens when multiple AI systems share the same platform. Multi-tenancy was an infrastructure concern. In the age of autonomous agents, it becomes a governance concern, because one agent's drift can quietly contaminate another's context.

Platform Path · Issue 07 Multi-Tenancy and AI Isolation: When One Agent's Drift Becomes Everyone's Problem

Until next week

Rupali