Adaptive Root Cause Diagnosis: A Knowledge Graph That Updates What It Believes

A production parameter moves outside its expected range. The operator must work out what caused it, what to check, and what corrective action to take often while the production process is still running.

The organisation already knows a great deal about how to answer that question. Experienced specialists know the likely causes. Correction rules capture much of that knowledge. Historical incidents contain another source of evidence.

The problem is that these sources of knowledge do not naturally learn from one another. We wanted the next diagnosis to benefit from the outcome of the previous one. That requirement changed architecture.

This work was delivered in process manufacturing, where production follows a defined process and each stage has a set of quality parameters that need to remain within specified limits. When a parameter drifts out of range during production, the operator has to determine what caused the deviation and what to do about it.

Before this system was introduced, that decision was supported primarily by two things: a set of written correction rules, and escalation to one of a small number of technical specialists who carry much of the causal model of the process in their heads. The specialists are accurate, but there are only so many of them.

What we built sits within the operator’s existing chat interface. The operator describes the deviation in plain language; the system returns the likely root causes, ranked, together with how to check each one and what corrective action to take.

The rest of this article is about the reasoning engine underneath that answer.

Root cause diagnosis rarely works like a lookup. For the same observed deviation, there may be five or six plausible causes. Which one should be investigated first can depend on the site, process configuration, operating context and what has historically been observed there.

A static rule set can capture the initial causal knowledge well:

What it cannot naturally capture is how that knowledge should change after deployment.

Suppose experts initially believe Cause A is the most likely explanation for a particular deviation, followed by Cause B. That is a perfectly reasonable starting point. Now imagine the system is used repeatedly at one site and confirmed resolutions begin showing Cause B much more often than Cause A. Nothing is necessarily wrong with the original expert knowledge. The local operating environment is simply producing evidence that the ranking should be different.

In a conventional rule-based system, somebody eventually has to notice the pattern, review the rules, agree that the evidence is sufficient and change the ranking manually. We wanted that evidence to become part of the diagnostic system itself.

The requirement was therefore not simply to digitise the existing correction rules. It was to preserve expert knowledge as the starting point, expose it through an Agentic AI experience, and then allow confirmed production outcomes to progressively update the system’s belief.

That distinction became the central design decision.

The transactional data was already suited to a relational model, and we kept it there.

The problem was using the same model for knowledge whose relationships carried information and could change shape over time.

Consider the actual question behind a diagnostic request:

Given this deviation, at this site, under this process configuration, what are the most likely root causes based on what we currently know? How do I validate each one, what corrective action should I take, and which procedure governs it?

A relational implementation can answer that question. But it requires traversing multiple many-to-many relationships across deviations, candidate causes, diagnostic checks, corrective actions and procedures, while applying the appropriate site and configuration context.

The causal relationship itself also has state. A candidate root cause might be strongly associated with one deviation and weakly associated with another. The current belief might come primarily from expert judgment, or it might now be backed by hundreds of confirmed observations. It may apply generally or only in a particular context.

As the knowledge evolves, its shape evolves too. If two root causes are repeatedly confused, for example, a new diagnostic check may be introduced specifically to distinguish between them. If a relationship originally believed to be general turns out to behave differently in one operating context, its scope needs to change.

These are natural graph operations. So we moved the diagnostic reasoning layer into a Knowledge Graph in Neo4j, while leaving transactional data in the relational system of record. This was not about replacing relational technology with graph technology. It was about giving each a workload that matched its strengths.

Figure 1. The same diagnostic question represented as relational joins and as a connected Knowledge Graph traversal.

The Knowledge Graph represents the process and diagnostic entities required for root cause analysis: procedures, process phases, parameters, observed deviations, candidate root causes, corrective actions, sites and resolved events. But representing those entities as nodes was the straightforward part. The more consequential decision was what we stored on the relationships between them.

At the centre of the graph is the relationship between an observed deviation and a candidate root cause. That relationship carries the current confidence score, the evidence count behind that belief, its source, its scope, and the process configuration to which it applies.

The graph therefore does not merely know that Deviation X can be caused by Cause A. It can represent how strongly we currently believe that relationship, how much evidence supports it, where that belief came from, and the context in which it applies.

Starting from an observed deviation, the system can retrieve ranked candidate causes, move from those causes to the checks that distinguish between them, and then to the appropriate corrective actions and procedures.

