Digital Financial Reporting

I have mentioned the notion of "decidability" when I did a blog post related to description logic.  When I discussed the notion of decidability with others, many times they seemed to be lumping other things in with decidability.

And so, I am tuning and I think improving my ability to express what I am trying to say.  This is an improved attempt to summarize and synthesize these ideas.

There appears to be four "logical catastrophes" or "failure points" that the type of business system that I am working to create and many other similar types of business systems MUST NEVER HAVE. These characteristics are so catastrophic to the system they must never exist.  Besides, these characteristics never exist in the reality that the system is trying to represent in machine-readable form.

This is a summary of these four logical catastrophes or "failure points" which must never exist:

• Undecidability:  "I don't know" or "unknown" is NOT an option as an answer to any question.  A big part of this is making the closed world assumption rather than the open world assumption.  What is interesting is that XBRL 1.0 and I am pretty sure XBRL 2.0 allowed for explicitly stating whether the closed world assumption was being made.  Also, relational databases make the closed world assumption.  On the other hand, many of the "anyone can say anything about anything" folks working to build the semantic web take the open world assumption by default.  It is not to say that one assumption is right and the other is wrong.  It is to point out that one assumption works one way and the other works another way and business systems generally need to be decidable and would make the closed world assumption.  And this is not an "either/or" type question.  All one needs to do is be explicit and not make others guess.  Digital financial reporting needs to make the closed world assumption and therefore be decidable for the reasons explained here. Why?  For the exact same reasons OWL 2 DL makes the closed world assumption.
• Infinite loops:  It is not hard to understand the problems caused by getting into an infinite loop from which a system can never escape.  The reality represented by the business systems that I want to create don't have infinite loops.  Therefore, there is no need to express something as an infinite loop.  Another term that helps to understand loops from graph theory or network theory is a cycle.  This stuff hurts my head to think about, but the basics of what a business professional needs to know is the difference between a directed cycle and an undirected cycle.   Basically, never use directed cycles, they cause potentially infinite loops.  Again, what is interesting is that XBRL consciously provided a means to eliminate directed cycles from ever appearing in an XBRL taxonomy.  I don't think OWL 2 DL has this ability.
• Unbounded pieces; unbounded sets:  First-order logicor also known as first-order predicate logic can only work on finite systems.  An infinite system can never be explained successfully using first-order logic.  The pieces that make up XBRL are: fact, characteristic, parenthetical explanation (XBRL Foot note), network, hypercube ([Table]), dimension ([Axis]), member, primary item ([Line Items]), abstract, and concept.  EVERYTHING in XBRL is one of those things.  You can add any number of those things.  You cannot invent new things and arbitrarily add them to a system.  While the XBRL Technical Specification does allow for the addition of new things; most systems created have some bounded set of pieces.  Further, every set is likewise bounded.  There is a specific, countable, number of facts in an XBRL instance; always. This blog post and this blog posthelp you see that the pieces that make up XBRL are well bounded.  Likewise, every set of such pieces is finite.
• Unspecific logic:  It is not expected that the business system at the level of describing the things in the system be able to support "fuzzy logic" or "probabilistic reasoning" or other such stuff. Now, when you use the information from the system, you can do whatever you want. But, describing what is in the system and what is not is not a "probability", it is a fact and the answer is it is there or it is not there; there is no in between and the answer is not a statistical probability.  For example, "What is the value of assets?," is a number, not a probability.

That is my best attempt at describing the requirements of the type of business system that digital financial reporting needs to be.  This is not a personal preference, this is about science.  This is the only type of system what will work the way professional accountants need the system to work. There are a lot of other systems which would have similar requirements.  And this is not to say that other systems can have different requirements.

And so the question is this: What logic or calculus should be used to represent such a system?  OWL 2 DL might work, but OWL 2 DL does not support mathematical computations because some such computations cause a system not be decidable. 

XBRL can do this.  There are exactly ZERO catastrophic failures if you read the entire set of XBRL-based financial filings which have been submitted to the SEC.  Not one.  While the closed world assumption is not explicitly stated, it is assumed.  No infinite loops.  A bounded set of pieces can be used to construct an XBRL-based report.  A bounded, finite number of pieces exist for each XBRL-based report.  Fuzzy logic was not used to create the reports, the creation rules are specific.

Now, within the XBRL-based reports there are mistakes in the articulation of meaning.  Many inconsistencies such as that.  But, that is not remotely close to a catastrophic failure. That is a detail. Those inconsistencies are being detected and corrected.

I would be very interested in the thoughts of others who are knowlegable about how to make such a system work. I am not 100% sure that I am describing this correctly.  But I am 100% certain about what I am trying to achieve.  What I really don't understand is exactly the best way to achieve it.  I have some ideas, but I don't know the answer yet.  So please let me know what you think.

The video, A Theory of a System for Educators and Managers, discusses Dr. W. Edwards Deming's view of systems in general by looking at the education system.  If you don't know who Deming is; he is the guy that the U.S. automotive industry ignored but the Japanese automotive industry did not ignore, allowing the Japanese automotive industry to overtake the U.S.

I don't understand the relation between Deming's ideas and Six Sigma, but they seem very related.

These ideas were developed to improve production processes.  But they are just as applicable to services and even to information systems.

Cooperation and collaboration is key to systems:

Working together is the main contribution to systemic thinking as opposed to working apart separately.

There are different programming paradigms that exist and can be used: imperative, declarative, object-oriented, functional symbolic, and logic programming.

