Digital Financial Reporting

The following is a summary of the business case for PROLOG that I have gleaned from various other sources including this and this and this and this. 

• Modern implementations of Prolog (PROgramming LOGic) are based on technology that has been around for over 40 years.  Prolog has a long, proven track record.
• Prolog is an ISO standard. There is a core set of Prolog notation which tends to be provided by most Prolog systems and there is now an ISO standard for that specific subset of the language.
• The Prolog relational paradigm fits well with tabular data such as that within a relational database management system (RDBMS), while optimized support for recursive code fits well with graph or "tree" shaped information such as RDF or graph databases.
• Prolog reduces development costs and maintenance costs.  With declarative logic programming languages like Prolog, code is generally more reusable, business logic can be separated from program flow logic, Prolog code is more readable than languages like Java or C++ or C#, and therefore software maintenance costs (which can be 60% of total development cost) is significantly reduced.
• Prolog is Turing complete. Turing complete means reliability and predictability. While most programming languages these days are Turing complete, they may not be used that way.
• There are 20 different Prolog implementations.
• Free versions of Prolog exist such as SWI Prolog. Open source Prolog implementations exist.  There are many, many open source Prolog related projects.
• Here are other specific Prolog features.

Prolog is not a tool business professionals would ever be exposed to.  Business professionals would be exposed to high-level interfaces that they understand and can work with.

As pointed out in the article, Building a Custom Rules Engine with Prolog, there benefits to using the right tool for the right job. Here are some exerpts from that article: 

The primary problem was that the flow-of-control branching if-then statements of a procedural language did not have the same semantics as the pattern-matching if-then rules of logical relationships. Developers must make arbitrary decisions of where in the flow-of-control to code each branch, thereby entangling the declarative rules in the thread of execution.

This is clearly an advantage over the procedural approach, and also a big advantage over rule-based approaches that do not provide ontologies. In a pure rule-based approach, these definitions would all have to be implemented as rules. Having the writers of the rules stick to a limited vocabulary doesn't work because so many different vaccines and spellings appear in the medical records. It is the ontology that makes it practical to use the existing medical records.

Unlike factual or procedural knowledge, logical knowledge is difficult to encode in a computer. However, the ability for organizations to successfully encode their logical knowledge can lead to better services for users. The question, then, is how best to encode logical knowledge. It can be shoe-horned into data- and procedure-based tools, but the encoding is difficult, the knowledge becomes opaque, and maintenance becomes a nightmare. Rule-based and logic-based tools are better suited to the encoding of logical knowledge, but require the selection of the proper tool for the knowledge to be encoded, and the learning of how to use that tool. Off-the-shelf rule or logic tools sometimes provide a good solution, but often the knowledge representation of the tool doesn't fit the actual knowledge, or the reasoning engine doesn't use the knowledge as it is supposed to be used. This leads to the same coding and maintenance problems experienced with conventional tools, but to a lesser extent depending on how big the semantic gap is between the knowledge and the tool.

A viable alternative is the building of a custom logic-based language and reasoning engine. This allows for the closest fit between the coding of the knowledge and the actual knowledge, and for the cleanest integration between the tool and the rest of the application context.

Specialized tools are easier to use that general tools.

An example of using PROLOG is PROLEG which is programming logic for the legal industry.  PROLEG is described as an "interactive system for arranging issues". This video, Introduction to PROLeg, and this paper, PROLEG: An Implementation of the Presupposed Ultimate Fact Theory of Japanese Civil Code by PROLOG Technology, and this paper Introduction to PROLEG provide examples of the capabilities of PROLEG.  Effectively, this seems to be a specialized subset of Logical English.  This is very likely how financial reporting rules will be written in the near future.

Prolog seems to be a possible candidate for the unifying logic framework for business that I was seeking.

##########################

Have you Heard of PROLOG?

Fifty Years of PROLOG and Beyond

PROLOG at 50

2022: The Year of Prolog

PROLOG (PROgramming in LOGic) is a declarative logic programming language that was created almost 50 years ago.  SWI-Prolog is a robust and free implementation of PROLOG that was created starting in 1987, so it is quite mature.  It can run locally or in the cloud. Note that there is an ISO Standard PROLOG. (i.e. there is a core set of notation which tends to be provided by most Prolog systems and there is now an ISO standard for the language)

Logical Contracts, a company that specializes in PROLOG (Robert Kowalski, a co-designer of PROLOG, is a partner) which has created a PROLOG implementation of XBRL-based report verification. This short video and this short video walk you through how to run the implementation.

I am testing the PROLOG impelementation to be sure it deals with everything in my SBRM PROOF which exercizes all that you would ever see in an XBRL-based financial report.