We implemented parameterised traversals for those core diagnostic paths, together with a graph coverage query. The coverage query handles an important failure mode: distinguishing between ‘none of the known causes currently has strong evidence’ and ‘this deviation was never properly connected into the causal model.’ Those are not the same answer, and a production diagnostic system should not silently confuse them.

Figure 2. Knowledge Graph schema for root-cause diagnosis, with the causal relationship carrying belief, evidence and context.

The Knowledge Graph is exposed through a diagnostic tool invoked by the Agentic AI orchestration layer. This boundary was deliberate. The operator can describe the issue conversationally, and the agent can manage the interaction and determine when the diagnostic capability should be invoked. But the LLM is not asked to manufacture the most likely root cause from its own parametric knowledge.

The diagnostic tool queries the Knowledge Graph and returns structured candidate causes, rankings, evidence and resolution paths. The responsibilities are intentionally separated: the LLM handles interaction and orchestration; the Knowledge Graph holds connected causal knowledge; and the Bayesian ranking layer determines how strongly the evidence supports each candidate cause.

Before the Knowledge Graph existed, the agent already had access to a deterministic diagnostic capability through a defined tool interface. The graph-backed implementation preserved that contract: the same invocation pattern and compatible response structure, but with a different reasoning engine underneath.

The agent did not need to know that its diagnostic engine had changed. Enterprise AI architectures will evolve. Models will change. Retrieval approaches will change. Reasoning components will change. If those capabilities sit behind stable contracts, the orchestration layer does not have to be rebuilt every time one component improves.

Figure 3. A stable diagnostic tool contract allowed the reasoning engine to change without redesigning the agent orchestration.

An adaptive system creates an uncomfortable question before it ever reaches production:

What does it know before it has learned anything?

Starting from zero was not acceptable. The deterministic system already contained useful domain knowledge. Replacing it with a system that initially produced weaker recommendations and asking users to wait while it learned would have been a poor migration strategy.

We therefore used the existing expert knowledge as the starting belief of the new system. For each observed deviation, the candidate root causes form a categorical distribution. Expert judgment was represented formally using a Dirichlet prior, with pseudo-counts encoding the relative strength of that judgment.

A cause considered highly likely by the domain experts receives a stronger prior. A cause considered possible but less likely receives a weaker one. As confirmed outcomes accumulate, those observations are added to the prior evidence and the posterior confidence is recalculated:

confidence(cause) = (α_prior + confirmed_count) / Σ(α_prior + confirmed_count)

The important result is not the equation. It is the migration path the equation gives us.

On day one, the adaptive system can behave like the trusted deterministic system it replaces. There is no cold-start period in which users have to tolerate deliberately inferior recommendations. But day one is also the last day on which the new system has to rely entirely on what was known before deployment. From that point onward, confirmed outcomes begin contributing evidence. Expert knowledge establishes the prior. Production experience updates the belief.

Figure 4. Illustrative example of posterior confidence changing as confirmed outcomes accumulate. Figures are illustrative, not client data.

When a diagnosis is resolved, the operator is asked to confirm the actual root cause from the leading candidates. We placed that confirmation inside the existing workflow rather than creating a separate feedback process. An adaptive architecture is of little value if its feedback loop depends on users consistently performing an additional task that sits outside their normal work.

The confirmed outcome is written to the transactional store. A scheduled process then identifies the affected causal relationships, incorporates the new evidence, recomputes their posterior confidence and writes the updated scores back into the Neo4j Knowledge Graph. Nothing is retrained. There is no ML model that has to be retrained every time enough new incidents accumulate. There is no new model artifact to package and redeploy for each update to the ranking.

Because of the conjugate Bayesian formulation, the update is arithmetic: increment the relevant evidence and renormalise the distribution.

The application code can remain unchanged while the belief represented in the Knowledge Graph changes. The expert prior might initially rank Cause A above Cause B for a particular deviation. At one site, however, operators repeatedly confirm Cause B. Those confirmations become evidence. As they accumulate, the posterior ranking changes.

The next operator who encounters the same deviation benefits from what previous operators discovered – without somebody rewriting the rule and without a model retraining cycle. The Knowledge Graph starts with how the process is expected to behave and gradually learns how that operating environment actually behaves.

That is the feedback loop we wanted from the beginning.

Figure 5. The production feedback loop: confirmed outcomes update Bayesian confidence and the derived Knowledge Graph reasoning layer.

An adaptive ranking creates another problem: a probability can look more authoritative than the evidence behind it.

