Data-driven (forward) vs goal-driven (backward) chaining

Two directions for the same rule base

A production system can run a rule base in either direction. This is exam Q2 verbatim — *"contrast data-driven vs goal-driven strategy for search control in production systems."*

Data-driven (forward chaining). Start with the known facts in working memory. Match rules by their conditions (IF parts): when a rule's conditions are all present, fire it and add its conclusion to working memory. Repeat. The known set of facts grows outward until the goal appears or no rule can fire. Reasoning flows *facts → conclusions*.

Goal-driven (backward chaining). Start with the goal in working memory. Match rules by their conclusions (THEN parts): when a rule concludes the goal, its conditions become new subgoals. Recurse on each subgoal until every subgoal is either a known fact or supplied by the user. Reasoning flows *goal → facts*.

How to choose the direction

Pick the direction with the smaller branching factor, and consider what you start with:

- Use data-driven when you begin with lots of data and want to know *what follows* — interpretation/monitoring problems (a stream of sensor readings), where there is no single starting goal. The risk: it fans out in all directions and can derive irrelevant facts. - Use goal-driven when you have a specific hypothesis to confirm and the set of possible goals is small — diagnosis ("is it disease X?"). It stays focused and, crucially, gives better explanations: the goal/subgoal tree *is* the justification, so answering "why did you ask that?" is free.

Worked contrast

Rule base: R1: A∧B → C, R2: C → D, facts {A, B}, target D.

- Forward: {A,B} fires R1 → add C; now {A,B,C} fires R2 → add D. Done. Two firings, driven by the data. - Backward: goal D; R2 concludes D → subgoal C; R1 concludes C → subgoals A,B; both are facts → success. The rule chain R2 ← R1 read backward is the proof of D.

Same rules, same answer, opposite traversal. The choice is a control decision, not a logical one.