Beyond Rules Engines

The Genesis of Goal–Directed Technology

Peter Evans-Greenwoodpeter@evans-greenwood.com

Abstract

Agent technology represents a new generation of software that brings the power and sophisti-cation of goal–directed reasoning and plan-ning to business applications for the first time. The technology was developed during the early 80s in reaction to the perceived limitations of the rule–based systems (expert systems) that were in wide use at the time. Goal–directed technology builds on the rule–based technolo-gies that preceded it, overcoming their limita-tions by integrating support for procedural reasoning; the step–by–step, trial–and–error approach that a person typically uses to solve a problem.

Goal–Directed technology enables the devel-opment of more flexible and robust applica-tions; applications that are aligned with the business and that allow enterprise systems to adapt rapidly in the face of changing require-ments.

Introduction

Commercial rule–based technology appeared during the 80s when expert systems first emerged[1]. For the first time these systems allowed business rules to be captured directly.

Rule–based technology forms rules as IF … THEN … expressions, with the then portion describing an action to be executed when the expression specified by the if clause becomes true. Whenever the rules engine receives a piece of data from the outside world (or is trig-gered by an external action) the rules engine considers the if clauses of all the rules to deter-mine which rules had been effected. The then clauses of all activated rules are then processed in some defined order (for example: the order in which the rules where activated, based on a priority assigned to each rule, or even alphabet-ical by rule name), with each then executed as its rule was processed. A rule’s action can range from simply updating a variable through

to a sequence of actions, including calls to external systems.

The first few rule–based applications showed a great deal of promise[2,3,4]. They provided clear and concise definitions of expert, rule–based knowledge from a range of disparate fields (for example: medical diagnosis or fault finding) and successful business systems where built around the technology. Rule–based tech-nology promised to provide an elegant and simple methodology for capturing complex business rules. However, it quickly became evident that the technology faced significant problems as the number of rules, and their complexity, increased. Mainstream commercial adoption was hampered by two major limitations: fragility of large rule–bases and the difficulty in capturing procedural knowledge.

FragilityRule–sets with a large number of individual rules (typically more than 1,000) become frag-ile. As the rule–sets expanded it became increasingly difficult to predict the result an application would provide for a given input; with the rule–engine generating essentially non–deterministic answers.

A rule–set is similar to a series of IF… THEN … statements in a procedural language, but they are not used in a procedural manner. Con-ventional sequences of IF … THEN … state-ments are executed at a specific time and in a specific order, according to how the program-mer creates them, while rules are potentially executed whenever their IF parts are satisfied. This makes rule engines less deterministic, and more fragile, than a typical procedural pro-gramming language when they are not used with care. There are two contributing factors to this fragility: the difficulty in predicting how a new rule will integrate into the existing rule–set, and the challenges in maintaining a dispar-ate set of related rules.

The set of executable rules in a rules–based application are considered as a flat set when evaluated, with each rule defined separately and given equal importance; however, the real-ity is that the rules are interrelated. Sub–sets of rules can share clauses in their if portion:

The Customer is in arrears ANDThe Customer lives in CA→…

The Customer is in arrears ANDThe Customer lives in DC→…

or rules may be contrary, specifying alterna-tives open to the application:

The customer is in arrears→…

The customer is not in arrears→…

All new rules must be specified in a way that is complimentary to existing rules, ensuring that they do not conflict with existing rules. A rule must be completely specified to ensure that it will only be triggered when it is appropriate.

If the rule introduces a new variable then exist-ing rules may need to be extended by adding a clause including the variable, and preventing the existing rules from being triggered when they are not required.

The Customer is in arrears ANDThe Customer is not in good standing→…

The Customer is in arrears ANDThe Customer is in good standing→…

If a rule is not completely specified then it may be activated unexpectedly, as the result gener-ated by the application will depend on the order in which the rules are processed. A new — incompletely specified — rule can change the output of the application when it is activated unexpectedly.

The customer is in arrears→…

The customer is in arrears ANDThe customer is not in good standing→…

Care must be taken to ensure that related rules are consistent, as changes to the shared clause in one rule must be accurately reflected in all related rules. Errors and inconsistencies inevi-tably creep in as rules are added and mainte-nance demands increase. The answer that a rule–set provides for a given input can change dramatically due to small adjustments to its constituent rules, as the final answer depends not only on the individual rules but the on interactions between the rules and the order in which the rules where activated. Small mainte-nance changes can have unforeseen effects on the application, and it becomes difficult to determine which rules will be triggered for a given input, and what the applications final result will be.

