Backward Chaining, Logic Programming Rules

Backward chaining starts with an assertion that is true if an associated condition is true. Prolog is a well-known language for backward chaining or “logic programming.” The condition may be evaluated by evaluating the truth of each element. The truth of each element, in turn, may be based on other conditions. Backward chaining is often used for diagnosis.

We might think of the basic form of a logic programming rule as then-if. For example, the “result” might be, “the car won’t start.” We then look for potential reasons—in other words, things that, if true, would cause the car to not start. So, in a rather informal form, the rules might look something like this:

 Car-wont-start(?) <= Battery-dead(?) or Flooded(?) or Out-of-gasoline(?)
 Battery-dead(?) <= Lights-dont-go-on(?)
 Flooded(?) <= Smell-gasoline(?)
 Out-of-gasoline(?) <= Fuel-gauge-shows-empty(?)

Here the question mark (?) represents a reference to the particular vehicle under consideration. More complex rules might reference additional relevant entities or values.

If implemented as Prolog statements, the execution would start with the first rule, where we are interested in finding a potential reason that Car-wont-start could be true. In order for Car-wont-start to be true, one of the subsequent statements must be true, that is, Battery-dead or …If we consider Battery-dead, we see that the next rule evaluates Battery-dead. If Lights-dont-go-on is true, then Battery-dead is true and the cause of Car-wont-start is found. If Lights-dont-go-on is false, then Battery-dead is false and we return to the first rule (we “backtrack”) to examine the next possibility: Flooded. The nesting of rules can be very complex. The ordering and structure of the rules determines the order in which questions are asked. For example, if Lights-dont-go-on is true, we have completed the search and we need not ask about Smell-gasoline or Fuel-gauge-shows-empty.

Note that when one path of the search fails, the search returns up the search tree to explore an alternative path. This is commonly called backtracking and enables the exploration of alternative solutions. Some problems may have multiple possible solutions that can be identified and considered. Such alternatives might have different levels of risk or probabilities of success as in a medical diagnosis and treatment. The risks might be computed from multiple factors involved in a suggested action.

The example is quite trivial; it fails to demonstrate many capabilities of Prolog, it does not cover all possible causes of nonstarting car, and the result is fairly obvious. Much more complex problems can be addressed; among the most sophisticated is mathematical theorem proving.

Logic programming is important for implementing complex searches such as in diagnoses or identification of omissions and inconsistencies in models. The programmer can focus attention on defining the rules and does not need to deal with the mechanics of backward chaining and backtracking. Nevertheless, logic programming does require special skills and attention to the order in which statements are executed.

Forward Chaining, Production Rules

Forward chaining involves an alternative form of reasoning with rules, often called “production rules.” A production rule is triggered when its condition is met in a model of the problem domain—the model is often called the “working storage.” When a rule “fires” its action will update working storage causing other rules to fire. The actions of a sequence of rule executions produces (ie, production of) a working storage that is a solution to the problem.

Production rules are applied by a rules engine, as depicted in Fig. 5.1. A rules engine is a software product that applies rules to a problem. Generally, the rules reside in the runtime environment and, on request, the data representing a problem to be evaluated is loaded into the rules engine working storage. A Rete network (pronounced ree-tee) is created to link the rules to the working storage for efficient processing. The rules engine determines whether any of the rule conditions are met. If the conditions of more than one rule are met, the rules engine has logic to decide which rule to “fire” (ie, execute). When a rule fires, its action is performed. This action likely changes the data in working storage that defines a new, current situation; it may also cause some external effect. When the data change, the conditions of a different subset of the rules may be met, and the rules engine again selects a rule to fire.

This general class of rules processing is called forward chaining because the action of each fired rule updates the working storage model and affects the selection of the next rule and subsequent chain of actions. The generally accepted mechanism for evaluating, selecting, and firing rules is the Rete algorithm.

Note that rules engines that implement production rules (forward chaining) also usually include backward-chaining capabilities where an evaluation of a condition requires examination of other conditions on which it depends.

