Not every value your rules need has to arrive as input. Some values are derived — computed from the inputs you already have. AI Rule Engine now lets you declare those directly with derived facts: context values computed on demand from other context values, instead of being supplied when the run starts.

You will find them on the new Derived Facts tab in the RuleSet editor, just before Tests.

Resolved the moment a rule needs one

A derived fact is resolved the first time a rule reads its key while that key is absent from the context. That’s the whole model in classic mode: rules ask for a value, and if it isn’t there, the matching derived fact produces it — lazily, on demand, only if something actually needs it. With forward-chaining inference on, derived facts go a step further: when an input a fact reads changes, the fact is re-derived automatically, before the rules that depend on it are re-evaluated. Your computed values stay in step with the cascade.

Defining one

Each fact has a few fields:

Key — required, and unique within the set. (“Derived fact keys must be unique.”)
Description — optional, up to 255 characters, so the next author knows what it means.
Value — where the value comes from: a Context key, an Env Var, a Constant, or an Expression.
Guard — optional. By default a fact is always derived; add a guard to derive it only when a condition holds.

When a guard is false, the key simply stays absent — and your rules can test for exactly that with Is empty / Not empty. Absence is a first-class, meaningful state, not an error.

Facts can build on other facts. A fact’s value or guard may reference another derived fact, and chains resolve recursively. To keep that safe, cycles are rejected at save time, with a message naming the loop, so you can never ship a set where two facts depend on each other in a circle.

The Derived Facts tab showing computed context values: a constant default, an expression, and a guarded fact.

Four ways to use them

Defaults for optional inputs. Some inputs are optional; your rules still need a value. Define a derived fact that supplies the fallback — region defaults to "US" when the run doesn’t provide one — and every rule downstream reads a clean value without special-casing the missing one.

Shared business definitions. Define a term once and reference it everywhere. A fact named IsVip — say, spend over a threshold and account in good standing — can be read by dozens of rules. When the definition of “VIP” changes, you change it in one place, not in every rule that happened to spell it out.

Computed values via expressions. Point a fact’s value at an Expression and you can compute whatever you need: a riskScore blended from several inputs, a normalized total, a derived category. The rules that read riskScore don’t care how it’s calculated — they just compare against it.

AI-classified flags, evaluated only when needed. Give a fact an AI-prompt guard and you get a classification that runs lazily — the model is consulted only if a rule actually reads the fact. If nothing needs it on a given run, the model is never called. And under inference, while the inputs that feed the classification are unchanged, the result is remembered and never re-billed. You get AI judgment as an on-demand fact, without paying for it on every run or every re-evaluation.

They show up in the trace

Because facts resolve during the run, they’re part of the story a trace tells. The inference trace includes a Derived Facts section listing which facts resolved, whether lazily or eagerly, at which iteration, and from which input keys. When a decision hinges on a computed value, you can see exactly when and how that value came to be — the same provenance you get for everything else in the run.

Derived facts move computation out of your rules and inputs and into one declared, reusable, testable place. Define the value once; let the rules read it.

Visit RuleEngine.ai to try it.

The AI Rule Engine Team