Goal-Driven Evaluation: Start From the Answer You Want

Most rule engines answer a question you did not ask. You hand them a context, they evaluate every rule in the set, and somewhere in the output is the one value you actually wanted. That works, and for a cascade of small decisions it is exactly right. But when you know the question up front, evaluating everything is a strange way to get to it.

Goal-driven evaluation turns the run around. You name the context keys a run should establish, its goals, and the engine works backwards from them: which rules could produce this key, what would each of those rules need first, and what would that need. Rules that cannot contribute to a goal are never evaluated, so they never run and their conditions are never billed.

Turning it on

Open a ruleset and pick Goal-driven from the hit-policy menu on the execution toolbar. A Goals box appears beside it. Type the context keys you want established, comma separated.

Leave it empty and the ruleset falls back, in order, to its decision keys and then to its declared tool outputs. A ruleset that already says what it decides needs no extra setup at all.

How the search works

For each goal, in order, the engine tries three things:

1. Is it already there? A key supplied as run input, or established while proving an earlier goal, is done. Nothing fires.
2. Is it a derived fact? Then it is computed. Facts come before rules because they cost no rule firing.
3. Otherwise, which rules write it? Every enabled rule whose actions write that key becomes a candidate, tried in salience order.

For each candidate the engine first establishes that rule’s own premises. Every context key its condition reads becomes a sub-goal, resolved the same way, recursively, until it reaches inputs you supplied. Then it evaluates the condition. The first candidate whose condition holds is fired, and if the goal key is present afterwards the goal is established and the rest of the candidates are skipped.

That last part changes what salience means. Under forward chaining, salience decides which rule fires first. Here the search stops at the first candidate that works, so salience decides which rule gets to produce a key. Give your most specific rule the highest salience and your fallback the lowest, and the fallback runs only when nothing better applies.

The run explains itself

A traced goal-driven run shows a Goals section above the firing timeline: one tree per goal, with every candidate rule that was considered, what came of it, and the sub-goals its premises spawned nested underneath.

Read top down, it answers “how did this value come to be?” The candidates that lost are there too, each with the reason it lost: did not match, fired but did not set the key, already fired with these inputs. You can see not just which rule produced the answer, but which rules were in the running and why they were passed over.

When a goal cannot be established the tree turns red, and the deepest node reading nothing writes this key names the input that was actually missing. That is usually the fastest route from “the run produced nothing” to the reason.

Keeping the rest of your run

A pure goal-driven run fires nothing beyond the proof, which means rules that exist for their side effects, sending a notification or calling an API, never run. Turn on Then forward chain and the run continues into the normal forward cascade once its goals are resolved.

Both phases share one trace, one activation cap, and one firing history. Nothing the proof already fired fires a second time, and no AI-prompt condition is billed twice. That makes migrating an existing inference ruleset a two-step change: switch it to Goal-driven, name its goals, turn Then forward chain on. You get the focused proof and the explanation, and everything that used to run still runs.

Verify knows about goals now

Working backwards introduces two mistakes no other mode can make, and both look identical from outside: a run that fires nothing. The Verify tab checks for them without running anything.

• A goal nothing can establish, reported as an error, because every run will come back with it unproven. If the only rules that write it are switched off, the finding says so.
• A producer that cannot be read, a rule whose written keys cannot be known without running it, so the backwards search cannot see it. While one exists, the unreachable-goal check stands down for the whole ruleset rather than guessing.
• A goal-driven ruleset with no goals at all, nothing declared and nothing to fall back on.
• A retractable rule that can never be retracted, because only the forward cascade withdraws support.

When to use which

Forward chaining is still the right answer for a cascade where each conclusion enables the next and you want everything that follows from your data. Goal-driven evaluation is for the other shape: you have one question, the ruleset is large, and you want the cheapest path to the answer plus a record of how it was reached.

Visit RuleEngine.ai to try it.

The AI Rule Engine Team