Perspective
Why a Knowledge Graph Is Not a Resolution Memory
Every AIOps vendor now claims a knowledge graph. They almost always mean a live map of your estate. Sentinel keeps that, and adds something further: a Resolution Memory of every incident this platform has resolved on your estate, structured as retrievable evidence for the next one.
A Live Knowledge Graph answers what is my estate right now. A Resolution Memory answers what have we already resolved and why. Both are useful. Only the second one enables autonomous action that a change board will approve.
What most vendors mean by knowledge graph
The industry-standard knowledge graph is a live map of your estate. It ingests CMDB, observability, changes and often tacit signals like ticket text or chat, and stitches them into a queryable graph of services, CIs, owners and dependencies. Kept current in near real time, it is genuinely useful. When an alert fires, the graph answers what is upstream of the failing thing, who owns it, what changed today, and whether anything similar is happening elsewhere.
It stops there. The graph is a lookup of current state, learned from streaming data. Because part of what it learns comes from unstructured human text, its edges are inferred rather than derived. A correlation the graph confidently makes from ticket comments is not something you can defend to an auditor. This is why the vendors that lead with knowledge-graph capability rarely lead with autonomous action: the substrate does not support it.
What Resolution Memory adds
Resolution Memory is a different object with a different job. Each entry is one resolved incident: the topology at time of failure, the RCA, the fix procedure that worked, the verification signal, the postmortem, and the citations Sentinel used to reach its conclusion. The memory grows one confirmed resolution at a time, not one alert at a time. It is fed by outcomes, not by chatter.
When a new signal arrives, Sentinel matches its signature against the memory before paging anyone. If the class has been resolved on this estate before, the prior RCA, the fix that worked and the postmortem are attached to the new incident record on creation. The engineer starts from a case with cited prior evidence, not a blank console. And when Sentinel proposes to act, it points to the specific past case it learned from. That is the substrate that makes autonomous action defensible.
Side by side
| Property | Live Knowledge Graph | Resolution Memory |
|---|---|---|
| Fed by | Streaming CMDB, telemetry, tickets, chat | Resolved incidents only |
| Updated | Continuously, near real time | At resolution time |
| Answers | What is upstream now, who owns it, what changed today | Have we seen this before, what did we conclude, what worked |
| Best for | Enriching alerts with current context | Grounding Sentinel's reasoning in prior evidence |
| Auditability | Weak where the graph learned from ticket text | Strong, every reference is a specific past incident with a postmortem |
| Failure mode | Wrong when ticket or CMDB text is stale | Empty when the incident class is genuinely new |
Why this matters for autonomous action
Every AIOps vendor eventually needs to answer one question: on what basis did the system decide to act. A knowledge graph that inferred a correlation from ticket text cannot answer this in a way an auditor will accept. A resolution memory that points at a specific prior incident, with the postmortem and citations attached, can. This is why Sentinel Action Tickets carry the prior case they learned from as an explicit reference, not as a confidence score.
The measured effect is a resolution-speed curve that bends over time. First occurrence is the baseline. On the next occurrence of the same class, Sentinel retrieves the prior RCA and fix in seconds, and total time to baseline drops by four to five times, without changing any of the underlying detection or execution. That gap is the substrate showing up in the metric.
What the graph still gets you
None of this is an argument against the live knowledge graph. Sentinel keeps one, populated from your ITSM (CMDB, incidents, problems, changes, service requests, assets) and observability. It is what gives Sentinel the current-state context every incident needs: who owns the affected service, what changed in the last window, which downstream customers will notice. Without the live graph, enrichment is thin. Without the resolution memory, action is undefensible. The point is that you need both.
See both views on a sample estate
The interactive demo linked from the CTA below toggles between a Live Knowledge Graph (services, CIs, teams, active alerts, changes and service requests, fed from CMDB, ITSM and observability) and a Resolution Memory (resolved incidents, problems, affected services and citations). Click any node to see how each is used during an incident. The recurrence nodes show the four-times-faster resolution effect specifically.
How Opstral does it
Sentinel writes the resolution memory automatically at incident close: the RCA object, the fix procedure that worked, the verification signal, the postmortem link, the citations used. On the next incident, Sentinel queries the memory before triage begins. When it proposes an action, the prior case is cited on the Action Ticket, along with the governance policy under which the action is permitted. That is what lets a change board approve autonomy: the substrate is auditable by construction, not by post-hoc explanation.
Frequently asked questions
Do you still have a live knowledge graph?
Yes. Sentinel populates a live estate graph from your CMDB, ITSM and observability. It is the current-state substrate for enrichment. The Resolution Memory is a second, complementary object that captures resolved incidents and their outcomes.
Why not just learn from ticket text like other vendors?
Learning from ticket text produces impressive-looking correlations that are hard to defend to an auditor or a change board. A resolution memory built from confirmed outcomes gives Sentinel evidence that can be cited, which is the substrate autonomous action actually needs.
How does the memory handle a genuinely new incident class?
It returns no match. Sentinel then falls back to first-principles reasoning against the Live Knowledge Graph (topology, changes, correlated signals), produces its probable cause with citations to those primary signals, and either acts autonomously if a policy permits it or hands the case to an engineer. When the incident closes, a new entry is written to the memory. The cold-start problem exists once per incident class.
How is this different from an SOP or runbook library?
SOPs and runbooks are hand-written for anticipated cases. Resolution Memory is auto-populated from actual resolutions, including the ones that were not anticipated. A runbook says what should be done for a known class. A resolution memory says what was done for the specific past incident whose signature matches this one. Both are useful, and Sentinel uses both, but they are not the same object.
How quickly does the four-times-faster recurrence effect appear?
As soon as the first recurrence of any incident class occurs. In practice most estates have a handful of frequently recurring incident classes that account for the majority of NOC time, and those classes see the effect within the first quarter of Sentinel running. Long-tail incident classes accumulate the effect over longer periods. The metric that captures this is the ratio of first-occurrence MTTR to recurrence MTTR, tracked per class.