Verify Your Rules Before They Run

A passing test tells you that one input produced the outcome you expected. It says nothing about the rule sitting three rows down that can never fire, or the second rule quietly overwriting the first, or the combination of inputs your table forgot entirely. Those mistakes do not fail loudly. They just sit there being wrong.

AI Rule Engine now finds them for you. Open any RuleSet and choose the new Verify tab.

Reading, not running

Verification is a static check. It reads your rules and reasons about them instead of executing them. Nothing runs, no AI call is made or billed, nothing lands in run history, and your monthly run count is untouched. You can re-check as often as you like.

It also reads the copy of the RuleSet open in your editor, unsaved edits included. Change a condition, press Re-analyze, and see immediately whether the finding went away. You never have to save a half-finished idea to find out if it fixed the problem.

What it finds

Findings come back as plain sentences, counted by severity: Error for something broken, Warning for something that has no effect or whose outcome depends on rule order, Info for an observation that is often deliberate.

Rules that never fire, or fire and do nothing

• A condition whose own clauses contradict each other, so no value can satisfy all of them at once.
• A rule made unreachable because the rules above it always match and use up your match limit.
• A rule that only matches inputs an earlier rule already handles the same way, so it never changes the outcome.
• A rule with no actions: it matches, and nothing happens.
• Rules that are disabled, expired, or not yet effective, reported so a silent rule is never a surprise.

Rules that repeat each other

Duplicates are found by what a rule means, not by how it was typed. The same test written two different ways is still recognized as the same test. Same condition and same actions is a duplicate you can delete. Same condition, different actions is usually two rules that want to be one.

Rules that fight over a key

When two rules can both match the same input and both write the same value, the finding tells you which one wins and why, and its severity follows how your RuleSet actually executes. Randomized rule order or parallel execution makes it an Error, because the winner changes from run to run. Under inference with different salience it is only Info, because you already said which rule should win. Otherwise it is a Warning: the later rule silently overrides the earlier one.

References and keys

Missing shared conditions and missing action sets are errors. A condition that reads a key nothing supplies is a warning, and it is almost always a typo. A key nothing reads, or a derived fact nothing asks for, comes back as information worth acting on.

Input combinations nothing covers

This is the question a decision table invites: have I handled every case? Verification cuts each key your rules test into the ranges they distinguish, then asks, for every combination, whether some rule matches it. Gaps come back in your own vocabulary: “No rule matches when ‘tier’ is Gold and ‘amount’ is more than 100.”

Then switch to the Table view. Each uncovered combination appears there as a greyed Not covered row, sitting under the columns it constrains, with a count in the toolbar. A coverage gap is a row that is not there, so we show you where it would go.

Checks that stand down, and say so

Some checks can only give an honest answer under conditions your RuleSet may not meet. A clause the analysis cannot read through, such as a pattern match or an AI prompt. Randomized order, when the check depends on a fixed one. A missing action set, which leaves the set of keys your rules write incomplete.

Rather than guess, those checks stand down and tell you, in an expandable “could not run” section with a reason for each one. So “no issues found” always means the checks that ran found nothing, never that the ones that could not run were quietly counted as passing. We would rather be honest than look thorough.

Rules that withdraw their conclusions get extra checks

If a rule is set to withdraw its conclusions automatically, it is making a promise the engine has to keep. Verification checks that promise: an action that cannot be undone, a rule that reads a key it writes, retractable rules holding each other up in a loop, or an ordinary rule that would silently discard another rule’s support.

Use it alongside your tests

Verification and test cases answer different questions and neither replaces the other. A test proves an input still produces the outcome you want. Verification catches the contradictions, redundancies, and holes that a passing test cannot see, without you writing anything at all.

Verify while you author. Keep tests for the behavior you never want to lose.

Visit RuleEngine.ai to try it.

The AI Rule Engine Team