Digital Financial Reporting

I'm still trying to figure out the best processing approach for the fundamental accounting concept relations and other business rules to best take advantage of the power XBRL has to express business rules. One part of that question is whether a forward chaining or backward chaining approach is best.

The blog post Forward and Backward Chaining: Part 2, by Charles Forgy, PhD, provided the best answer to that question. In a nutshell, here is Dr. Forgy's answer: use both if possible:

In conclusion, forward and backward chaining systems both use subgoals to control the operation of a rule base. Pure forward chaining systems are more powerful than pure backward chaining systems, but pure forward chaining systems require the developer to write all the subgoaling rules. Modern forward chaining systems such as the RulesPower system integrate automatic backward chaining with forward chaining. These systems combine the best features of both forward and backward chaining.

Dr. Forgy distills the difference between forward and backward chaining down to the following two salient points:

• Rule firing:
  1. Forward-chaining systems fire rules whenever the rules’ If parts are satisfied.
  2. Backward-chaining systems attempt to fire rules only when those rules can potentially satisfy a goal.
• Subgoal creation:
  1. Backward-chaining systems automatically create new subgoals when more information is needed to determine whether a given rule is satisfied.
  2. Forward-chaining systems do not automatically create subgoals.

Dr. Forgy explains why you would want to use forward-chaining when backward-chaining automatically creates new subgoals but forward-chaining does not:

You might ask why you would want to use a forward chaining system if you have to write rules to manage subgoals. After all, backward chaining systems automatically manage the subgoals. There answer is very simple: Backward chaining systems are more limited than forward chaining systems. There are many kinds of tasks that can be handled easily with a forward chaining system that are either difficult or impossible with a backward chaining system. Backward chaining systems are good for diagnostic and classification tasks, but they are not good for planning, design, process monitoring, and quite a few other tasks. Forward chaining systems can handle all these tasks.

So there seems to be a tradeoff.  You can use forward-chaining and satisfy all your needs, but the price you pay is having to create subgoals.

Alternatively, you could use a system that supports forward-chaining which automatically swithes to a backward-chaining mode when needed.

If you want to understand more details about forward an backward chaining, Dr. Forgy first part in this series, Forward and Backward Chaining Part 1, is worth reading. This Wikipedia article on business rules engine types is also useful.

But man, why can't this be easy! Note this statement in the last paragraph on the Wikipedia article about business rule engine types:

A fourth class of rules engine might be called a deterministic engine. These rules engines may forgo both forward chaining and backward chaining, and instead utilize domain-specific language approaches to better describe policy. This approach is often easier to implement and maintain, and provides performance advantages over forward or backward chaining systems.

"Easier to implement and maintain", "performance advantage".  Huh.  Interesting.