Going by Miranker’s LEAPS paper and Batory’s P2 LEAPS paper, the primary difference with backward chaining is it delays evaluating joins for all rules. Instead, it sequentially evalutes the rules by querying the facts. I like Dr. Forgy’s interpretation of the differences between forward vs backward. In plain english, a subgoal is a join between 2 facts. A backward chaining engine manages the subgoals in that it takes the first rule off the stack and checks to see if it needs to evaluate the join. If no facts satisfied the literal conditions (aka alphaNodes), it doesn’t need to perform a join evaluation.

Forward chaining in contrast pushes the facts through the network and filters it. If a fact satisfies the conditions a node, it propogates the fact down the network. Basically, it pushes it down.

The real downside of backward chaining is that it is not good for scenarios where one wants to perform cross product matching. The best example I can think of is an OMS (order management system) application for large mutual fund companies. The goal is to match multiple transactions against each other to determine the optimal combination. Since leaps trade performance for thoroughness, it’s not appropriate for scenarios that need cross product matching.

I’ve heard of companies using backward chaining for OMS and pre-trade compliance, but I generally think they haven’t got a clue.

peter