linkedin facebook twitter rss

05 Feb Rings of Power: Workflow and Business Rules

One Ring plus toolsGandalf the Wizard explained the writing on the “One Ring”:

One Ring to rule them all, One Ring to find them, One Ring to bring them all and in the darkness bind them

Such a ring would be a nice thing to have, as long as it didn’t make you into a fascist – the world has had a few too many fascists already. IT fascism is probably not much better than other attempts at national or world domination. Perhaps we could modify the line to say: “One Ring to coordinate them all and in the canonical model reconcile them.”

Did your education endow you with the “One Ring” of power to work amazing wonders in your chosen field? If you were charged with building a new computer system or automated service, what tools would you use?  System, solution and capability designers approach design tasks in different ways depending on their skills, experience and successes and failures with past projects. Check out my posts on “Unruly Systems” and “Backward Chaining Logic”.

The central object of this blog is teaching computers how to do really hard things, like understanding human language, using context. Today’s discussion about workflow and inference rules is included in the section on cybernetic modeling. I consider this discussion important because my experience has given me empirical evidence of the power of these tools. Besides years of consulting in large and small companies that have benefited from using these models. I have developed successful products that use workflow models and backward- and forward-chaining rules. When I find something that works, I like to add it to my tool belt and pull it out when the task demands. This approach, I believe is necessary for performing the range of brain tasks that I have been blogging about. I further believe that workflow and rules engines are almost as neuromorphic, or more so, than connectionist neural networks.

Understanding Context Cross-Reference
Click on these Links to other posts and glossary/bibliography references

  

Section 7 #11

AI Modeling Section Icon

 

Table of Context

Systaltic Flow in Computers

Workflow and Business Rules are fundamentally different, and they exist in a natural hierarchy, analogous to brain functionality. The structure and flow patterns of the brain are built in: language perception flows through the layers of the visual cortex (reading text), and/or the receptive speech area (audio text) to correlating layers and finally to the frontal cortex. Let’s compare this systolic flow to a business process workflow. Now, in the frontal cortex, like the other parts of the brain, the neurons are interconnected in ways that change the amount of flow to different neurons and groups of neurons. Let’s compare this complementary or diastolic flow to a stored repository of rules, in which the ones that receive sufficient heat, fire and the ones that fire the hottest tend to win and bubble up to conscious prominence. The sequential nature of the workflow may be used to invoke rules in sequential processing models in which rules may appear at any step along the way. Rules may be triggered to establish context and determine the correct workflow to invoke. They work together.

Sequence is often needed in rules in that you often must evaluate conditions in a specified order, and the rule may trigger multiple consequences or actions, some of which may need to execute in a specified order. As an example…   These sequencing requirements may be handled by decomposing the rules and inserting them in workflows.

Workflow Linearity

Logic may also be required in workflows. These requirements may be satisfied by embedding rules at specific steps along a process definition. Both the workflow branching mechanisms and the rules’ branching are data driven. Whenever you don’t know in advance where the dialog is going, data driven approaches often deliver the most adaptability. Amzi discusses the data driven aspects of this approach in their explanation of OOPS, a forward-chaining production system in Prolog. My model of an expert system (illustrated below) incorporates such an inference engine.

Expert System Architecture

Forward chaining rules engines are often called “production” systems because, in them, each of the rules is a compact procedure called a production. The rules are of the form:  left hand side (LHS) ==> right hand side (RHS) meaning “Whenever the conditions on the LHS are true, do whatever the RHS tells you to do.” The LHS contains one or more conditions which must be evaluated to be true based on data in working memory for the rule to be  executed. The RHS contains one or more actions to take if the LHS conditions are met. Some rules are limited to one pass during the course of a process, while with others, whenever the patterns in the left hand side of the rule match subject data elements, the actions on the right hand side are executed. Production systems are minimally composed of three components:

  1.  any number of rule sets, each serving a specific category or process;
  2. a working memory area with the subject data elements and some metadata;
  3. an inference engine that apply the rules in the context of data elements and metadata.

Enforce the Rules

The approach I just defined applies most often to forward-chaining rules such as those in a production system. Goal directed or backward-chaining rules, that know the finite set of outcomes required and work through the rules to see which best lead to the goal, may also be used with workflow scripts, but the implementation requires that, instead of identifying which rules to apply at which step, you identify which goals to seek at each step, and the backward-chaining system determines which rules to use.

My assessment of forward and backward inference engines is that they can perform difficult reasoning tasks, not unlike the human brain. I think combining production rules with the sequential logic of a guided workflow engine make for a powerful combination that can approach human competence in some complex reasoning tasks. I have also used the approach to successfully design significant customer-facing capabilities where the customer doesn’t always know the right words to ask for what they need. Workflow, rules and human language understanding combine to provide powerful solutions.

In future posts, I plan to show how advanced models for business process modeling can be combined with intelligent capabilities, such as highly accurate language understanding and dialog, to deliver capabilities beyond those available in today’s systems and architectures. The illustration below is a taste of the future architecture.

Joes BPM Illustration

Click below to look in each Understanding Context section


 

Comments are closed.