NOFire AI vs Cleric

At a glance

	NOFire AI	Cleric
Core idea	A causal model of production, each answer tied to a named change	Read-only investigation with an auditable trail and accumulated memory
Published accuracy	89% Top-1 on RCAEval, a public fault-injection benchmark	Not published against a public benchmark
Default authority in production	Read-only collectors, with acting supported under an enforced bound	Read-only by default, acting not offered
Bounding agent actions	Blast radius enforced as a policy bound before an action runs	Not applicable. The agent does not act
Learning across incidents	Not published as a distinct mechanism	Operational memory, so a resolved incident informs the next
Auditability	The evidence path is attached to each answer	Every investigation auditable, and the product leads on this
Before a change ships	Deployment risk analysis on the proposed change	Not offered
Deployment	Read-only collectors, in-VPC processing, BYOC	Vendor-hosted, SOC 2 Type II
Data handling	Processing in your own VPC	States customer data is never used for training

How the two differ in practice

The cleanest way to separate these is to ask what happens after the product produces an answer.

With Cleric, a human takes it from there. Read-only by default is not a limitation the product apologises for, it is the design, and it makes the security conversation short. The investigation is auditable, so somebody can review how the conclusion was reached, and the operational memory means the next investigation of a similar failure starts from what was learned rather than from nothing.

With NOFire AI, acting is supported, and the interesting part is the constraint rather than the capability. Blast radius is computed and enforced as a policy bound before an action runs, so the question is not whether the agent has permission but how much a single action is allowed to affect. That is a different answer to the same organisational anxiety: Cleric removes the risk by removing the capability, we manage it by bounding it.

Measurement is the other real difference. We publish 89% Top-1 on RCAEval, a public fault-injection dataset, where Top-1 means the first hypothesis was right rather than the answer appearing somewhere in a ranked list. A second run on SREGym-lite reports 17 of 20 with no shell access during diagnosis, and names the three it missed. Cleric does not publish an accuracy figure. That asymmetry should be read carefully: it means our claim is checkable, not that theirs is worse. Most of this category publishes nothing comparable at all.

There is also a timeline difference. Both products work after something has fired. We additionally analyse deployment risk on a proposed change before it ships, which is a different job from investigation and is worth ignoring entirely if your expensive incidents are not deploy-shaped.

Where each one is stronger

Cleric is stronger where the obstacle is approval. In an organisation with a change advisory process for humans, an agent that structurally cannot write to production sails through a review that a bounded-action model has to argue its way through. That is a real and repeatable advantage, and it is the reason a read-only product can win against a more capable one. The auditability supports the same case, and the memory model compounds with incident volume in a way that is easy to underestimate over a fortnight.

NOFire AI is stronger where the answer needs to be checkable and where acting is eventually the point. An answer that names a specific deploy or config event can be verified against your own change history in minutes, which is a different kind of confidence from a well-reasoned narrative. Publishing against a public benchmark means the accuracy claim can be audited by anyone. And for teams that do want automated remediation, a bound enforced before the action is the mechanism that makes it approvable rather than merely permitted.

Our limit is worth stating plainly. The 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 89% figure is measured on a public dataset, not on your estate, and those are not the same claim.

How to choose

Start with the approval question, because it is usually decisive and usually answered outside the engineering team. If read-only is a hard requirement from security or compliance, Cleric satisfies it by construction and the evaluation is short. If acting is eventually the goal, the requirement to write down is not permission but the bound, and what governing an AI agent in production requires covers what a testable version of that looks like.

Then weigh incident volume honestly. Memory is Cleric's compounding advantage and it pays in proportion to how often you have incidents. A team with a quiet quarter will see the least of the thing that makes the product good.

Score both on the first hypothesis, using incidents whose true cause you already know. That is the only measurement that compares products which publish different kinds of claim. The AI SRE Benchmark gives a method on a public dataset worth copying.

If deployment risk is irrelevant to your failure profile, discount it from the comparison rather than letting it flatter one column.