See Which Rules Actually Fire

You can read a RuleSet and know what it is supposed to do. Run history tells you what one run did. Neither answers the question you actually have after a policy has been live for a month: which of these rules are doing any work?

AI Rule Engine now answers it. Open any environment and choose the new Analytics page, right next to Logs.

Fire rates, per rule

The Rule Fire Rates card ranks every rule by how often it fired, as a share of the runs that evaluated it. A rule at 92% is carrying your policy. A rule at 0% is not, and the table tells you which kind of nothing it is doing.

Each rule gets six columns:

• Fired, the runs where it fired at least once.
• Evaluated, the runs where its condition was actually tested. This is the denominator.
• Skipped, the runs where it was passed over without being evaluated at all, because it was disabled or the run fell outside its effective and expiration dates.
• Activations, total firings. Higher than Fired only under forward-chaining inference, where a rule can fire more than once in a single run.
• Plus the rule name and its fire rate.

That Skipped column is what makes a 0% row readable. High skipped count means the rule was switched off or outside its date window. High evaluated count with zero fires means the condition is genuinely never true against your real traffic, which is usually a rule that has quietly stopped matching the world it was written for.

What your RuleSets are deciding

A RuleSet usually exists to produce one answer: approved or declined, which queue, which risk band. Name the context key holding that answer and the Decision Distribution card charts how often each value came out, as a doughnut plus a written list of value, count, and share.

You name it in the RuleSet editor, in the Decision keys panel underneath your rules. It sits collapsed and shows the keys currently in use right on its header, so it stays out of the way until you want it. Expand it, type one or more context keys separated by commas, and save. If your RuleSet is already exposed as an MCP tool, it uses the output keys it already declares, so its outcomes are charted with no configuration at all.

The setting changes nothing about how the RuleSet runs. It only says which key is worth counting. Point it at a key with a handful of repeating values, not at an order number: a key with one value per run produces a chart with one slice per run and tells you nothing. Values marked secret are never recorded.

Suddenly the distribution is a business question you can ask. What share of applications are we auto approving this month, and was it the same share last month?

Volume and outcomes, day by day

The top of the page covers the health of the environment itself: total runs, success rate, average duration with the fastest and slowest run, and how many rules never fired at all. Under it, Runs Per Day stacks each day by outcome, so completed, warnings, errors, failed, and cancelled runs are one glance instead of a query.

Three filters sit above everything: Project, RuleSet, and a Window of the last 7 to 90 days. Narrow to one RuleSet to study it, or leave it wide to see the whole environment.

Where the numbers come from

Counters are rolled up as each run finishes, not by scanning your logs after the fact. The page stays fast no matter how much history an environment has, and a fire rate is a real measurement rather than an estimate over whatever logs happened to be retained.

A few consequences worth knowing:

• There is no backfill. Analytics accumulate from your first run after the feature went live. Runs before that cannot be reconstructed, so the sooner your RuleSets start running with decision keys named, the sooner the picture is complete.
• Sandbox test runs are excluded. Testing a RuleSet never moves its production numbers.
• A RuleSet invoked by another gets its own rollup under its own name.
• Recording is best effort and can never fail a run that already completed.

Verification, then evidence

The Verify tab reads a RuleSet and tells you which rules can never fire. Analytics tells you which ones do not fire, whatever the RuleSet allows in theory. Together they cover both halves of the same worry: logic that is wrong on paper, and logic that has quietly gone stale in production.

Start with the rules that never fired. Every one of them is either dead weight you can delete, or a policy you thought was running and is not.

Visit RuleEngine.ai to try it.

The AI Rule Engine Team