How the CODIL model was developed,

A detailed paper discussing the theory underlying CODIL, and it relevance to modelling the human brain and its connections with more conventional computing models is being drafted.  This post summaries the main issues to be included in that paper.

 

CODIL started in the 1960's and is best understood as a research project to develop an "interactive electronic" clerk that could work symbiotically with humans in the context of very large organisations and management information systems.  The key requirement was that the clerk used the human terminology to describe the task, was fully transparent and could, if asked, explain what it was doing. There was no explicit attempt to model human intelligence, but the hope would be that the human/computer partnership would be more effective than humans working alone.   The current reassessment of the original research, interpreted in terms of a network, suggests CODIL unintentionally  reversed engineered some aspects of how the human brain stores and processes information and supports intelligence. It is therefore not surprising the CODIL system uses a very different model of information processing to the stored program computer model based on the pioneering work of Turing and Von Neumann.

 

If we go back to first principles any observer of the real world will have an incomplete and uncertain view of the surrounding environment, whether the observer is a small animal (human ancestor) with a primitive brain eons ago, a human adult, or a large social organisation. In 2002 Donald Rumsfeld described the importance of real world uncertainty in a large organisation :

Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don't know we don't know. And if one looks throughout the history of our country and other free countries, it is the latter category that tends to be the difficult ones.

Although the CODIL research effectively began in the 1960s Rumsfeld's later description serves as a good starting point for emphasising how CODIL differs from the stored program computer model:

 

The CODIL model assumes incomplete knowledge.  Information must be held in a way that does not require a formal distinction between rules (i.e. program) and data. However it does assume that real world "objects" can be recognised and named, and names can also be given to collections of related objects (sets). Information relating to objects is stored in named sets which are mapped onto an associatively addressed network where each node in the network represents a named set (or subset, or set-generating function) and where the links between nodes is defined by set membership.  

 

Information in this network is processed in a way which is very different from the command-driven approach of the  stored program computer and a very simple example illustrates how this works.

 

 If the human wants the "electronic clerk" to provide a price (initially a human "known unknown") for goods delivered to a customer he would provide information (initially human "known knowns") in a form such as:

 

CUSTOMER = Joe Bloggs; PRODUCT = Widget; QUANTITY = 20

 

The clerk places these into a set called the FACTS which is a "window" which forms part of the user interface and provides the human with details of the clerk's active "known knowns". The FACTS window is deliberately kept small to avoid overloading the human's short term memory. (In the first interpreter one of the goals was to find the maximum size of the FACTS workspace and the limit was set at 32. This proved over generous and for many tasks the typical number of set/nodes active at any one time will be well under a dozen, and fits in well with the idea that the human short term memory can only retain about 7 items of information at any one time.)

The electronic clerk will already be storing a large network of nodes relating to statements describing customer contracts. pricing lists, etc, as predefined "known knowns". For example:

 

CUSTOMER = Jack Crow; PRODUCT = Zocco; DISCOUNT = 20%

and

PRODUCT = Widget; QUANTITY > 10; UNIT PRICE = 11.5

                                      QUANTITY > 100; UNIT PRICE = 9.5

 

The CODIL decision making unit works on the basis that any nodes incompatible with the FACTS are "invisible" - so that nodes that refer to members of the CUSTOMER set which do not include "Joe Blogs" are automatically hidden because they are irrelevant.  (In the real world invoicing application study that preceded the development of CODIL simply naming a customer would logically reduce the search space by about 999.999%. Mentioning a product as well would reduce the search space even further). The result is that the CODIL decision making unit only needs to explore the "true in context" paths through the network of sets, and in this tiny example deduces that UNIT PRICE = 9.5 is addition "known known" which must be added to the FACTS. In the later versions of CODIL a node can be labelled "QUERY" to indicate that it is a "known unknown" node. When such a node is activated the clerk will ask the human user for more information to resolve the issue.

 

In effect the CODIL model reflects the logic underlying human intelligence. The electronic clerk works with an active current context (The FACTS) which is designed to work like the human short term memory - and makes it easy for a human observer to understand what it is doing. In particular the CODIL approach uses the context to focus on a subset of the total network for active consideration (equivalent to being conscious?) and it is only at this stage that the decision is made as to which nodes in the network are open/closed  gateways (equivalent to a conditional IF test in a stored program computer) and which nodes provide new FACTS (equivalent to assignment statement is a stored program computer.)

In stored program computer terms the CODIL decision making unit traces out in real time what could be considered to be a tailor-made mini-program for processing the single transaction currently described in the FACTS.  This avoid the need (in the stored program model) for a human programmer/systems analyst to try and anticipate every possible type of transaction in advance and then produce a pre-defined global "black box" algorithm which will hopefully handle all transactions.

This short account does not discuss the role of "demons" (such a QUERY mentioned earlier) which relate to input and output of information, handle fuzzy logic, leaning with feedback, and defining alternative routes through the network. These issues, and the relation between CODIL and natural language will be covered by future posts on this blog.