The Rules You Forgot You Wrote

Rules accumulate. Someone adds a row for a customer segment that no longer exists. A temporary override outlives the outage it was written for. A condition is tightened upstream and the rule below it stops matching anything, silently, because nothing about a rule that never matches looks broken.

None of this fails. It just quietly makes your logic harder to read every quarter. Here is a way to clear it out.

Step 1: start with the count

Open an environment and choose Analytics. The fourth tile reads Rules Never Fired, with the total number of rules seen in the window underneath it.

Set the Window filter to 90 days first. A rule that fired once last quarter is not dead, and a 7 day window will tell you it is. If that tile reads 3 of 40, you have some tidying to do. If it reads 22 of 40, more than half your logic is decoration.

Step 2: sort out what kind of nothing each rule is doing

Scroll to Rule Fire Rates and read the table from the bottom up. Everything at 0% falls into one of three buckets, and the columns tell you which.

High Skipped, low Evaluated. The rule was never in play. It is disabled, or the runs fell outside its effective and expiration dates. This is often correct: a promotion that ended in June should show exactly this. Check the dates before you touch anything, because a rule that is skipped today may be scheduled for next month.

High Evaluated, zero Fired. The rule was tested on every run and never once matched. This is the interesting bucket. Either the condition is wrong, or the world it was written for is gone. Read the condition and ask whether any realistic input could satisfy it.

Low Evaluated and low Skipped. The rule barely came up at all, usually because a Match First policy stopped the run before reaching it. That is not a dead rule, it is an unreachable one, and it is worth confirming that the ordering is deliberate.

Step 3: check whether it could have fired

Now switch to the RuleSet and open the Verify tab. Verification reads the rules without running them, so it answers a different question: not “did this fire”, but “could it have”.

If a rule shows 0% in analytics and verification reports it as contradictory, shadowed by an earlier row, or duplicating a rule above it, you have a confirmed dead rule. Two independent checks agree, and you can delete it without a discussion.

If analytics says 0% but verification is quiet, the rule is fine on paper and the inputs simply never arrived. That is a business conversation, not a cleanup: either the segment disappeared, or an upstream system stopped sending something it used to send. The second case is worth knowing about for reasons that have nothing to do with tidiness.

Step 4: confirm the outcome mix did not move

Before you delete anything, note what your Decision Distribution looks like. If you have named a decision key on the RuleSet, the doughnut shows the share of each outcome across the window.

Delete the dead rules, let the RuleSet run for a few days, and compare. A rule that truly never fired cannot change the distribution. If the mix moved, the rule was doing something after all, in a case the window did not cover, and your version history has the old RuleSet waiting.

Step 5: leave a test behind

For every rule you kept because it fires rarely but matters, write a test case for it. Rare rules are the ones a future refactor breaks without anyone noticing, precisely because production traffic will not exercise them for months.

That is the pairing worth building a habit around. Analytics tells you what your rules do against real traffic. Verification tells you what they could do. Tests pin down the behavior you never want to lose. Run the first two quarterly, and the third grows on its own.

Visit RuleEngine.ai to try it.

The AI Rule Engine Team