Goal-Driven Evaluation

Goal-driven evaluation (backward chaining) starts from the answer you want rather than the data you have. You name the context keys the run should establish — its goals — and the engine works backwards to find the rules that can produce them, firing only what the answer actually needs.

How it differs from inference

Forward-chaining inference asks “what follows from what I know?”. It evaluates every rule, fires the best one, and repeats until nothing is left to fire. Goal-driven evaluation asks the opposite question: “what would it take to establish approvalDecision?” A rule that cannot contribute to a goal is never evaluated, so it never runs and its conditions are never billed.

	Forward chaining	Goal-driven
Starts from	The input context	The goals you declare
Rules that run	Every rule that matches	Only rules on the path to a goal
Salience means	Which rule fires first	Which rule is preferred to produce a key
Best for	Cascades where each conclusion enables the next	Answering a specific question cheaply, and explaining a missing answer

Declaring goals

Choose Goal-driven from the hit-policy menu on the rule set editor's execution toolbar. A Goals box appears next to it: enter the context keys to establish, comma-separated. Leave it blank and the engine falls back, in order, to the rule set's decision keys and then to its declared MCP tool outputs — so a rule set that already says what it decides needs no extra setup.

You can also override the goals for a single run: the Run page shows a “Goals for this run” box, and the API accepts a goals query parameter. That lets one rule set answer several different questions without being edited.

How the search works

For each goal, in order, the engine tries these in turn:

If the key is already in the context — run input, or something an earlier goal established — the goal is met and nothing fires.
If the key is a derived fact, the fact is computed. Facts come before rules because they cost no rule firing.
Otherwise the engine collects every enabled rule whose actions write that key, and tries them in salience order (highest first, then editor order).

For each candidate it first establishes that rule's own premises — every context key its condition reads becomes a sub-goal, resolved the same way, recursively. 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 remaining candidates are skipped.

Salience is preference order Because the search stops at the first candidate that works, 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 only runs when nothing better applies.

Premises that cannot be established

A sub-goal that fails is not an error. The key simply stays absent and the condition is evaluated against it — which is exactly what keeps a rule like “if override is empty, set decision to the default” working. Goal-driven evaluation makes such a rule fire for the right reason instead of skipping it.

Running the cascade afterwards

A pure goal-driven run fires nothing beyond the proof, which means rules that exist for their side effects — sending a notification, 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, so nothing the proof already fired fires a second time and no AI condition is billed twice.

Migrating an existing inference rule set Switch it to Goal-driven, name its goals, and turn Then forward chain on. You get the focused proof and the explanation, and everything that used to run still runs.

Reading the proof

A traced goal-driven run shows a Goals section above the firing timeline: one tree per goal, with each candidate rule that was considered and what came of it, and the sub-goals nested underneath. Read top-down it is the answer to “how did this value come to be?”:

approvalDecision   established by Approve
  Deny             did not match
  Approve          fired
  creditTier       established by Tier
    Tier           fired
    income         already known

On a failure the tree turns red and the deepest node reading “nothing writes this key” names the input that was actually missing — usually the fastest way to find out why a run produced nothing. See Logs & Run History.

Limits and safeguards

Situation	What happens
A goal depends on itself	The branch is abandoned and marked “depends on itself”. The rest of the search continues.
Very deep premise chains	Bounded by a depth cap; the branch stops and is marked “sub-goal chain too deep”.
Too many firings	The same Max activations cap as inference applies, across both phases.
A rule whose writes are unknowable	A rule with a human-intervention form, whose submitted fields are not typed, cannot be searched as a producer. The Verify tab warns about it.
Automatic retraction	Support is only ever withdrawn by the forward cascade. In a pure goal-driven run a retractable conclusion is never taken back; Verify points this out.

What Verify checks

The Verify tab adds goal-specific checks: a goal nothing can establish (an error — every run would report it unproven), a rule whose writes cannot be determined without running it, a goal-driven rule set with no goals at all, and retractable rules that can never be retracted. As always, a check that cannot see through something stands down rather than guessing.

Forward-Chaining Inference →Derived Facts →Automatic Retraction →Verifying Rule Sets →Testing Rule Sets →