PROLOG (download here) a general purpose logic programming language that is also declarative.  Prolog is based on first-order logic. The syntax of PROLOG is derived from Horn clauses which is a subset of first-order logic. Because PROLOG is declarative, program logic is expressed represented by facts, relations, and rules. Questions are asked and then answers are provided based on the facts, relations, and rules. 

The name PROLOG is derived from the phrase "PROgramming in LOGic". Academics in computer science community consider PROLOG an important language because it is about executable logic. Academics in philosophy or logic like to teach PROLOG for the same reason.  Academics in business...Well, I have an MBA with an emphasis in information systems and they never mentioned PROLOG in any classes I took but that was 30 years ago.

So, most business professionals have probably never heard of PROLOG.  However, if you have read Knowledge Engineering Basics for Accounting Professionals, you might be like me and get the sense that PROLOG might be very, very important.

The article, Prolog Under the Hood: An Honest Look, examines the inner workings of PROLOG. In the first paragraph of the conclusion of that article the author states:

In the AI [artificial intelligence] industry we have created many neat programming tools, none of which have taken off as we hoped. Quite possibly it is because the languages try too hard to be something they are not.

There is a lot to that statement.  First off, it is unfortunate that the author chose to use the term "AI" or artificial intelligence.  It seems that artificial intelligence and expert systems tends to get grouped together.  This is unfortunate in my view. Personally, I don't like the "artificial" part of artificial intelligence.  The term expert system resonates with me well though.  Expert systems are "neat" ideas.

The "...because the languages try too hard to be something that they are not."  I completely agree with that statement.  Computers cannot think.  They are machines and machines, at least today's machines, cannot think.  The best that machines can do is mimic some things what humans can do.  Machines cannot mimic intuition and creativity.  But they can mimic rudimentary tasks, if give the right knowledge in the right form.

That form is machine-readable metadata.  Facts, relations, rules.  That is what a machine uses to mimic tasks humans perform, successfully automating those tasks.  But if the metadata is nonsense, then the results of the machine automated tasks will likewise be nonsense.

PROLOG is a tool for making sure the important machine-readable metadata is not nonsense.  That is the first step in automating work.  So, am I saying that every accountant needs to go and learn PROLOG?  No.  Not at all.  PROLOG or things like PROLOG such as the Fluent Editor will be buried deeply within the bowels of software.  While the law of conservation of complexity states that complexity can never be removed from a system, the complexity certainly can be moved.

Using techniques that I have outlined in my document Understanding Blocks, Slots, Templates and Exemplars, the "neat" functionality provided by PROLOG and other such tools for making sure facts, relations, and rules are described correctly in taxonomies and ontologies and consistent with those descriptions in something like a digital financial report; machines will effectively mimic humans and perform useful work. 

The alternative?  Nonsense.  Describing the facts, relations, and rules is a basic function of the system.  If the facts, relations, and rules are not described correctly then inconsistencies result.  It really is that straight forward.

But if both the information in something like a digital financial report is correct and consistent with what people believe is a standard machine-readable representation of a financial report; machines can do incredibly useful work for humans because the information does not contain nonsense.

Tools like PROLOG and the Fluent Editor minimize and hopefully eliminate nonsense.

XBRL US and others have created what they call the "Data Quality Committee".  Data quality is the "end".  What they are really doing is creating machine-readable rules necessary to reduce the nonsense.  Those rules are the "means" to the "end", data quality.  Think of what the Data Quality Committee creates as being an extension of the US GAAP XBRL Taxonomy, adding important missing machine-readable business rules.

Ask yourself a question.  How do you know that the machine-readable rules are correct? Tools like PROLOG can help.

If you are ambitious, a great way to understand what I am talking about is to fiddle around with PROLOG. This blog post, Try Logic Programming: A Gentle Introduction to PROLOG, points you to a free downloadable version of a PROLOG implementation, tutorials, examples, and other useful information.

Learn PROLOG Now! has other very useful information.

Really anxious to get started with PROLOG?  Try this online version of PROLOG.

Of course, all this begs the question, "Why would you need PROLOG?  Why can't an XBRL processor and/or XBRL Formula processor handle all these details?"  PROLOG is basically a general purpose reasoner.  Why isn't there a business report reasoner or even better a financial report reasoner?

Stay tuned!

One of the significant issues with XBRL-based public company financial reports to the SEC is that there is no one set of consistency checks that everyone uses to check their digital financial reports.  The SEC has its Edgar Filer Manual (EFM) tests (interactive data public test suite), XBRL-US has their consistency suite, XBRL Cloud has their tests, I have my fundamental accounting concepts and minimum criteria tests, and I suppose that each software vendor has proprietary tests and checks that they do.

What there really needs to be is ONE set of consistency checks that is used by everyone, not different versions of tests and checks which cause different versions of consistent and inconsistent.

I have made available all of my fundamental accounting concepts work free of any restrictions at all to XBRL US or anyone else for that matter.  I really hope they take advantage of that work.  I would encourage everyone to encourage the XBRL-US Data Quality Committee to consider leveraging this work.

All of this can be downloaded here.  Perhaps what I am doing is more sophisticated that what XBRL-US is doing right now or willing to take on.  However, the fundamental accounting concepts offers important information about how to best create the US GAAP XBRL Taxonomy and tests which will be important down the road.

I don't know if people remember my state-of-the art example of using XBRL definition relations.  These are more along the lines of what is really needed to get XBRL-based digital financial reports dialed in correctly. Those consistency checks will make more sense when software starts guiding professional accontants in the creation of financial reports (i.e. expert systems).

People will eventually figure this out. What about you?  Are you going to be proactive and therefore ahead of the curve or are you going to be reactive and therefore behind the curve playing catchup?

Each strategy has it pros and cons.  But either way: things are about to change big time.