Here is additional information about PROLOG: 

• Another PROTOTYPE Implementation (by the same person)
• More information about PROLOG

What is of particular interest is the short time that it took to put together the PROLOG implementation.  Now, the person has 30+ years of experience with PROLOG.  The first prototype took about 50 hours with ZERO knowledge of XBRL by the programmer.  The second, which is commercial quality, took about another 30 hours.

More information coming soon, so stay tuned!  If you don't understand why this is a very good thing, you will want to read the four documents here.

####################################

Prolog Business Case

Prolog Tutorial (Video playlist) (SWI Prolog)

Prolog Tutorial (Video) (GNU Prolog)

Comparison of SWI Prolog and RDF

An Introduction to Prolog and RDF

Building Expert Systems in Prolog

PROLOG Cheat Sheet

SWI-Prolog Semantic Web Libraries

Power of Prolog

PROLOG Facts, Rules, Queries

Full Prolog

Auditing is broken. Old school financial reporting processes are inefficient. Accounting is inefficient. Analysis tends to be too manual.  Accounting, reporting, auditing, and analysis needs to move to 21st century techniques.

Old technologies are making it increasingly difficult to keep up with today’s fast paced information exchange. New technologies such as structured information, artificial intelligence, digital distributed ledgers offer significant and compelling opportunities to make accounting, reporting, auditing, and analysis tasks and processes more efficient and effective.  But figuring out how to employ these new technologies and finding people with the necessary skills and experience to analyze systems and fix problems can be challenging. What if there were a standards-based proven best practices method you could use to improve your productivity?

The difference between "custom", a "product", and a "commodity" is explained in this blog post, Properties of Products. In summary,  

• Custom: Means unique to each individual customer. No attempt is made to standardize.
• Product: Found repeatable patterns (clusters), created a product for each pattern. Standards can be used. (As Malcom Gladwell explained in a TED Talk, "The answer is that there is no best pickle or spaghetti sauce.  But there are best clusters of pickles and spaghetti sauces.")
• Commodity: Generalize the product so much that it is fungible, indistinguishable. Standards can be used.

An XBRL-based digital financial report should be indistinguishable in terms of quality.  Are their customers that consciously want low quality?  That would be absurd.  As such, high-quality XBRL-based digital financial reports should be a commodity.

"Custom" is not scalable.  While standard approaches do allow scaling.

Companies should not compete as to whether they can or cannot create high-quality XBRL-based reports.  We need ALL such reports to be of high quailty.  Companies should compete in terms of value added above and beyond fundamental quality, building on top of a rock-solid digital financial report foundation.  Why? So we can reliably and predictably do this:

If XBRL-based reports fundamentally do not work reliably, then such reports are nothing more than an expensive garbage collection scheme.  But what if they do work?

I have put together a series of documents that can jumpstart your understanding of XBRL-based digital financial reporting.  Those documents add up to a total of 161 pages.  If you want to make a small investment, you can learn about XBRL-based digital financial reporting and how those techniques also apply to accounting, auditing, and analysis. Here are the documents in the order that I would suggest that you read them: 

• Understanding Proof: Proves that XBRL-based reports can work and shows you what such a working report looks like and is capable of. (30 pages)
• Understanding Method: Explains, at a high level, a proven, reliable, best practice method for implementing XBRL-based digital financial reporting following the forthcoming OMG Standard Business Report Model (SBRM). (35 pages)
• Understanding Digital: Helps professional accountants get their heads around important aspects of digital related to accounting, reporting, auditing, and analysis. (84 pages)
• Understanding Semantic Shreadsheets: Takes the ideas of XBRL-based financial reports and generalizes them to business reporting. (12 pages)

Not saying that the documents are perfect; they are the best that I can put together currently.  Myself or others will improve this information even more over time.

Want to make a bigger investment? Watch this video playlist and/or read Mastering XBRL-based Digital Financial Reporting.

Forbes published an article, 3 Important Ways Artificial Intelligence Will Transform Your Business And Turbocharge Success, explains that organizations are leveraging AI in three ways: 

• Creating more intelligent products;
• Offering a more intelligent service; (another Forbes article breaks this down)
  • Delivering highly personalized offerings
  • Giving customers more value
  • Predicting customers needs
• Improving internal business processes

These are not mutually exclusive.

It appears that this resource provides a means of extracting information from an XBRL instance and converting it to R.  Not totally sure about that, but that is what this appears to be.  See RCPP. See this on GitHub. See this also.

It appears to be the case that this resource sufferes from the same fundamental problem of Google's BigQuery repository of SEC public company information.