# Comparison matrix v2.0: How to compare any tool with Asama

> How to score any infrastructure tool against Asama on Infrastructure State, detection and remediation: the L0 to L4 ladders, the rules and the demo questions.

- URL: https://blog.asama.ai/blog/comparison-matrix/
- Author: Manish Gautam
- Published: 2026-09-07
- Tags: Frameworks, Comparisons

The comparison matrix v2.0 scores any infrastructure operations tool, or any stack of tools, against Asama on thirteen components in three parameters. Infrastructure State is what the platform knows about your fleet before anything breaks, detection runs from a changed signal to a named cause, and remediation runs from a named cause to a verified fix. Each component scores 0 to 4, and the number says how much of the work the platform does and how much is left to your engineers. The parameters stay separate. Version 2 of the matrix, dated 21 October 2026, sets out the ladders, the rules and the arithmetic, and corrects five cells in the comparisons we published over the summer.

## Three scores, never one

Wire a frontier model to Zabbix and detection climbs from 0.8 to 2.3 out of 4. Infrastructure State moves from 1.4 to 1.8, and all of that comes from history becoming searchable ([Asama vs Zabbix + Claude](https://blog.asama.ai/blog/01-asama-vs-zabbixclaude)). Breadth does not move. The model adds no layer, no vendor and no class of data. Add the parameters together and the pairing looks like progress everywhere. Keep them apart and you can see what happened: the reasoning layer got cheap, and it cannot buy you Infrastructure State.

Infrastructure State is the complete, current, normalised record of what every component in your estate is: its identity, its parts, its firmware and software versions, its configuration and tuning, its place in the topology, what it is supposed to be, and how it came to be that way ([Why Asama Is Different](https://blog.asama.ai/blog/why-asama-is-different)). Earlier posts call its five components Infrastructure Coverage. It is a standing asset, built continuously, while detection and remediation are work done per incident, and the record caps both: no platform correlates across a layer it never collected, or plans against state it never recorded. So the matrix is read as two plots, Infrastructure State across and a loop up.

## Who does the work at each level

Every level describes two jobs, what the platform does and what is left for your engineers, and the second column is the residual, not a mirror of the first.

| Level | The platform | Your engineers |
| --- | --- | --- |
| L0 | Does not address it | Do the whole job outside the platform |
| L1 | Supplies raw material | Do the work, and carry the knowledge in their heads |
| L2 | Consolidates and organises | Do the reasoning, faster, with better tools |
| L3 | Reasons within limits | Supply what falls outside the limits, and the judgement |
| L4 | Reasons across the fleet and down the stack | Review and approve |

Besides Asama, we have scored 23 platforms and pairings this way between July and September, 299 component scores in all. None is a 4. Twenty of those rows are unpublished and still on version 1 rules, and [Why L3 Stalls](https://blog.asama.ai/blog/why_l3_stalls) explains why extending a stack that reached 3 on the cheap components does not carry it to 4 on the expensive ones.

## Infrastructure State: what the platform knows before anything breaks

| Component | L1 | L2 | L3 | L4 |
| --- | --- | --- | --- | --- |
| Breadth: which layers, across which vendors? | Major layers, one OEM | Major layers, across OEMs | A band of adjacent layers with depth, connected, across OEMs | Interconnect and components through firmware and BMC, BIOS, drivers, kernel and OS, to the hypervisor and Kubernetes, across OEMs |
| Depth (cumulative): what is known about each part? | Events | Adds live telemetry | Adds clustered inventory and golden baselines | Adds configuration and tuning state across BIOS, kernel, firmware, drivers and device config, multi-vendor, with drift classified against an approved, evolving reference and domain knowledge per asset class |
| Normalisation: does a record mean the same thing everywhere? | Industry-standard formats (MIB-II, IPMI sensor names, the Redfish schema), or each vendor's values decoded separately: nothing comparable across OEMs | A few aspects of major components, across OEMs, within one layer | A few aspects of major components, across OEMs and a few layers | Every aspect of every component, across every layer and OEM, so one physical part is one object whoever reports it |
| Topology: what affects what? | Relationships you declared | Relationships discovered within one domain | Relationships discovered across a band of adjacent layers, kept current | A live representation of assets, components, layers, metadata, change history, dependencies and interconnectedness across the fleet |
| History: what is remembered, and when does it surface? | Raw time series and events | History with reporting, and human-written records alongside | Indexed and searchable by query or chat | Prior faults, RMA history and firmware and configuration changes for this node and its cohort, surfaced into the current diagnosis |

Sensors are not settings. Reading a BMC temperature (over IPMI, often enough, a protocol from 1998 that most BMCs still answer on UDP port 623) is breadth, while holding the BIOS attribute registry as comparable state is depth. An integration count is not normalisation either, because a platform can collect from six vendors and normalise none of them. The test is whether the block device the kernel enumerates, the bay the controller reports, the Redfish drive resource and the serial printed on the caddy label resolve to one object.

History earns its 4 only when last Tuesday's firmware change turns up in today's diagnosis without anyone asking for it.

## Detection: from a changed signal to a named cause

| Component | L1 | L2 | L3 | L4 |
| --- | --- | --- | --- | --- |
| Symptom detection: is something wrong? | Limits and triggers somebody wrote, item by item | Each signal against its own history, with nobody writing the baseline | Its own history, qualified by seasonality, change windows and workload phase | Comparable nodes under comparable conditions, firing before the node crosses any threshold of its own |
| Correlation (counts ×3): what belongs together, on what evidence? | Within one device, or along a declared relationship | Related metrics on shared dashboards, mapped by time window: signals grouped, evidence not assembled | Semantic search across tools and domains that assembles the case: scoped logs, change records, impacted configuration | An end-to-end causal chain across the whole stack, BMC, BIOS, firmware, kernel and driver state included, with history, on a live topology and across the fleet: compute, storage and network |
| Root cause and evidence: why? | Orders the signals without asserting a cause | Orders and selects the signals that bear on this incident | Several probable causes, with the evidence for each | One declared cause with its evidence chain, a confidence level and the blast radius |
| Detection learning: is the next one caught sooner? | Records outcome signals by hand: acknowledgements, false-positive flags, noisiest sources | Finds patterns in recorded failure confirmations and baselines | Folds your verdicts into what it detects and how it correlates | Keeps a live inventory of confirmations and baselines; expected anomalies are written into the state and recalled in later investigations |

Correlation counts three times because it includes evidencing, and evidencing is where the hours go. Once every signal that bears on an incident, down to firmware and BIOS state, sits in one case, naming the cause takes minutes. Two hundred alerts compressed into one incident are a different matter: somebody still opens five consoles to build the case, which is why alert deduplication changes the demo and not the week.

To score correlation, count the dimensions that built the case: time, topology, cohort, and state and change. Time alone is 2. Adding change records and adjacent topology makes 3, and all four, followed down the stack and across the fleet, make 4.

To test a root cause, ask the whys. A CPU under pressure on one host is the first, and its cores running at a fraction of their rated clock is the second, the power governor pinned in powersave is the third, the firmware update that reset it eleven days earlier is the fourth, and the other eight machines from the same procurement batch are the fifth. A cause that stops at the first two is a hypothesis, L3 at best. An L4 cause carries the last three as its evidence and blast radius, and shows its working at each step, which is what makes an analysis checkable ([Trust Is the Real Interface](https://blog.asama.ai/blog/trust-is-the-real-interface)).

Symptom detection climbs on what the node is compared with. A limit fires where somebody drew the line, and for most faults that is at or after impact. A self-baseline fires when the node leaves its own norm, and a comparison with comparable nodes before either ([Normal Is a Moving Target](https://blog.asama.ai/blog/normal-is-a-moving-target)). When a whole cohort shares the fault, as the nine machines from that batch did, only a check of their state against the approved reference sees it, and that check is scored at depth.

## Remediation: from a named cause to a verified fix

| Component | L1 | L2 | L3 | L4 |
| --- | --- | --- | --- | --- |
| Plan (counts ×3): what should be done to this node? | Suggestions for this kind of issue | Predefined runbooks or workflows, bound to the alert or device class that triggers them | Understands the problem and maps it to the right procedure from a library or your scripts, with a stated target outcome | Composes the plan at incident time against this node's exact hardware, firmware, BIOS and kernel, with preconditions and rollback |
| Act: who changes it, and what if that fails? | A single step on the target | Multi-step, with scheduling, change windows and audit, and reports failure | Multi-step with failure handling: halts cleanly and restores a prior known state | Runs its own plan in stages (dry run, canary, waves) inside maintenance policy; a failure leaves the fleet at the last verified step and triggers a new plan |
| Verification: did it work? | Reports whether the command ran and exited clean | A defined post-change check against an expected outcome: compliance re-check, re-scan, idempotent re-run | Re-compares the node with its expected behaviour and state, and surfaces degradation | Compares against the pre-incident baseline and re-validates the node against its peers |
| Remediation learning: is the next fix better? | Keeps a retrospective a person wrote | Stores the resolution as content it can retrieve | Surfaces past resolutions inside a new incident of the same class | Updates the procedure library so the next plan is better |

Remediation counts only changes to infrastructure state: hardware, firmware, BIOS, kernel, driver, OS or device configuration, or the node's state in the hypervisor or Kubernetes, such as a drain. Restarting a service or opening a ticket is housekeeping, and scores nothing. Plan counts three times because running a command is easy, and knowing which command is right for this box, on today's firmware, inside this week's change policy, is the hard part.

Act starts with one question: does the platform itself touch the machine? A ticket does not. A platform that fires a webhook into an automation tool you license and run separately scores 0 on act as well, because the capability leaves with that other licence the day you stop paying for it. A procedure for your estate is always yours, so plan and act score what the platform does with it: a platform that binds your stored script to a trigger earns plan 2 although you wrote the script.

An alert clearing is not verification. It is the detection loop running again on the same threshold, and it proves nothing about a fault that threshold never saw.

## The rules behind every score

- Score what ships, in the configuration you would buy, and name it. Our rows use each vendor's top tier with its add-ons. Triggers, templates and dashboards your engineers write are their work, and leave state and detection components where the platform alone would put them.
- Zero is a score. A component left entirely to your engineers gets 0, not 1.
- One capability, one cell. The evidence chain counts at correlation, the execution log at verification, and retained history at history. Recalling what went wrong is history; recalling what fixed it is remediation learning.
- Reasoning layers are scored as pairings, connection included. An assistant detects nothing and holds no state, so Zabbix + Claude is a row of its own, and the same model reading Prometheus is another row with a different score, because the collector underneath sets what the model can see.
- Single-vendor consoles are scored on your mix. Our rows assume three vendors in equal shares; use your own.
- Every cell carries a source, a product version or tier, and the date we checked it. Documentation and demos can support up to L3. L4 is shown on a working fleet, in a live comparison on yours or at a reference.
- Capability is not authority. The matrix scores what a platform can do. What it may do without a person is a separate decision, made one class of action at a time ([The Automation Boundary](https://blog.asama.ai/blog/the-automation-boundary)).
## Rolling up the scores

- Infrastructure State = (breadth + depth + normalisation + topology + history) ÷ 5
- Detection = (symptom detection + 3 × correlation + root cause + detection learning) ÷ 6
- Remediation = (3 × plan + act + verification + remediation learning) ÷ 6
Zabbix + Claude on detection works out as (1 + 3 × 3 + 3 + 1) ÷ 6, which is 14 ÷ 6, or 2.3. Scores are quoted to one decimal and compared unrounded, so [LogicMonitor + Edwin AI](https://blog.asama.ai/blog/01-asama-vs-logicmonitor)'s 2.67 against that 2.33 is a third of a level, though the rounded figures suggest four tenths. A gap under 0.3 means nothing: one level on a single-weight component moves a loop score by 0.17. When a component scores 0 in a parameter that averages 1.5 or more, a bold sentence under the scores names it, because an average can hide a stage the platform does not do at all.

The Four Levels post told you to read the lowest stage, not the average. Read that way, a platform scoring [1,1,0,1] on detection and one scoring [4,4,0,4] come out level. They are not. Version 2 reads the weighted average and names the zero beneath it.

Four regions recur across the 23 rows. Collectors such as Zabbix sit low on all three. Reasoning layers on thin state, such as Zabbix + Claude and LogicMonitor + Edwin AI, sit higher on detection than on state. Vendor consoles such as Dell AIOps, HPE OneView and Lenovo XClarity are deep on their own iron and blend down on a mixed fleet. Executors such as Ansible with Event-Driven Ansible score on remediation and little else. The top right corner holds one point: Asama.

## Scoring your own stack

Write your stack the way you run it, as pairings: collector, reasoning layer, executor and the connections between them. Start with the documentation. Then take one question per component into the demo.

| Component | Ask |
| --- | --- |
| Breadth | Show me a BIOS attribute for this node from your console, without SSH. |
| Depth | What is this node supposed to be set to, and where did that expectation come from? |
| Normalisation | Show me this drive as the OS, the controller and the chassis see it, without me typing a serial number. |
| Topology | This link degraded. Which jobs are affected, and how do you know? |
| History | What were this node's firmware and BIOS before the last maintenance window? |
| Symptom detection | What is this node being compared against? |
| Correlation | Which of time, topology, cohort, and state and change built this case? |
| Root cause | How many whys does this answer reach, and what is the evidence for each? |
| Detection learning | I marked this finding wrong. What changed? |
| Plan | Why this procedure, for this node, at this firmware? |
| Act | What executes the change, on whose licence, and what happens if step three fails? |
| Verification | What did you compare against before closing it? |
| Remediation learning | The fault came back. What did you reuse? |

Then walk five incidents. In each, note the why at which a person takes over:

- a fan profile reset by a BMC firmware update six days earlier, surfacing as a hot, throttling CPU;
- a power governor pinned in powersave on nine machines from one procurement batch;
- a leaf port dropping frames, so forty ranks of a training job run slow and an array shelf doubles its latency;
- a failing drive that four layers report as four different objects;
- a PCIe link that came back from a reseat at a lower generation and width, with every dashboard green.
Finally, run a pilot for 30 to 60 days beside what you have, with detection read-only. Count the faults your current stack missed. Split the clock in two, from alert to assembled evidence and from evidence to named cause, because a reasoning layer shortens the first half and only Infrastructure State shortens the second. Count the root-cause analyses your engineers accept on first read, and the hours they spend maintaining templates, triggers and dashboards. For remediation, authorise one low-risk class of change and record what executed it, what verification compared against, and whether the fault's second occurrence closed faster than its first.

## Asama, on the same ladders

Asama scores 4 on all thirteen components. The evidence published so far, from Why Asama Is Different:

| Components | Score | Evidence |
| --- | --- | --- |
| Infrastructure State | 4 | One model across Dell, HPE, Lenovo, Supermicro and NVIDIA hardware |
| Symptom detection | 4 | 50-plus induced failures on Dell, HPE and Lenovo hardware, detected in 8 to 50 seconds |
| Correlation, root cause | 4 | 26 root-cause analyses at a mid-market design partner: 20 accepted on first read and 3 more after one follow-up question. On five issues worked side by side, Asama averaged 3 minutes 20 seconds to root cause and the team's own engineers 65 minutes |
| Detection learning | 4 | Shown in a live comparison on your fleet |
| Plan, act, verification, remediation learning | 4 | Shown in a live comparison on your fleet |

A live comparison on your own fleet shows each of the thirteen. Every L4 anchor above describes the work Asama does, so decide whether L4 is work you want a platform doing before you count anyone's distance from it.

## What we got wrong in our earlier evaluations (v1.0) of competitors

Five remediation cells in our summer comparisons were too low. Our plan rule asked of Zabbix who wrote the procedure, and of LogicMonitor how it was matched. Version 2 asks both what the platform does with the procedure. Re-checking against current documentation also turned up three things we had missed.

| Row, as configured | Component | Was | Now | Why |
| --- | --- | --- | --- | --- |
| Zabbix 7.0 LTS | Plan | 0 | 2 | Actions bind stored scripts to trigger conditions: a procedure bound to the alert that fires it |
| Zabbix + Claude, through a tool server that lists and runs Zabbix's scripts | Plan | 2 | 3 | Claude reads the diagnosis and picks among those scripts, stating the outcome it expects |
| Zabbix + Claude, on a paid plan with chat search | Remediation learning | 0 | 2 | Chat search retrieves earlier conversations, so a fix worked out in one chat can be found in the next |
| LogicMonitor Signature + Edwin AI | Act | 0 | 1 | RemediationSources run your Groovy or PowerShell scripts against the target, by hand or through Action Rules and Action Chains |
| LogicMonitor + Edwin AI, with the AI Agents add-on | Remediation learning | 2 | 3 | The Similar Incidents Agent surfaces how past incidents like the current one were resolved |

Zabbix's remediation moves from 0.3 to 1.3, Zabbix + Claude's from 1.3 to 2.2, and LogicMonitor + Edwin AI's from 2.0 to 2.3, which puts the two pairings within noise of each other. Detection is untouched. So is Infrastructure State. Zabbix's act stays at 1, because its escalation steps fire while a problem stays open rather than when the last step worked, and its remote commands run even when the host is in maintenance. Smaller errors in the same posts are corrected in place.

The corrections take a full level off the remediation gap we drew between Zabbix and Asama.

One question the matrix cannot settle yet is whether partial Infrastructure State buys anything, or whether the five components return little until they reach L4 together.

To score your stack against Asama on your own fleet, book a live comparison at [asama.ai](https://www.asama.ai), or write to contactus@asama.ai. If you think one of our cells is wrong, send the source to the same address, and the comparison will be corrected and the change dated in its closing note.