The Goals for this run box on the ruleset runner, overriding the goals a goal-driven ruleset works backwards from

Rulesets grow by accretion. The set that started as “can we approve this?” picks up pricing, then a risk band, then a review-queue assignment, and every run computes all four whether the caller wanted them or not.

Goal-driven evaluation lets you ask for one of them. This is how to get there from a ruleset you already have, and how to point the same ruleset at a different question per run.

Step 1: switch the mode, name the goals

Open the ruleset and choose Goal-driven from the hit-policy menu on the execution toolbar. In the Goals box, type the context keys that hold the outcome, comma separated. If you already filled in Decision keys for the Analytics page, leave Goals blank instead and those keys are used.

Nothing else changes. Your rules, conditions and actions stay exactly as they are. The engine only changes how it decides which of them to evaluate.

Step 2: turn on the cascade, at first

A pure goal-driven run fires only what the proof needed. If your ruleset also sends a notification, calls an API, or writes an audit key from a rule that no goal depends on, those rules will not run.

Turn on Then forward chain. Once the goals are resolved, the run continues into the normal forward cascade, sharing one trace, one activation cap, and one firing history with the proof, so nothing fires twice. Your run behaves the way it did before, and you have gained the proof tree.

Once you can see from the trace what the proof actually needed, you can decide whether to turn the cascade back off.

Step 3: check it with Verify

Open the Verify tab. It has goal-specific checks: a goal that nothing writes, a rule whose written keys cannot be determined without running it and so cannot be searched backwards, a goal-driven ruleset with no goals, and retractable rules that can never be retracted because the cascade is off.

Verify reads the copy open in the editor, so you can check the change before you save it.

Step 4: ask a different question per run

Here is where one ruleset starts earning its keep. The goals in the editor are the default, not a fixed commitment.

From the runner. The Run page has a Goals for this run (optional) box. Type a different key, run it, and the engine works backwards to that key instead.
From an API call. The run endpoint takes a comma-separated goals parameter. Leave it off and the ruleset’s own goals apply.

So an eligibility service can ask for approvalDecision while a quoting service asks the same ruleset for premiumRate, and neither pays for the other’s rules. The logic stays in one place, and it stays consistent, because both callers are reading the same rules.

What to watch for

Salience means preference here. The search stops at the first candidate whose condition holds, so the highest-salience rule that matches is the one that produces the key. Order your rules most specific first, fallback last.

A missing sub-goal is not an error. If a premise cannot be established, the key simply stays absent and the condition is evaluated against it. That is what keeps “if override is empty, use the default” working, and it fires for the right reason instead of being skipped.

Parallel is off. Goal-driven fires one rule at a time by construction, so the parallel rule sequence is unavailable. Max activations still applies, across the proof and the cascade together.

The payoff

You stop paying for decisions nobody asked for, and every answer arrives with the chain of reasoning that produced it. The ruleset stops being a batch job that computes everything and becomes something you can ask a question.

Visit RuleEngine.ai to try it.

The AI Rule Engine Team