Modern rules engines have features specifi-cally designed to overcome these limitations. Ideas from procedural programming languages have been adapted to rules technology, allow-ing developers to create groups of rules that may be selectively enabled or disabled during program execution. Rules can be organized into a tree, capturing some of the dependencies between rules, or be assigned a priority. How-ever, these extensions introduce traditional pro-gramming constructs that run counter to the conceptual simplicity that was one of the tech-nology’s original attractions. Previously appli-cations would consist of a set of cleanly defined business rules, whereas now the rules are obscured behind extensions that are designed to overcome the technology’s limita-tions.

Procedural KnowledgeThe second limitation of rule–based technol-ogy is the difficulty in capturing procedural knowledge. The declarative nature of the tech-nology — where a rule is declared or specified as an IF … THEN … expression — forces developers to use multiple rules to capture a procedure. A simple step–wise process must be broken into a rule for each step, and new vari-ables are used to capture the stable state between each step. For example, the following simple process:

When order is submitted→Validate the orderCheck the customer’s creditProvision the orderSchedule delivery with the customer’sagreementInvoice the customer

can be mapped to the following set of rules:

When an order is received ANDthe order is not validated→Validate the order

When an order is received ANDthe order is valid→Check the customer’s credit

When an order is received ANDthe order is valid ANDthe customer has credit→Schedule the delivery

When a delivery is scheduled→Verify the schedule with the customer

When the customer has verified thedelivery→Invoice the customer

with additional rules required for failure and error conditions.

Procedural knowledge is awkward to capture with rule–based technology. Procedures are, in effect, transformed into large state machines, with each state transition specified by a rule in the rule–set. A simple procedure can rapidly become a large and unwieldy state–machine that is difficult to build and maintain, while the additional rules this approach creates only adds to the fragility of the application. The declara-tive nature of rule–based technology does not match well with the style of procedural knowl-edge that is common in business.

Again, modern rules engines have extended the core rule–based technology to overcome this limitation. Developers can create multi–step statements as the THEN part of the rule or allow a rule to trigger an external process, allowing some additional procedural rules and states to be collapsed into a single rule. Trivial state transitions that are used only to order operations can then be removed.

When an order is received ANDthe order is not validated→Validate the order

When an order is received ANDthe order is valid→Check the customer’s credit

When an order is received ANDthe order is valid ANDthe customer has credit→Schedule the deliveryVerify the schedule with the customer

When the customer has verified thedelivery→Invoice the customer

As with the extensions to overcome fragility, extensions for capturing procedural business logic introduce traditional programming con-structs that run counter to the conceptual sim-plicity that was one of the original attractions of the technology. The cleanly defined business rules are obscured by the explosion of rules required to support procedural logic, and the addition of sequences of operations in the THEN part of a rule breaks from the simply declarative nature of the original rules based systems.

Procedural Knowledge

After the early explosive growth of expect sys-tems, rule–based technology began to flounder in the face of these and other real world com-plexities and researchers looked to other ways of capturing knowledge.

Rule–based technology is based on a simple model of how people store and process knowl-edge. It breaks knowledge into a set of atomic rules — IF the customer is in arrears THEN we call in debt collectors — but this model does not truly capture how people make deci-sions and act. Researchers turned to work in philosophy and the psychology[5] for a more sophisticated model that could capture proce-dural knowledge; the know–how describing how to perform some task. Procedural knowl-edge is different from rule–based knowledge as it applies directly to tasks, providing us with a tool for capturing the trial–and–error, step–by–

step approach that a human uses to solve a problem.

Investigations into supporting procedural knowledge[6] began during the expert system boom, but the approach did not come into its own until the limitations of rules–based tech-nology were uncovered. The first systems based on this technology were developed dur-ing the mid–eighties, delivering solutions to problems that had been intractable with rules–based technology. The seminal application was the NASA Space Shuttle RCS Malfunction Handling System[7]. This application builds on the first tools for the technology (Procedural Reasoning System[8] (PRS), which is still in use today) and includes approximately 60 pro-cedures extracted from NASA's RCS malfunc-tion handling manual, another 60 procedures to interface with the shuttle's computer, and a few higher level reasoning procedures that imple-ment policies for dynamically selecting a pro-cedure for execution when multiple procedures are eligible.

