NOFire AI vs Traversal

At a glance

	NOFire AI	Traversal
Core idea	A live, time-versioned model of production. Every answer is a specific deploy, config or code 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	82% RCA accuracy, self-reported from customer deployments
What the answer returns	A specific deploy, config or code change, 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	Human approval before any action, with no published bound on reach
Where agent code runs	Read-only collectors. Coding agents run in a microVM via brig, our open-source sandbox	Nowhere. Agentless and read-only, so no agent code runs against production
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 be a specific deploy, config or code change, 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 82% root-cause accuracy from its own deployments. It also went further than anyone else here on the public side. With Columbia and Cornell Tech it built and released ORCA-bench: 1,079 root-cause tasks, a public dataset, a leaderboard and a 33-page paper. It scored five frontier models on it rather than its own product, so its own number is still a deployment figure. The distinction left is narrow. Both companies publish against public datasets. Only one has published a score for its own system.

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 requiring a specific 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. The 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.