An 80% confidence score backed largely by an expert prior is not equivalent to an 80% confidence score supported by two hundred confirmed outcomes. Returning only the number would hide that distinction. The diagnostic response therefore includes the evidence count, source type and scope alongside the confidence. If the evidence count is below a configured threshold, the system can indicate that the ranking still relies primarily on expert prior rather than substantial observed evidence. This gives the agent enough information to communicate not only what the system believes, but also how much evidence that belief has earned.

The threshold itself is configurable. That is important because there is no universally correct number of observations after which a recommendation becomes trustworthy. The acceptable evidence level depends on the environment and the consequence of acting on an incorrect diagnosis.

We wanted uncertainty to remain visible rather than being hidden behind a precise-looking probability.

Neo4j is not the system of record in this architecture. Transactional information remains in the relational database, where it belongs. The Knowledge Graph is a derived reasoning layer containing causal structure and the current belief associated with those relationships.

Its state can be reconstructed from the expert priors and confirmed-outcome history. That gives us a useful operational property: the reasoning state is not an opaque artifact that exists only inside the graph.

It is also possible to understand why a cause ranked first at a particular point by examining the evidence that had accumulated by then. The same restraint applies to Agentic AI. The fact that an LLM sits in the interaction layer does not mean the LLM should perform every kind of reasoning in the system. Here, causal ranking is better grounded in explicit domain knowledge and observable evidence. And there are cases where we would not build this architecture at all. If the causal structure is small and rarely changes, a deterministic rule set may be sufficient.

More importantly, if nobody eventually confirms what actually caused the problem, there is no meaningful feedback signal. In that situation, an adaptive Bayesian layer cannot manufacture evidence that does not exist.

A Knowledge Graph without relationship-rich reasoning, or an adaptive system without a functioning feedback loop, adds sophistication without necessarily adding value.

The system described above is in production. What follows is the next stage of development. Today, the primary reasoning path focuses on an individual diagnostic event. As the history of resolved events grows, the next opportunity is to reason across cases. A resolved event can connect the deviation that was observed, the cause that was ultimately confirmed, the corrective action taken, the operating context and the effort required to resolve it.

With sufficient history, that opens several additional questions. The first is context-conditional weighting. If one site or process configuration develops a materially different root-cause distribution from the general model, there may eventually be enough evidence to maintain a more localised ranking.

The second is resolution cost. The most probable root cause is not necessarily the most efficient one to investigate first. If one cause takes several hours to validate while another can be ruled out in minutes, the optimal diagnostic sequence may need to consider expected cost as well as probability.

The third is patterns across incidents. If certain causes repeatedly co-occur, the graph may expose a common upstream driver that is difficult to see when incidents are investigated independently. But there is an important qualification. The architecture makes these questions possible; it does not make sparse data statistically meaningful.

Co-occurrence analysis based on a handful of events can produce attractive but unreliable patterns. Highly granular context-specific ranking has the same problem.

Those capabilities should only become part of the diagnostic reasoning once the accumulated evidence supports them.

The system was built for root cause diagnosis in a process manufacturing environment, but the underlying engineering pattern applies more broadly wherever expert knowledge exists and the eventual outcome can be confirmed.

1. 01
   Represent connected causal knowledge explicitly.When reasoning requires moving between observations, causes, checks, actions and context, a Knowledge Graph can make those relationships first-class.
2. 02
   Put belief on the relationship.A causal connection becomes more useful when its confidence, evidence, source and scope travel with it.
3. 03
   Do not throw away expert knowledge to make a system adaptive.Encode it as the prior and allow production evidence to update it.
4. 04
   Launch at parity where possible.A learning system is easier to adopt when users do not have to accept a temporary reduction in quality while it gathers data.
5. 05
   Close the feedback loop inside the workflow.Every confirmed outcome is an opportunity to make the next recommendation better.
6. 06
   Make evidence visible.Confidence without evidence can create false precision.
7. 07
   Keep specialised reasoning behind stable tool contracts.The agent should be able to use a better reasoning engine without being redesigned around it.
8. 08
   Use each technology for the job it is good at.The relational database remains the transactional system of record. Neo4j represents connected causal knowledge. Bayesian inference updates belief. The LLM orchestrates the interaction.

The precondition is simple but non-negotiable: the process must eventually tell you whether the diagnosis was right.

Where that happens – equipment and service diagnostics, quality investigation, incident response, claims adjudication and other forms of operational triage – the same pattern can be applied with a different domain model.

Where it does not, a well-maintained deterministic system may still be the better engineering choice. The interesting question is not whether an AI system can make a recommendation. It is what the system does when reality tells it that recommendation was wrong.