Towards Goal–Directed Behaviour with Backward–ChainingThis new approach is built on the techniques and lessons learned during the development of commercial rule–based technology platforms. One of the more advanced features of rule–based technology is its ability to support goal–directed behaviour. When presented with a problem the engine can be configured to proac-tively seek a solution.

Goal–Directed behav-iour relies on back-ward–chaining; a technique used by rules engines to enable the goal–directed, trial–and–error, approach to problem solving. Nor-mally the rules engine is configured to sup-

port forward–chaining: navigating forward from the IF portion on the left of a rule to the THEN on the right (shown to the right). The executing engine examines the IF portions of all the rules it contains to determine which are true, and activates them. The engine works for-

ward for each of the activated rules, executing their THEN portions in turn.

To enable backward–chaining, first we identify which possible conclusions to test for. For example, suppose that we want to check a cus-tomer’s credit status before an order can be accepted, posting a goal to establish the cus-tomer’s credit status. To achieve this goal the rules engine would search for all rules whose THEN part included a conclusion that the cus-tomer has sufficient credit for the purchase (e.g. IF the customer has no outstanding debt with the company THEN assert that the cus-tomer has sufficient credit). Each rule is exam-ined, in turn, working backward from the conclusion to determine if the IF portion is sat-isfied. If so, then the goal is achieved. If not, then the rules engine will continue searching until all rules have been examined. (Sophisti-cated applications can search rules recursively, evaluating rules that depend on other rules.)

Backwards–chaining allows us to create rule–based applications that are more flexible than a simple forward–chaining system can offer. However, the application will still suffer from the same limitations as all other rule–based applications — fragility from a large, diverse rule base and the inability to capture the sequential, task–based, procedural knowledge.

Goal–Directed TechnologyGoal–directed technology builds on the suc-cesses of rule–based technology to directly support procedural knowledge. The technology introduces explicit support for goals and sequential processes to allow developers to specify procedural knowledge as a series of plans.

Plans are the corner-stone of the approach; each plan captures one plan of action — one process — which rep-resents a fragment of procedural knowledge. A plan is one possible way to achieve a goal. Plans are specified in three parts (shown in

the figure above):

IF {…} THEN {…}

IF {…} THEN {…}

Forward Chaining

BackwardChaining

Goal:Context:

Goal. Specifying what goal the plan will achieve. For example, to accept the order.

Context. A rule that specifies when the plan can be used. If the rule is true, then the plan is applicable and can be used. If the rule is false, then the plan is not applicable and will not be considered. For example, IF build–to–cash.

Process. The step–by–step process, that is, how to achieve the goal, within the context. The process is specified with a conventional procedural language; with the addition that new goals (sub–goals) can be posted by the process.

The operation of goal–directed technology is similar to that of a backward–chaining rules engine, with the process as the THEN part of

the rule, and the goal as the IF part1. When a new goal is posted, the goal–directed engine surveys all the plans associated with the posted goal. Each of these plans is examined to deter-mine if its context rule is true — if the plan is applicable. The engine selects one plan from the set of applicable plans and begins execu-tion. (This is similar to rule selection in an rules engine, and can be based on factors such as priority, the order the plans where identified in, or it may even be random.) If the selected plan fails it is discarded, another plan is selected from the set of applicable plans and execution begins again. If the plan completes successfully, then the goal has been achieved.

This tight integration of rules, processes and goals allows us to directly model the trial–and–error, step–by–step nature of how people solve real world problems. Goals capture the trial–and–error nature by allowing the goal–directed engine to automatically try alternate ways of achieving a goal (alternate plans) without requiring developers to specify every possible combination of plans. The plan process allows the step–by–step nature of tasks to be explicitly

modelled. The ability to explicitly create goals (and sub–goals) mirrors a person’s intentions and thought processes when problem solving. Goal–directed technology allows us to capture, and directly execute, the procedural knowledge that we all use to solve everyday problems.

Avoiding the Problems of the PastSince goal–directed technology is derived from the rule–based technology, how does the tech-nology avoid its predecessor’s limitations?