The application of production rules does not include backtracking to explore alternative sequences of rule firings. Backtracking would require the engine to determine the point in the search where an alternative rule should be fired and the changes to working storage that would need to be withdrawn to pursue the alternative path. The Rete network links to working storage would further complicate the backtracking.

Production rules are used to produce a complex configuration or a plan such as a process or project or configuration.

Data and Model Integrity Rules

Data integrity rules are first incorporated in data models and the design of databases. These rules may also be called business rules by developers of data models and designers of databases. They are constraints that exist in the real world. For example, a person cannot have a birth date in the future, and two people cannot have the same tax ID number. These rules do not change, and violation of these rules would indicate that the integrity of the associated database has been compromised.

Certain constraints are intrinsic to business concepts. For example, an organization unit cannot directly or indirectly report to itself, or a customer order must have at least one order item. These constraints ensure the validity of data when they are applied to data being entered by a person or received from another system.

Integrity rules may be considerably more complex. These rules may be defined in models and implemented in the computer applications. For example,

• In computer-assisted design models, a surface must have closed edges or the model is intrinsically invalid.

• In product specifications, for certain parts, there must not be more than one part number for the same application; for example, the conditions for use of different air conditioning compressors on a vehicle must be mutually exclusive.

• For process design, an iteration must have a termination condition.

• For an organization, a reporting relationship must not be circular.

• For a Value Delivery Modeling Language (VDML) model, the organization unit, management reporting relationships must not be circular (management hierarchy).

These constraints are defined to ensure the integrity of the model and are not dependent on the industry or the particular enterprise.

Some constraints are required to ensure data integrity from a business perspective. For example, a purchase order must be submitted or approved by a person with that level of financial authority. In this case, when a purchase order is entered, the rule will require an authorization that may direct a request, recursively, up the management chain until a person with sufficient authority is reached.

Data constraints are applied in databases to ensure that updates to not violate data integrity. In addition to constraints in databases, rules must be applied as data entry constraints and for validation of data received from other sources. Every field of every record created or received must be validated so that no actions are performed on invalid data. Processing of data should never reach the point where it is rejected in a database update.

This is not usually a concern in conventional systems, but when records are submitted to shared services, there is a greater risk that an invalid request could be submitted. Each service should apply the same rules to data received from other services as it would apply to data entered by a human. A service should be designed to be used in a variety of contexts and cannot assume that all sources are reliable. Similarly, a service may be used by new processes or processes that are independently upgraded or replaced in the future, resulting in potential incompatibility.

Event Rules

Event rules identify events of interest for monitoring or initiation of action. Event processing is discussed in detail in Chapter 8. Rules are important for recognition, filtering, and distribution of events.

Process Flow Control Rules

Some rules identify risks or expense to be avoided and divert process activity to mitigate or avoid the damage. Other rules recognize policy constraints that, under special circumstances or approvals, may be authorized. For example, all purchases of equipment must go through the purchase order process. However, if equipment is required to resolve a major disruption of operations, an individual can purchase the equipment and submit an expense report with appropriate justification. The constraint is violated, but there is a compensating process required.

Decision Model and Notation

