# Trust Is the Real Interface: what makes an AI root cause analysis checkable > An AI root cause analysis earns trust when you can check it: findings tied to evidence, confidence stated with its gaps, and overrides that change the answer. - URL: https://blog.asama.ai/blog/trust-is-the-real-interface/ - Author: Sumeet Ghosh - Published: 2026-06-10 - Tags: Frameworks An AI root cause analysis earns trust when you can check it in minutes. Every finding points at the graph, log entry or device output behind it, and the answer states its confidence and names the evidence it could not get. Its causal chain still holds when restated for a change board. And when you override it, the next answer changes. When an AI system tells you a DIMM is failing, you do not want it to explain its reasoning. You want it to show you why it thinks that. The two sound similar and they are not. One produces a description of how the system arrived somewhere. The other produces the evidence that a specific component, in a specific slot, on a specific node, is going bad. For the DIMM, that is the slot named, its corrected-error count climbing in the kernel's EDAC counters, and the memory ECC entries the BMC logged for the same slot. The first answer cannot be acted on, and it cannot be defended to whoever asks why the node was pulled. This is the gap that kills adoption of technically correct systems. A platform can detect better than anything a team has run before, reach the right conclusion faster than a senior engineer would, and still be quietly routed around within a quarter. Not because it was wrong. Because nobody could tell, in the moment, whether it was right. > "Correctness is a property of the system. Trust is a property of the relationship. The first does not produce the second, and infrastructure teams have learned to tell them apart." --- ## Evidence, not narrative The most common failure in AI infrastructure products is answering with a story. A well-written paragraph explaining that a node is degraded, what probably caused it, and what to do about it reads as intelligence. It is also unfalsifiable. You cannot separate what came from measured telemetry from what came from plausible inference, and once you cannot, the only rational response is to verify all of it yourself. At which point the system has saved you nothing. The alternative is to structure the answer so every claim points at what produced it, as the DIMM evidence does. For a storage diagnosis, that looks like this: | Finding | Backed by | | --- | --- | | The array was busy servicing I/O during the window | Utilisation graph | | Queued I/O accumulated, so this is storage, not CPU or memory | Queue depth graph | | The array was in recovery at the time | Raw device state output | | The maintenance job and the application ran concurrently | Live process listing | You do not have to accept the conclusion in order to use it. You can check the third row, decide it holds, and move on. Or check it, find it does not, and reject the whole diagnosis in ninety seconds rather than reproducing the investigation from scratch. Checking the third row means reading the array's state as it was captured during the window. On Linux software RAID that is two lines of `mdadm` output, in the same format the command gives you: ``` $ sudo mdadm --detail /dev/md0 | grep -E 'State :|Rebuild Status' State : active, degraded, recovering Rebuild Status : NN% complete ``` Had the State line not said recovering, the third row would fail. So would the diagnosis. The quick rejection is the case that decides adoption. A system that is efficient to disagree with is a system that stays in the workflow. --- ## Confidence is part of the answer The second failure is uniform certainty. Two diagnoses from the same fleet, in the same week. In the first, a storage array was rebuilding while a filesystem discard job ran concurrently, application I/O queued behind both, and an API slowed down. All three were directly observed and the alternatives excluded. Confidence: high. In the second, receive-buffer drops on a NIC spiked, kernel receive-processing pressure spiked in the same minute, and a large inbound burst occurred during the same hour. The mechanism was confirmed. The trigger was not, because the peak timestamp of that burst had not been retained, so the alignment could not be established. Confidence: medium, with the reason stated in the answer. A system that reports both with the same tone has taken something from you. Not accuracy, calibration. You can no longer tell which conclusions to act on and which to spend twenty minutes verifying, so you either verify everything or trust everything. Both are worse than where you started. Naming what could not be established is the harder half. Attaching a percentage to a conclusion is easy. Writing, inside the answer, that a specific piece of evidence was missing and the conclusion is weaker for it is not. Read that sentence first: it shows the system modelling its own blind spots rather than pretending it has none. --- ## Reasoning that survives restating There is a test for whether a diagnosis is real, and it is not a technical one. Take the same finding and ask for it in another register. The storage case, restated for an executive: two background maintenance jobs competed for the same disk capacity, the storage layer could not answer application requests quickly enough, and response times rose. Same mechanism, same causal chain, same recommended actions, none of the counters. Nothing had to be softened to make that translation, because the reasoning underneath was a chain of physical events rather than a statistical assertion. A diagnosis built on correlation alone does not survive this test. Strip out the metric names and there is nothing left to say. You are rarely the last person a diagnosis has to convince: it has to go to a change board, a customer, or a vendor whose hardware is about to be blamed. A finding that cannot be re-expressed for those audiences never leaves your terminal, however correct it was. --- ## Override, and what the system does next Trust is also a question of what the system does when you disagree with it. You must be able to reject a diagnosis, decline a plan or stop an execution, and none of those should need an escalation. That is the baseline. The revealing question is what the system does next. A rejected diagnosis is information. It says that the [model of normal on that node or cohort](https://blog.asama.ai/blog/issue-11-asama-peer-comparison-is-the-baseline) is wrong in a way that produced a false positive, or that you know something the system does not, and either way it is a signal about the system rather than about you. It should change the next answer. If it does not, your judgement is being logged rather than used, and judgement that changes nothing soon stops being offered. This is also the argument for starting read only. Onboarding is detection and diagnosis only, and [execution privileges per class of action](https://blog.asama.ai/blog/the-automation-boundary) are designed to come afterwards. That reads as caution and is partly that. Mostly it is sequencing. The first weeks are when the system knows least about the fleet and the fleet knows least about the system, and asking for authority before either is true is asking for trust to be granted rather than earned. --- ## From Asama > ### Designed to be checked > > Asama is designed to answer this way: > > - Every diagnosis a set of findings, each traceable to the graph, log entry, state output or process listing behind it, with the evidence open to inspection rather than summarised > - A confidence level on every diagnosis and, where it is not high, the reason, with missing evidence named in the answer rather than left out > - Root cause expressed as a causal chain across layers, so the same finding can be restated for an engineer, a change board or a customer without changing what it claims > - Read only at onboarding, with execution privileges granted per remediation class under credentials you control and can revoke --- ## The cost of stating uncertainty A system that [states its uncertainty](https://blog.asama.ai/blog/determinism-probability-and-the-limits-of-observability) will sometimes look less impressive than one that does not. In a side-by-side demo, "medium confidence, and here is the evidence we could not obtain" loses to a confident declarative sentence almost every time. We think that is a cost worth paying, because the demo is thirty minutes and the deployment is years, and a system that has overclaimed once is checked manually forever. The vocabulary around AI infrastructure is doing the opposite. Autonomous investigation, root cause in minutes, self-healing. Some of it will turn out to be true. All of it is being asserted at a confidence the underlying systems have not yet earned, and the reckoning will land on everyone in the category, including the products that were careful. The alternative is slower and duller. Show the evidence. State the confidence. Name what you could not establish. Make it cheap to disagree with you. --- ## Food for thought > When your monitoring tells you something is wrong, how long does it take to find out whether it is right? Is that number getting better or worse as the tooling gets smarter? **Update, October 2026.** Asama's fleet visibility is generally available, and detection built on it has been validated; investigation and remediation are expanding. About 70% of Asama's root-cause work is deterministic correlation and statistical inference; agentic reasoning then takes those results and the raw evidence and writes the causal chain, and when Asama can't read something, it says so. Its [security architecture](https://blog.asama.ai/blog/asama-ais-compliance-journey-building-trust-through-architecture) separates planning from execution: the SaaS plans and never touches your infrastructure, an executor on your premises accepts only signed, in-scope manifests, BMC credentials stay in your own Vault, and on day one your engineers approve every plan. To check a diagnosis against your own fleet, book a live comparison against your stack at [asama.ai](https://www.asama.ai), or write to contactus@asama.ai.