Forward-Chaining Inference
Turn a rule set into a reasoning loop: rules re-fire as other rules change the context they read, ordered by salience, until the run reaches a stable state. Every firing is recorded in a trace you can read — or ask AI to explain.
The other direction Forward chaining starts from what you know and works out what follows. If instead you know the question — “can this application be approved?” — and want only the rules needed to answer it, use goal-driven evaluation, which can also run this cascade once its goals are resolved.
What forward chaining is
By default a rule set runs in a single pass: the engine walks the rules once, fires the ones that match, and stops. That is simple and predictable, and it stays exactly that way unless you opt in.
Inference (forward chaining) changes the model. The engine fires one rule at a time and, after each firing, re-checks the rules that read whatever just changed. A rule whose inputs were rewritten by an earlier rule gets another chance to match. The run keeps going until nothing new can fire. That lets one decision cascade into the next without you wiring the order by hand.
When to reach for it Use inference when decisions build on each other: cascading eligibility (qualify a customer, then price them, then pick an offer), derived-state rule sets where each rule refines a shared picture, or any “keep applying the rules until things settle” problem. Stick with single-pass for straightforward “score these inputs once” sheets and decision tables.
Turning it on
Inference is a per-rule-set choice. In the rule set editor, the execution toolbar sits above the Rules view and applies to both the Table and List layouts. A match-policy badge shows the current mode; open its dropdown to pick one of:
| Policy | Behavior |
|---|---|
| First match | Single pass; stop at the first matching rule. |
| First N… | Single pass; stop once N rules have matched. |
| All matching | Single pass; fire every matching rule once (the default). |
| Inference | Forward chaining; rules re-fire as the context changes. |
| Goal-driven | Backward chaining; the engine works backwards from the keys you name and fires only the rules needed to establish them. |
Selecting Inference turns forward chaining on; selecting any single-pass policy turns it off. The badge then reads Inference in both views. The toolbar tooltip states it plainly: “Forward-chaining inference: rules re-fire as their actions change the context keys other rules read. Use per-rule Salience for priority and Max activations to cap firings.”
How the engine runs
With inference on, a run proceeds like this:
- Eligible rules — those whose condition currently matches — form a queue ordered by salience (highest first), with ties broken by rule order.
- The engine fires one rule and runs its actions, which may write to the context.
- Those context changes re-evaluate only the rules that read the changed keys — not the whole set — and any that now match re-enter the queue.
- The loop repeats until the set is stable, the activation cap is reached, or the run is cancelled or errors.
Because only rules that depend on the changed keys are re-checked, a large rule set does not re-scan itself top to bottom on every firing.
A disabled rule, or one outside its active date window, never enters the queue at all — so it can neither fire nor be re-activated later in the cascade. The clock is read once at the start of the run, so a rule cannot expire between passes.
Re-firing and loop safety
A rule will not re-fire unless the values it reads have changed since it last fired. That single guarantee is what keeps inference from spinning: if two rules keep flipping a value back and forth (A sets it, B resets it, A sets it again…), the values each rule reads stop changing and the chain settles instead of looping forever. You get cascading behavior without hand-managing termination.
How a run halts
Every inference run ends with one of these outcomes, shown as a banner in the trace:
| Banner | What it means |
|---|---|
| Reached a stable state — no more rules to fire. | Normal completion: nothing left that could match on changed inputs. |
| Stopped at the activation cap (possible write/read loop). | The run hit its Max activations limit — often a sign that a rule keeps rewriting a key another rule reacts to. |
| Cancelled before reaching a stable state. | The run was cancelled while still firing rules. |
| Stopped by an error during inference. | An action or condition raised an error and halted the loop. |
The trace also reports the totals for the run — for example “12 firing(s) · 4 iteration(s)”.
Salience — setting priority
Salience is a per-rule integer that decides which eligible rule fires first. Highest salience fires first; ties fall back to rule order. It is ignored entirely unless inference is on, so adding salience never changes single-pass behavior.
- Default 0; range −10000 to 10000.
- Set it in the per-rule settings overlay (the gear) in the decision table, or in the List-view rule editor.
- A nonzero salience shows a small row badge — for example
S5for a salience of 5.
Max activations — capping the loop
Max activations caps the total number of rule firings before the run halts, a safety net against an unintended write/read loop. The input appears only in Inference mode (range 1–10000, placeholder 500) with the tooltip “cap on total rule firings before the run halts (blank = server default)”. Leave it blank to use the server default of 500, or set a per-set override. When the cap is reached the run stops with “Stopped at the activation cap (possible write/read loop).”
What changes, what stays
Switching a set to inference adjusts a few of the single-pass controls:
| Setting | Under inference |
|---|---|
| Parallel rule sequence | Disabled — “Not available with Inference — forward chaining fires rules one at a time.” Rules must fire one at a time so their outputs can feed the next. |
| Max rules to match (First match / First N) | A single-pass concept; cleared and disabled, since inference decides its own stopping point. |
| Randomize rule order | Still allowed — it becomes the tie-breaker within an equal salience. |
| Nested rule sets, all action types | Work unchanged; a nested Run Rule Set runs with its own policy. |
Cost
An inference run counts as a single metered run no matter how many activations it takes. And when a rule's AI-prompt condition is re-checked with the same inputs, the earlier result is remembered rather than re-billed — only a genuine change in what the condition reads triggers a new AI call.
Traces
Inference produces a trace: a firing-by-firing record of what happened and why. Turn on the “Record run traces” toggle (shown in Inference mode) to keep it for production runs — “Record a viewable, AI-explainable inference trace for production runs (every firing, why each condition passed/failed, and each context change). Adds a small per-run cost. Test runs are always traced.” The viewer shows a timeline of firings, a “why it matched” condition tree with the actual values, the context deltas each firing produced, and any derived facts. You can also Explain with AI to get a plain-language summary of the run. See Logs & Run History for reading traces after a run, and Testing Rule Sets for traces in test results.