Sometimes circumstances are not so simple. There may be multiple alternatives described by multiple rules. The decision model and notation (DMN, http://www.omg.org/spec/DMN/) specification of the Object Management Group (OMG) defines a facility for representation of these complex rules in tables.

Fig. 5.2 illustrates the typical structure of a DMN table. The rules are the bottom three rows. There are two input variables and two output variables. The lists of possible values of each input and each output are indicated. The hit indicator, “U”, indicates that each rule is unique (the conditions do not overlap). The completeness indicator, “C”, indicates that there are no gaps between rules, full coverage.

Note that rules 1 and 2 have the same input 1 value, and rule 3 has an input 2 value that is irrelevant—the rule only depends on the input 1 value.

There are various possible hit indicators and completeness indicators that can prescribe the sequence in which rules are evaluated and how overlaps or gaps in rule coverage should be resolved. There is an expression language for specification of the conditions in a form to be interpreted by computer. Each input value or output value may be a computed value dependent on multiple variables. The table can also take various shapes and accommodate different numbers of inputs, outputs and rules. A tool that implements DMN and supports easy configuration of the table graphics and proper syntax of expressions.

It is most useful for business users to express the inputs and outputs as text to be converted to formal expressions by technical people. A table with textual descriptions can be relatively easy to understand and validate unless there are many rules or variables.

The decisions modeled with DMN are explicit and predictable.

Selection

Backward chaining (or logic programming) is important for implementing complex searches. The programmer can focus attention on defining the rules and does not need to deal with the mechanics of backward chaining and backtracking. Nevertheless, logic programming does require special skills and attention to the order in which statements are executed.

For example, backward chaining can determine if the necessary elements to authorize a claim are present and return the allowable fee for the qualifying circumstances. This might include a determination that the claim has already been paid as part of another claim.

Diagnosis is another form of selection. Rules search for a diagnosis that exhibits the observed symptoms of a problem. Diagnosis is frequently a fundamental step in determining corrective action.

Rules provide the basis for selection of a performer to fill a role. Roles in any collaboration should be filled by people or service units that have the necessary skills, relationships, and authority to meet the needs of the collaboration while recognizing workload balancing objectives as discussed above.

Some collaborations are unstructured and require a mix of skills, relationships, and authority. For example, a task force may be assembled to address a particular business problem. The participants must have relevant skills, relationships to organizations that are affected by the problem and potential solution, and authority to gain access to the information needed to analyze and solve the problem. Not every person need have all the relevant skills, and it is likely that no one of them will have all of the organizational relationships or access authorization. Rules can be used to consider candidates for participation in the collaboration that, together, satisfy the requirements.

Different people with the same job classification may each have different, but overlapping skill sets and certifications. Assignments should reflect the level of demand for certain skills so that progress on some undertakings is not delayed because persons with critical skills are assigned to efforts that do not require those critical skills. This is again the workload balance problem discussed above.

A couple other factors may be considered. Even though activities within a collaboration can be done by different performers, assignment of one performer to a series of activities may result in higher productivity, quality, and job satisfaction. This continuity of participant must be curtailed where there is a requirement of separation of responsibility.

Product Design and Configuration Rules

Production rules are used to produce a configuration. Most often they are used for complex system configurations such as configuration of a complex product such as an automobile or a computer. For example, a rule may specify that “if a customer automobile order includes air conditioning, and if the order also includes an optional V-8 engine, then air conditioning compressor 1234 is added to the bill of materials.” Another rule may specify that “if air conditioning compressor 1234 is included, and the order also includes power windows or power door locks, then the alternator must be replaced by a heavy-duty alternator.”

Production rules might also be used for such computations as bill-of-materials generation, project planning, process planning, in-process inventory computation, design of experiments, or forecasting.

Since rules can be used to identify the parts required for a product configuration(s) this may be used to generate a bill of materials. An extension of the mechanism is to compute the addition of parts to correspond to a production-line sequence to determine assembled parts to determine inventory without emptying the production line.

Forward chaining may be used to generate a sequence of activities for a project plan or an adaptive process, coordinating the work of different participants. This is equivalent to planning a trip. You make assumptions about intermediate outcomes, but if an outcome is not as expected, then you replan from that point forward. The end objective remains the same. Each plan identifies the best path to reach the objective from the current point under current circumstances and assumptions.

Alternatively, a process can be dynamically defined as each activity is completed. As an activity is completed or an event is triggered (or in anticipation), production rules can determine the next activity(s) to be performed or considered for the particular situation based on the state of the process, the work product, and the objective. Rather than allow the rules engine to pick from the rules available to fire, the tentative action of each of the candidate rules could be presented to a knowledge worker. In such a process, there is no obvious, predefined flow, just a set of possible activities, events, and rules. This technique can fit quite well into an implementation of the CMMN specification.

A number of important features of a product can be computed (or estimated) using rules based on the configuration of the particular product (eg, car or truck).

• Weight can be computed as the sum of the components in the particular vehicle configuration.

• Cost of parts can be computed based on the particular configuration, but it is often more important to determine the cost based on product options (eg, air conditioning, power seats, sound system) which may involve different components for different vehicle configurations. Labor costs can also be computed based on product configuration. This can determine the cost of each unit, although idle operator time may be difficult to allocate. Overall production costs will be a function of the product mix.

• Fuel economy of an individual vehicle can be evaluated based on the components that affect fuel economy along with the impact of weight and aerodynamic characteristics of the vehicle model.

• Load capacity can be computed based on the suspension components and vehicle weight with some constraints based on the particular vehicle model.

• Failure mode analysis involves modeling components for analysis of potential failures and the consequences. This might be applied to the fuel system, the brake system, the drive train, and so on.

Governance

Governance is the responsibility of the board of directors or other governing body to ensure that the enterprise is “doing the right thing and doing it well.” Governance must be supported by the management of the enterprise, and governance will be a basis for evaluation of manager performance. Consequently, managers will also be concerned that organizations within their area of responsibility are doing the right thing and doing it well on a basis similar to the criteria of the governing body.

Governance involves (1) setting policies based on regulations, business objectives, good business practices, and monitoring compliance, (2) setting objectives, and monitoring performance, (3) ensuring accountability, and monitoring compliance with appropriate standards of conduct, and (4) identification of risks and assessment of risk mitigation or avoidance.

In this chapter, we are concerned with support of governance with rules applied in information systems. We will examine the mechanisms of governance in greater detail in Chapter 11. Much of governance involves the application of rules and measurement of compliance. This must be supported by a facility for management of the rules and traceability to their implementation as well as traceability from the effect of a rule back to the record of intent. Rules management is addressed later in this chapter.

Here we will consider the application of rules under the following topics:

• Regulations

• Policies

• Objectives

• Approval levels

• Monitoring

Policies in VDML

To the extent a policy affects collaborations, activities, and deliverable flows, VDML can provide a context for the implementation of policies. Generally, such a policy will affect the flow of deliverables—a policy decision will produce an alternative flow. VDML can express the policy condition and define an alternative deliverable flow to resolve the policy violation or constraint.

However, additional deliverable flows may be avoided as too much detail in a VDML model where a policy violation flow should never occur, but the relevance of a policy can be included as an annotation on the affected activity. In addition, a policy may be characterized as a practice and can be represented in the VDML Practice Library for cross-referencing.

In general, a VDML model will assist in the identification of relevant value stream(s) and capability(s) that may be affected by a policy. Resources or deliverables that are referenced in the rules will also suggest relevant capabilities and activities (those that consume or deliver). This includes value streams in product development where product design and production engineering decisions may affect regulatory compliance, as well as value streams of support services such as purchasing, receipt and storage of materials, maintenance of equipment, and so on. Each relevant value stream should be examined to find the earliest point where a rule should be applied to avoid rework or the consequences of noncompliance. The value stream also supports consideration of the impact of the policy on customer values. The customer value impact may be a basis for reconsideration of the policy, reconsideration of the way the policy is translated to rules, or consideration of changes to the structure of the value stream or the product.

In addition, where the consequences of violation may be more severe, it would be appropriate to apply rules prior to potential occurrence of the undesirable consequence. For example, if there are regulations that apply to a product, it may be appropriate to inspect finished products for compliance prior to shipment. This may reveal a circumstance where an early stage restriction was overlooked. This is a particular concern where there has been a significant product or business change.

There may be multiple capability methods for implementation of a policy. For example, an employee termination policy should require termination of any authority for access to information or participation in operations. Similarly, a new assignment should result in reconsideration of existing authorizations. These controls may require not only a rule, but the initiation of a process to effect the required changes to role and authorization records. This requirement could be driven by a trigger on the employment record. While this might be considered a data integrity issue, the scope of effect is broad, and there may be some discretion required regarding the propagation of changes and the timing of their effect.

Mapping business policies and rules to capability methods and business processes will also provide the opportunity to recognize where policies may overlap or conflict. Note that not all policies will be implemented with rules. Some policies will affect the way processes are structured, the way activities are performed, or the way resources are allocated, including people, machines, and materials.

Ecosystem Conditions

A policy may require attention to certain market events or trends. The criteria for identification of changes of interest may be expressed as policies or rules. The translation of these requirements for analysis will be in internal responsibility of the analytics or enterprise intelligence service unit. These should be addressed by the Sense and Respond Directory discussed in Chapter 9. If a relevant new or revised law or regulation is under consideration or has been adopted, this will be a situation to be reported in the Sense and Respond Directory. Such changes may affect not only activities and decisions but may require specific actions to achieve compliance of existing facilities, products, contracts, records, or other business items.

Consolidation of Control

It is desirable that implementation of policies and rules should have rapid effect. For example, consider an enterprise policy that “returns must be in original packaging, accompanied by the original receipt and received within 30 days of the sale.” Suppose that a competitor starts a holiday season campaign drawing attention to their policy that “returns must be in original packaging suitable for resale, goods must be current stock items, and refunds without receipts are in the form of a gift card.” It may be important to quickly implement a more accommodating policy to avoid potential lost business, particularly during the holiday season. This could take days if not weeks if there are different retail systems for different lines of business.

Consolidation of business control functions can provide a greater opportunity for rapid deployment of rules or codification of complex decisions. For example, computation of billing for specialized services might be a time-consuming manual process performed by individual, field service units, whereas consolidation of the billing function as a shared service might justify the development of a consolidated billing unit or an expert system solution. This is similar to the use of purchasing, accounting, and personnel services to control vendor selection, ensure control of financial records, and achieve consistency in personnel administration throughout the enterprise.

Regulations and Policies Directory

A Regulations and Policies Directory is needed to support an enterprise unit for administration of regulations and policies. Regulations must be interpreted to determine policies that are relevant to the particular enterprise, and policies must be expressed as rules that are precise expressions of intent and that can define relevant circumstances and be analyzed for overlaps and gaps. A policy may require multiple rules applicable in different contexts. The resulting rules must be deployed wherever they are appropriate, throughout the enterprise.

The Regulations and Policies unit must consider requirements for compliance with regulations and identify the appropriate organizations and processes where associated rules apply. From an enterprise perspective rules should be associated with capability offers. Capability offers identify not only the capability but the organization unit responsible for the capability and thus the organization unit responsible for application of the rule.

Relevant capabilities may be identified by analysis of value streams as discussed above, or by identification of other factors such as resources or deliverables affected by a policy. These are associated with capabilities where the policies may be applicable.

The directory must provide the linkage between regulations, policies, and rules. In the context of a VDM model, the implementation of policies and rules can be traced to capability offers and activities of capability methods, if appropriate. The VDM capability offers, methods, and activities are expected to align to operational models of service units, processes, and activities. Consequently, regulations can be traced to deployment in processes and activities, and the rules that implement policies (and regulations where applicable) can be linked back to the policy or rule that is the basis of the rule.

The Regulations and Policies Directory might also be the basis for analysis of the relationships between regulations and policies to consider overlaps, conflicts, and gaps. Rules reference business entities, attributes, and relationships in the rule condition expressions. The rule conditional expressions should reference these business entities, attributes, and relationships consistent with the enterprise logical data model as discussed in Chapter 6. Rules that reference the same business entities are related, so similar rules may be found by examining rules that reference some or all of the same business entities, and rule relationships can be further refined by identifying the references to attributes and relationships. There are various techniques for analysis of the relationships between conditional expressions (eg, using Venn diagrams).