NOFire AI vs Traversal

At a glance

	NOFire AI	Traversal
Core idea	A causal model of production, each answer tied to a named change	Production modelled as a graph, searched causally
Published scale	Not published as a node count	Node counts in the millions
Published accuracy	89% Top-1 on RCAEval, a public fault-injection benchmark	Not published
What the answer names	A specific deploy or config event, with the dependency path attached	A causal path through the graph
When investigation starts	On the alert, and on a proposed change before it ships	Unprompted. Workers act on the signal rather than on being paged
Bounding agent actions	Blast radius enforced as a policy bound before an action runs	Not published
Before a change ships	Deployment risk analysis on the proposed change	Marketed as incident prevention
Deployment	Read-only collectors, in-VPC processing, BYOC	Bring your own cloud
Programmatic access	MCP server and API	Not published as a distinct feature

How the two differ in practice

These two are the closest pair in the category, and the similarity is the interesting part. Both reject the approach of correlating symptoms across dashboards, and both replace it with a structure that encodes how production actually fits together, then search that structure. On the fundamental bet they agree.

They diverge on three things. The first is what an answer has to contain. Traversal returns a causal path through the graph. NOFire AI requires the answer to terminate at a named change, meaning a specific deploy or configuration event, with the dependency path attached as evidence. That constraint is deliberate and it has a cost: a failure with no corresponding change does not produce that shape of answer. It also has a benefit, which is that the output is directly actionable and directly checkable.

The second is measurement. NOFire AI publishes 89% Top-1 on RCAEval, a public fault-injection dataset, where Top-1 means the first hypothesis was right rather than the correct answer appearing somewhere in a list. Traversal publishes graph scale rather than accuracy. These are not competing numbers, they are different kinds of claim, and a buyer should not read the presence of one as evidence about the other.

The third is authority. NOFire AI computes blast radius as a bound enforced before an agent acts, so the constraint on what an action may affect is a policy rather than a permission. Traversal does not publish an equivalent. In organisations with a change advisory process for humans, this is often the item that decides whether an AI product gets deployed at all.

Where each one is stronger

Traversal is stronger where the gap between something going wrong and somebody noticing is itself a large part of the incident. Workers that investigate unprompted close that gap directly, and no amount of investigation quality helps if the investigation starts forty minutes late. The published graph scale is a real signal about ambition on large, interconnected estates, and bring your own cloud makes it viable where telemetry cannot leave the account.

NOFire AI is stronger where the answer has to be checkable and where actions have to be bounded. Publishing against a public benchmark means the accuracy claim can be audited by anyone rather than reproduced on trust, and tying the root cause to a named change means the answer either points at a real deploy or it does not. The deployment risk analysis sits earlier in the timeline than either product's incident work, which matters for teams whose most expensive incidents are the ones that should never have shipped.

Our limit is the same one Traversal has, and it is worth stating rather than leaving for a buyer to discover. A causal model is only as complete as the signals it is built from. Where a service emits nothing we can read, we say so rather than inferring a path through it, and a failure mode with no edge in the model is not covered. The benchmark number is measured on a public dataset, not on your estate, and those are not the same claim.

How to choose

Test coverage on both, using the same three incidents. Take failures whose cause crossed a service boundary and check whether the dependency involved appears in each product's model at all. What causal AI means for root cause analysis explains why coverage rather than scale is the question that decides whether this approach works on your estate.

Decide whether unprompted investigation helps you or adds a queue. It is a real advantage where nobody is watching the quiet failures. Where alert fatigue is already the problem, another stream of unrequested output needs somebody committed to reading it.

Establish whether you need an enforced bound on agent actions, and write it down as a testable requirement before either trial starts. What blast radius is and how it is bounded covers what a version of that requirement looks like that a product can actually be measured against. A product that cannot express it will not acquire the ability during a pilot.

Then score the first hypothesis on incidents whose true cause you already know. The AI SRE Benchmark sets out the method on a public dataset if you would rather copy one than invent one.