# The Four Levels of Detection Maturity > At every level the work is the same. What changes is how much of it the platform does, and how much is left to your engineers. - URL: https://blog.asama.ai/blog/four-levels-of-detection-maturity/ - Published: 2026-06-22 - Tags: Product updates 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. 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 upgrade 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." --- ## 01 — What Detection Actually Involves | 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 | Steps two and three are where the engineering hours go, and they are almost entirely uninstrumented. This is the first thing to understand about maturity in detection. 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. --- ## 02 — The Four Levels The levels below describe how much of that three step process the platform performs, and what the engineer is 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 diagnosis | Review synthesised context and validate the conclusions | | **Anchors** | Zabbix, Nagios, OpManager | Prometheus with Grafana, Elastic with Kibana, Datadog, Dynatrace | Elastic 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. 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](/blog/the-automation-boundary). Nothing on this ladder implies anything about that one. --- ## 03 — The Transitions Are the Real Content 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, cross-vendor normalisation 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. It becomes a very fluent L2. --- ## 04 — 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. --- ## 05 — What the Approver Actually Does Approver is the weakest-sounding word on the ladder, so it is worth being precise about the work it names. 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 judgment. 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 judgment cannot be exercised on a conclusion you cannot inspect. An approver handed a verdict with no evidence behind it is 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. 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 maintained equally across Dell, HPE, Lenovo, NVIDIA and AMD, so that 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 matches our own architecture. That is a reason to be sceptical of it, so here is the rule we apply to ourselves. No grade above L3 is credible on a desk review. 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 claims cannot be verified from a feature list or a scripted demo. They require a proof of concept on a real fleet, 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? --- *Asama is an AI infrastructure engineer built by operators who lived inside the problem for two decades. Our focus is MTTR. Detection is the prerequisite. Remediation is the mission.*