The problem of fragility was due primarily to our inability to manage large, flat, rule sets. Goal–directed technology avoids this by break-ing the rule set (the set of plans) into groups, with each group answering a specific goal. Goals are a natural way of grouping rules, leveraging the associations between rules rather than working against them. When a goal is posted, only those plans that are designed to answer the goal are considered, and the goal–directed engine never considers plans that do not answer the posted goal. Grouping plans by goal allows us to create relationships between plans that avoid the maintenance problems of rule–sets. New goals only impact plans that either call the goal directly, or plans specifi-cally created to achieve the goal.

The process portion of a plan allows the step–by–step nature of a task to be directly mod-elled, without the need to embed state–machines inside rules using additional vari-ables.

The Technology in a Modern Context

Goal–directed technology has matured during the 25 years since it was created. From the first successful systems the technology has become part of the larger agent technology move-ment[9]. Agent technology promises answers to some of the challenges facing enterprise software today. The technology provides an anthropomorphic view of software, one that allows us to construct systems from collections of cooperating agents. Problems are decom-posed into a set of software agents, each with its own goals, strategies and intentions. Solu-tions are then constructed by organizing agents into teams capable of cooperating and negotiat-ing to achieve a set of common goals.

1. In an rules engine the context in a goal–based solu-tion is represented by an additional clause in the IF part of a rule. For example, a goal to determine if there is sufficient credit for the purchase may have two plans: for build–to–cash and for build–to–cash. The rules engine would represent these as separate rules: IF sufficient credit AND build–to–cash THEN …, and IF sufficient credit AND build–to–stock THEN …

Goal–directed technology provides a sophisti-cated tool for modelling the human decision–making and problem solving process. This is complemented by other work in agent technol-ogy which provides tools for thinking about (and building) applications that leverage ideas from areas as diverse as economics and linguis-tics, creating applications that exhibit the rich-ness and capability of systems seen in the natural world[10]. There have been a number of notable successes for the technology, solv-ing core business problems such as: air traffic control, freight handling, order fulfilment and logistics optimization, and distributed network management[11].

Conclusions

Goal–directed technology is a new technology that, for the first time, allows applications to capture the richness and flexibility of human reasoning in a straight–forward fashion. It inte-grates the best ideas behind rule–based and conventional approaches to deliver applica-tions that can mirror the task–based, trial–and–error, nature of human problem solving in a way that both scalable and maintainable. Tomorrow, the development of enterprise ready agent–based tools and techniques will enable us to create more sophisticated applications that are capable to automating the complicated decision and exception management processes that are currently beyond our reach.

References

1. Charles L Forgy (1981), OPS5 User's Man-ual, Technical Report CMU-CS-81-135, Carnegie Mellon University

2. J. McDermott (1982), R1: A rule based configurer of computer systems, Artificial Intelligence, 19, 39–88.

3. Shortliffe, Edward H.(1981), Consultation Systems for Physicians: The Role of Artifi-cial Intelligence Techniques. In Webber, Bonnie L.and Nilsson, Nils J. (Eds), Read-ings in Artificial Intelligence. pp323-333. Tioga Publishing Company, Palo Alto, Cal-ifornia.

4. Shpilberg, David and Lynford E. Graham, (1986) Developing ExperTAX: An Expert System for Corporate Tax Accrual and Planning, Auditing. 6(1), pp. 75-94.

5. M. Bratman (1987), Intentions, Plans and Practical Reason, Harvard University Press

6. M. Georgeff and A. Lansky (1986), Proce-dural Knowledge, Proceedings of the IEEE (Special Issue on Knowledge Representa-tion), 74:1383--1398

7. M. Georgeff and F. Ingrand (1990), Real–Time Reasoning: The Monitoring and Con-trol of Spacecraft Systems, in Proceedings of the Sixth IEEE Conference on Artificial Intelligence Applications.

8. K. L. Myers (1997), User Guide for the Procedural Reasoning System, Technical Report, Artificial Intelligence Center, Tech-nical Report, SRI International, Menlo Park, CA.

9. Michael Wooldridge & Paolo Ciancarini (January 2001), Agent–Oriented Software Engineering: The State of the Art, in Agent–Oriented Software Engineering. Springer–Verlag Lecture Notes in AI Vol-ume 1957

10. Nicholas Jennings (2001), An Agent Based Approach to Building Complex Systems, Communications of the ACM, Volume 44, Number 4

11. Paul Taylor, Peter Evans–Greenwood & James Odell (2005), Agentis in the Enter-prise, in Proceedings of the Australian Software Engineering Conference (ASWEC).