# The Four Levels of Detection Maturity: L1 to L4, from threshold alerts to root cause > A detection maturity model, L1 to L4: how much of symptom detection, correlation and root cause your platform does, and how much is left to your engineers. - URL: https://blog.asama.ai/blog/four-levels-of-detection-maturity/ - Author: Sumeet Ghosh - Published: 2026-06-22 - Tags: Frameworks Detection maturity is how much of the work from a changed signal to a named root cause your platform does, and how much it leaves to you. At L1 it raises threshold alerts and you do the rest. At L2 it gathers telemetry into one place, and you still correlate it by hand. At L3 an AI layer helps you investigate, but only within the domain someone modelled for it. At L4 the platform keeps a live model of the fleet, names the cause, shows the evidence behind it, and leaves you to check the conclusion. A chassis temperature alert fires during a heavy load run. The dashboard confirms it. The node is hot. Most detection stops there. Here is what still has to happen before anyone can act on it. Inlet temperature is normal, so it is not the room. Power draw shows nothing abnormal. CPU package temperature is climbing and clocks are starting to throttle. Fan RPM is lower than it should be, which only becomes visible when the node is [compared against its peers](https://blog.asama.ai/blog/issue-11-asama-peer-comparison-is-the-baseline). The BMC audit log shows the fan performance profile was reset from performance to optimised. That reset happened six days ago, immediately after a firmware update. The firmware update reset the fan profile. That is the answer, and it is roughly eight steps past where the alert stopped. Every one of those steps was performed by a person. The alert took one second. The rest took an afternoon. > "Detection is not a signal. It is a three-step process, and most tools deliver the first step and call it the product." --- ## Three steps, two of them manual | Step | What it produces | Who does it today | | --- | --- | --- | | **Symptom detection** | Something is outside expectation on this node | The monitoring stack | | **Signal correlation** | These signals across layers belong to the same event, and these do not | Manual | | **Root cause** | This specific change, at this time, produced this symptom | Manual | Run the hot node from the opening through it. The chassis temperature alert was symptom detection, the one step the monitoring stack performed. The checks between the alert and the BMC log were correlation: inlet temperature ruled out the room, power draw showed nothing abnormal, CPU package temperature and throttling clocks showed where the heat was landing, and fan RPM, read against the node's peers, showed the cooling falling short. Root cause was the change the BMC audit log recorded: the firmware update six days earlier, which reset the fan profile from performance to optimised. Steps two and three are where the engineering hours go, and they are almost entirely uninstrumented. The industry has spent two decades getting better at step one: more agents, more exporters, more dashboards, more alerts. That work was real and it has largely succeeded. It has also left the expensive two thirds of the problem exactly where it was. --- ## The four levels The levels below describe how much of that three-step process the platform performs, and what you are left holding. | | **L1 Fragmented monitoring** | **L2 Centralised observability** | **L3 AI assisted analysis** | **L4 Autonomous understanding** | | --- | --- | --- | --- | --- | | **Platform is** | Observer | Consolidator | Assistant | Infrastructure expert | | **What it does** | Multiple tools collect telemetry independently and raise threshold alerts with limited context | Aggregates metrics, logs and traces through ecosystem connectors, makes them queryable | Indexes infrastructure knowledge for semantic search and assists analysis within a domain. Knowledge must be modelled by specialists | Maintains a live model of topology, dependencies and state. Normalises telemetry across vendors, learns baselines without authored rules, reasons about causality | | **User is** | Investigator | Analyst | Consultant | Approver | | **What they do** | Configure monitoring, triage alerts, switch between tools, correlate by hand | Build dashboards, investigate alerts, correlate signals across sources manually | Interact conversationally to retrieve and investigate, but still drive the reasoning | Review synthesised context and validate the conclusions | | **Anchors** | Zabbix, Nagios, OpManager | Prometheus with Grafana, Elastic with Kibana, Datadog | Elastic AI, Datadog with Bits AI SRE, Dynatrace with Davis AI, LogicMonitor with Edwin AI, terminal assistants over MCP | Asama | Read the user row rather than the platform row. That is where the cost sits, and it is the row most maturity models leave out. Down that row your job changes. At L1 you are the investigator, correlating by hand across tools that each hold part of the picture. L2 puts the data in one place and leaves you the analyst. The correlating is still yours. L3 makes you a consultant, questioning an assistant while you still drive the reasoning. Only at L4 do you become the approver, reviewing what the platform has assembled and deciding whether its conclusion holds. L4 is a claim about understanding, not about authority. A system that models your fleet without human authoring is a separate question from a system that acts without your approval, and the two ladders stay separate. Where authority stops is covered in [The Automation Boundary](https://blog.asama.ai/blog/the-automation-boundary). Nothing on this ladder implies anything about that one. --- ## What each step up the ladder needs A maturity model that only classifies is a scoreboard. What makes one useful is naming what it takes to move. **L1 to L2 needs a common data plane.** Everything reporting into one place with consistent identity. This is well understood, widely solved, and where most serious teams already are. **L2 to L3 needs knowledge modelled by specialists.** This is where the transition stalls for almost everyone. A conversational layer over your telemetry is only as good as the domain knowledge someone encoded underneath it, and that encoding is expensive, perishable, and specific to one layer of the stack. Teams reach L3 in one domain and then discover the effort does not transfer to the next. **L3 to L4 needs [state capture](https://blog.asama.ai/blog/issue-10-asama-the-firmware-layer-nobody-owns), [cross-vendor normalisation](https://blog.asama.ai/blog/issue-09-asama-the-heterogenous-problem-nobody-admits) and peer analytics.** None of those three arrive as a feature added to an existing platform. The dependency chain underneath the ladder runs in one direction: ``` identity → normalisation → topology → baseline → causality ``` Causal reasoning is not something you bolt onto a metrics store. It requires a topology to reason over. Topology requires normalised state across vendors. Normalisation requires stable identity for every device and component. Skip any link and the ones above it produce confident output with nothing underneath. This is why an AI layer on top of an L2 stack does not become L4. At best it reaches L3 in the domain someone modelled for it. Everywhere else it is a very fluent L2. --- ## Why this is not a single number Two cautions about using the ladder, both of which apply to us. **Score the stages independently and read the lowest, not the average.** A platform with excellent causal reasoning over a thin state model will produce articulate nonsense. A platform with rich state and no reasoning layer gives you a very good inventory. The chain is only as strong as its weakest link, and averaging across the chain hides exactly the weakness you needed to find. **Scope is a second axis the ladder hides.** Some of the deepest reasoning about hardware state in the industry today comes from single-vendor tools. NVIDIA DCGM knows more about an NVIDIA GPU than any general platform does. Dell and HPE know their own iron. Judged within their own scope, those tools reason at a level the ladder would score highly. Judged across a mixed fleet, they are blind past their own badge. So the ladder assumes multi-vendor scope, and single-vendor depth has to be scored separately. A fleet running one vendor's hardware end to end should weigh those tools very differently from a fleet running four. --- ## What the approver does Approver sounds like the weakest role on the ladder. It is not. What moves into the platform is the correlation: opening six tools, matching timestamps across them, comparing a node against its neighbours by hand, finding the change record that lines up. That work is skilled, but it is not the expertise. It is the tax the expertise has been paying to get to the question that matters. What stays is the judgement. Whether the diagnosis holds against what you know about this fleet. Whether the fix is safe on this hardware, at this firmware level, in this window. Whether the risk of acting is smaller than the risk of waiting. Whether the system has understood something about your environment that it was never told. That judgement cannot be exercised on a conclusion you cannot inspect. Handed a verdict with no evidence behind it, you become a rubber stamp, and the role collapses. This is why every finding has to trace back to the graph, log entry or state comparison that produced it, and why [confidence has to be stated rather than implied](https://blog.asama.ai/blog/trust-is-the-real-interface). The ladder is only worth climbing if the top rung leaves you able to disagree. --- ## From Asama > ### What L4 requires, concretely > A live topology graph carrying configuration state, telemetry and change history per node, not a static inventory refreshed on a scan cycle. > > Baselines learned without human-authored thresholds, tags or templates, across peer cohorts built on hardware SKU, firmware tuple, workload regime and rack position. > > Multi-vendor normalisation, so that one physical part is one object whichever vendor's tooling reports it, and the same reasoning applies to every node in a mixed fleet. > > Causal reasoning that traverses the topology graph and returns an inspectable chain, with confidence stated and missing evidence named. --- ## How to test any of this, including us The top rung of this ladder is where Asama works. Levels one through three can be assessed from documentation, because they describe what a platform collects and how it presents it. Level four is a claim about reasoning, and reasoning shows on a real fleet: ask any vendor for a proof of concept with real heterogeneity, including your oldest and newest SKUs. Ask any vendor claiming autonomous understanding to show a diagnosis on your hardware, produced without a template written for your environment. Then ask what evidence sat behind each step, and what the system could not establish. The answers to those two questions place a platform on this ladder more accurately than anything either of us could write down. --- ## Food for thought > When your monitoring finds something, how many of the three steps does it actually complete? And how many hours a week does your team spend performing the other two by hand? **Update, October 2026.** Asama's comparisons now read each score as the weighted average of its components, not the lowest stage, because the lowest stage rates 1, 1, 0, 1 the same as 4, 4, 0, 4. Components score 0 to 4, where 0 is a stage the platform does not do at all. A zero inside a score of 1.5 or more is named under it. Detection has four components: the three steps above, with correlation counted three times, and detection learning, whether the next fault of its kind is caught sooner. State capture and cross-vendor normalisation are scored as Infrastructure State, which is never averaged into detection, because state caps what detection can find. Asama works at level 4, with Dell, HPE, Lenovo, Supermicro and NVIDIA hardware in one model: it traces each fault to a root cause, and plans, runs and verifies the fix. Across 50-plus induced failures on Dell, HPE and Lenovo hardware, detection took 8 to 50 seconds. To see where your current tools sit on this ladder, book a live comparison against your stack at [asama.ai](https://www.asama.ai), or write to contactus@asama.ai.