Automatic Retraction: Conclusions That Take Themselves Back

Here is a bug that does not look like a bug.

rule A:  income > 100000    ->  tier = "premium"
rule B:  tier == "premium"  ->  discount = 0.2
rule C:  fraudFlag == true  ->  income = 0

The fraud flag arrives true. Rule C fires and income drops to zero. Rule A no longer matches. But tier is still “premium”, and discount is still 0.2.

Every rule did exactly what it was told. The trace is clean. The answer is wrong.

AI Rule Engine now fixes this class of bug directly, with automatic retraction.

A conclusion that knows what holds it up

In a single pass, a rule’s writes are permanent, and that is exactly right: nothing runs after it to invalidate anything. Under forward-chaining inference it is not right, because rules re-fire as the context moves. A rule that matched early can stop matching later, and the change it made is still sitting there.

Open a rule and switch on Withdraw conclusions automatically. From then on the engine remembers that the rule’s changes are true only while the rule still matches. When its inputs move, the conclusion comes back out. In the example above, marking A and B retractable is the whole fix: tier is withdrawn when A stops matching, which pulls the ground out from under B, so discount is withdrawn too.

Which rules want this

Rules that classify or derive: a tier, a risk band, an eligibility flag, a computed discount. Anything where the honest answer to “is this still true?” is “only while its inputs say so.”

Leave it off for rules that record something that happened: an audit note, a counter, a decision you want to stand regardless of what comes later.

Support is counted, not assumed

If two retractable rules both conclude status = "open" and only one of them stops matching, the value stays. The other rule is still holding it up. Only when the last supporter goes does the value go.

When two retractable rules write the same key different values, the most recent one wins and the earlier one waits underneath it. Withdraw the newer rule and the older value surfaces again rather than the key vanishing. Derived facts work the same way: if the values a fact was computed from go away, the fact is removed instead of sitting in the context with a stale value.

One deliberate exception. A rule without retraction that writes a key a retractable rule is supporting takes permanent ownership of it. That is a useful way to pin an override that should stick, and it is an easy thing to do by accident, so the RuleSet check points it out.

You can read every withdrawal

Withdrawals appear in the inference timeline alongside firings, in the order they happened, so a value that was written and then taken back reads as one story instead of two lists. A withdrawal row is struck through and marked with an undo icon, names the rule or fact that lost its support, says why, and expands to show exactly which keys changed and what they went back to. Firings from retractable rules carry a logical chip.

Test runs and what-if comparisons follow the same truth. A rule that fired and was then withdrawn is not reported as matched, because the run does not stand behind it.

Guard rails, checked up front

The engine can only undo what it can reach, so a retractable rule is constrained, and all four constraints are checked when you save rather than failing quietly at run time:

• Context actions only. An API call, an AI completion, a saved file, or a human-intervention form leaves a mark outside the context that no retraction can reach.
• Sequential actions. Merging parallel branches loses the record of which action wrote what.
• No reading a key it writes. A rule that stops matching because of its own conclusion would match again the moment that conclusion is withdrawn.
• Effects knowable in advance. The engine tracks what a rule supports from its declared writes.

Two retractable rules can still end up defeating each other in a loop through other rules. The run always terminates: after a rule has taken the same conclusion back a few times, the engine freezes its support and records an Oscillation detected warning. It freezes the conclusion held rather than withdrawn, on purpose, because ending a run with a contested answer is far easier to reason about than ending it with a live rule and no answer at all. The new Verify tab flags support cycles, irreversible actions, and self-supporting rules before you ship them.

Correct answers, not just consistent traces

A decision that outlives the facts behind it is the hardest kind of error to find, because nothing in the run looks wrong. Automatic retraction makes that impossible by construction: what the rules no longer support, the run no longer claims.

Visit RuleEngine.ai to try it.

The AI Rule Engine Team