Observability graphs should turn symptoms into testable hypotheses

An on-call AI assistant creates value when it reduces the work of connecting a symptom to a system change and the service responsible for it. That requires stable identities and evidence provenance. More logs without those relationships can simply produce a larger supply of persuasive explanations that are difficult to verify.

Netflix describes an operational ontology and knowledge graph, retaining evidence alongside investigative hypotheses. Grafana's October 20 announcements expand its Knowledge Graph: custom entities are generally available, while operational context from past incidents is in private preview. JetBrains Research's October 20 post discusses its study of differences between real agent sessions and issue-based benchmarks, emphasizing interaction sequences. Forrester discusses ContextOps as management of a production dependency. Together, these sources raise a practical question: how should a system prepare evidence for a decision?

Graphs help where identity gets lost

The same component might be an application in a catalog, a service in a trace, and a project in a deployment tool. If only a few engineers know those mappings, an agent must guess. A graph makes the correspondence explicit and reusable.

A relationship saying that a change preceded an error does not establish causality. It helps select a test. A useful investigation retains timing, source, and the basis for each relationship, while distinguishing a deployment fact from a hypothesis about its effect. An attractively named node without these properties can make a wrong conclusion more convincing.

The first deliverable may therefore be a small reliable catalog rather than an ambitious graph. For several services, agree on identifiers, owners, releases, and dependent business operations. Expand the model around recurring on-call questions. Otherwise, schema maintenance can grow faster than investigative value.

There is a genuine opportunity here for smaller teams. They do not need Netflix's infrastructure to stop repeatedly reconstructing the same mappings. A narrow model connecting one customer journey to its services and releases can provide a useful starting point, with less maintenance than a broad attempt to represent the entire company.

Incident memory changes the next investigation

A conventional final incident report often omits rejected hypotheses. Knowing that a restart failed under a similar pattern can help the next shift avoid repeating it. The conditions supporting that lesson must survive as well. A historical remedy should not silently become an automatic command for a new incident.

This connects operational context to evaluation design. A single message containing the full problem does not represent an engineer who clarifies symptoms, receives new evidence, and changes direction. JetBrains' study concerns coding agents, so its measured results cannot be transferred directly to incident response. Its methodological lesson remains useful: evaluate the interaction pattern intended for your deployment.

For an investigative assistant, useful measures include time to a testable hypothesis, correctly established relationships, and the quality of the next proposed check. Final prose alone is weak evidence. A short answer identifying the relevant service, change, and supporting record may be more valuable than a long narrative.

Evaluate counterevidence too. A good assistant should revise a hypothesis when a trace contradicts it. If a graph encourages the model to repeat a historical explanation regardless of new observations, it has become a source of inertia rather than operational memory.

Hypothetical incident: a slow customer portal

Suppose some users open documents more slowly after a release. This is a design example. An assistant observes latency, connects the affected route to a service, and finds a recent connection-pool configuration change. The incident history contains a similar event on a different database version.

A useful result proposes checking current connection waits, presents the release record, and explains the similarity and difference from the previous incident. Declaring the configuration to be the cause merely because timing matches would be premature. The graph prepares the evidence; verification supports the intervention.

Someone must own freshness. Service renames, team changes, and resolved incidents alter the model. Without maintenance, the graph becomes another obsolete directory. A managed platform can reduce some implementation effort, but GA and preview distinctions determine which capabilities can support a mandatory workflow today.

Choose between a custom model and a platform graph using the number of systems, available relationships, and maintenance cost. A large graph offers little if the common question still requires manually matching two names. Reducing that repeated reconstruction is the value a pilot can demonstrate.

Our article on the server as a system's core connects data with execution. The custom API case provides a connected-application context. You can discuss your product's dependency map, starting with one recurring investigation.