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.

This blog post walks you through using the business use cases by providing a walk through of one of the business use cases.

First, an overview of the business use cases. The business use cases is a set of 33 examples of business information represented using XBRL.  Here is a summary of the helpful view of this information:

• Basic list of use cases
• Another basic list in a little different format
• Visual summary of use cases
• Machine-readable list of business use cases (good for running tests)

For EACH business use case you can get the following: (I am using the last business use case, nonfinancial information, as an example)

• Index page for the business use case
• XBRL instance (Human readable)
• XBRL taxonomy used by the XBRL instance (Human readable)
• XBRL Formulas (Human readable)
• XML Infoset for Model Structure (Human readable)
• XML Infoset for Fact Table (Human readable)
• Human readable information for business use case
• ZIP file you can use to DOWNLOAD all the information above

To understand the model of the information (the fact tables), read this blog post. (multidimensional model)

If you want a more comprehensive example, use this reference implementation.

In a prior blog post I briefly described expert systems. I provided a couple of definitions of an expert system.  I am still synthesizing and summarizing information to improve the description of an expert system. Here is my best description as of this point:

Expert systems are computer programs that are built to mimic human behavior and knowledge. The computer program performs tasks that would otherwise be performed by a human expert.  A model of the expertise of a domain of knowledge of the best practitioners or experts is put into machine-readable form and the expert system reaches conclusions or takes actions based on that information.

Expert systems are a branch of artificial intelligence. So how does an expert system "mimic human behavior"?  How is knowledge "put into machine-readable form"?  How can tasks be performed by a computer that represents knowlege of "best practitioners or experts"?  This is how that is achieved.

A software based expert system has four primary components:

• Knowledge base: A knowledge base is a set of universally applicable rules created based on the experience and knowledge of a domain expert generally articulated in the form of IF…THEN statements or a form that can be converted to an IF...THEN form. A knowledge base is "fixed" in that its rules are universally relevant to all situations covered by the knowledge base.  Not all rules are relevant to every situation.  But where a rule is applicable it is universally applicable.  All knowledge base information is machine-readable.
• Database of facts: A database of facts is a set of observations about some current situation or instance. The database of facts is "flexible" in that they apply to the current situation. The database of facts is machine-readable.
• Inference engine: An inference engine takes existing information in the knowledge base and the database of facts and is used to reach conclusions or take actions.  The inference engine is the machine that processes the information.
• Explanation mechanism: The explanation mechanism explains and justifies how a conclusion or conclusions are reached.  It walks you through which facts and which rules were used to reach a conclusion. The explanation mechanism is the results of processing the information using the inference engine and justifies why the conclusion was reached.

The four primary components of an expert system are generally wrapped within some graphical user interface that presents the expert system to the user of the software based system.

How does all this relate to XBRL?

XBRL is a global-standard syntax that can be used to structure information which can then be used by expert systems.  In the XBRL world, the set of XBRL taxonomies including the relations expressed in XBRL calculations, XBRL definition relations, and XBRL Formula makes up the knowledge base.  The XBRL instance is the database of facts.  An XBRL processor plus the XBRL Formula processor performs the role of the inference engine. Reports generated by the XBRL and XBRL Formula processor and other such computer software tools provide the explanation/justification mechanism.

So why don't XBRL-based reports and software seem to act like expert systems these days?  That is simply because pieces are missing from systems that have been implemented.  Primarily there are two missing pieces:

1. Missing machine-readable rules from the XBRL taxonomy that makes up the knowledge base and
2. Missing processing from the XBRL Formula processor.

Very few XBRL implementations these days provide adequate machine-readable business rules using XBRL Formula and XBRL definition relations.  Software generally does not provide a complete XBRL processor, let alone an XBRL Formula processor or inference engine capabilities.  Current XBRL processors generally do not support chaining because XBRL provides no standard chaining model.  Further, most software developers creating software are not using the techniques offered by artificial intelligence technologies for creating their software.

What does this mean?  It means XBRL-based reports that are filled with errors.  It means that there is a lot of upside potential as software engineers/architects understand and correct the mistakes they have made. Ultimately, I believe, that it means the future of digital financial reporting and digital business reporting will be bright.

Imagine having "Legos" that can be used to construct your own expert system.  The complexity of such systems hidden from users of the software.  What I believe is going to happen is that software tools will become available that make it so the cost of creating and the knowledge required to create an expert system will both drop exponentially.  This will put powerful expert systems into the hands of business professionals.

Why can this happen?  Well, first because in the past such expert systems were created the way most things were manufactured prior to Eli Whitney introduced the notion of interchangeable parts.  Global standard specifications such as XBRL help make standardization possible.  Standards allow for interchangable parts to be created.  Second, because usage patterns can be turned into "Legos" that make it possible for business professionals to perform the knowledge engineering tasks necessary to create such systems.  The strict multidimensional model which defines things like "fact" of the information processed makes this possible.  Third, because more and more information is structured there are more and more opportunities to apply expert systems will appear.  Finally, because of the connectivity offered by the internet models and other metadata can be easily shared and used by such systems.  Digital machine-readable knowledge is collateral in today's increasingly digital world.

What do you think?