Vortex Decision Flows next up previous
Next: Attribute Rules and Combining Up: The Vortex Language and Previous: The Vortex Language and

3.1 Vortex Decision Flows

  The Decision Flow paradigm was developed for specifying complex reasoning that may involve partial information, heuristics, and multiple styles of combining information. A key criterion in the development of the paradigm was that users other than computer scientists (e.g., business managers, policy analysts, domain experts) should be able to understand the specifications of how decisions will be made, and in some cases be able to modify the specifications directly. Decision Flows support a form of incremental decision-making, that can easily incorporate a myriad of business and other factors, and specify the relative weights they should be given. Decision Flows support a rule-based style of specifying decision policies, and are more expressive than decision trees and traditional business rule systems. However, Decision Flows are less expressive than conventional expert systems as a result of a novel approach to structuring the rule set underlying a Decision Flow. This helps to simplify explanations of how a decision is made, and reduces the ``ripple effect'' that often arises from modifications to programs written in with expert systems or logic programming languages.

We briefly illustrate some of the basic Decision Flow constructs using Figures 2 and 4, which give a high-level picture of a representative Decision Flow that can be used for making the MIHU decision. In the MIHU prototype, a Decision Flow like this would be one node of a flowchart which is executed for each page that is served to a customer. For example, this outer flowchart might operate as follows: (a) test whether the page indicates a new session or is the continuation of an active session, (b) if a continuation then retrieve information (from a main memory database or internal data structure) about previous pages of the session (c) possibly get customer profile information, (d) execute a Decision Flow that decides whether to make an automated intervention, and (e) inform the web server about the decision made.

The two Decision Flow figures show rules and conditions using an informal, pidgin syntax. In the text-based version of Vortex, the syntax for conditions and terms is close to the C language. A GUI is provided for Vortex programmers, including wizards to help with rule construction, query construction, and the like.

Decision Flows are attribute-centric. In particular, a Decision Flow specification has source attributes or input parameters; in the example these hold information about the customer identification, customer profile and current session. The specification also includes a family of derived attributes, which may be evaluated during execution. Some of the derived attributes will be target, and embody the output of a Decision Flow; in the example this includes a boolean indicating whether to offer the MIHU functionality, and additional attributes giving characteristics of a session. The current prototype Vortex system supports data types associated with relational databases, namely scalars, tuples of scalars, lists of scalars, and lists of tuples of scalars. (We expect to incorporate XML data in the next round.)


  
Figure 2: Representative Decision Flow for making MIHU decision (using informal syntax)
\begin{figure*}
\begin{center}
\vspace*{-2mm}

~\epsfxsize=5in\epsfbox{Slide2.eps}~

\vspace*{-8mm}\end{center}\vspace*{-8mm}\end{figure*}

The Decision Flow of Figure 2 shows individual attributes using hexagons (e.g., current business score, offer MIHU), and modules using rounded-corner boxes (e.g., determine MIHU score, determine frustration score). A hexagon node may contain rules that specify how an attribute is to be computed; this will be described below in Subsection 3.2. External functions such as database queries, calls to a heavy-weight decision support system (e.g., an expert system) or side effect functions (e.g., database updates, triggering workflows) can also be included. The modules may be hierarchically organized, and may contain other modules, hexagons, and external functions.


  
Figure 3: Data from report on MIHU decisions
\begin{figure*}
\begin{center}
\begin{tabular}
{\vert c\vert c\vert c\vert c\ver...
 ...1 & 25 & 48 & 58 & -- & -- & -- \ \hline
\end{tabular}\end{center}\end{figure*}

We now use Figure 3 to explain intuitively how the MIHU Decision Flow operates. This figure shows a report presenting some representative decisions reached by the decision engine. The columns of this report correspond to some of the most important attributes of the Decision Flow, and each row corresponds to a single execution of the Decision Flow. During a single execution, the value of offer MIHU is based on three intermediate attributes: MIHU score, MIHU override score, and CSR load. In the example, if either of the scores is $\geq$ CSR load, then the MIHU functionality is offered.

The MIHU score attribute is based on other intermediate attributes, which focus on the current business value of the customer and session, on the estimated frustration level of the customer, and on the estimated opportunity for making money from the customer (either by encouraging the customer to purchase the contents of the shopping cart, or through a cross-sell or up-sell). The frustration score and opportunity scores in turn depend on additional intermediate attributes.

Referring to Figure 3, the first five rows of Figure 3 show how the different scoring attributes might vary over a user session. We assume in this example that the customer visited 5 pages, and placed something in the shopping cart when sending the 4th page back to the web storefront. In the Decision Flow used to generate this example, frustration score goes up, except when the customer places something in the shopping cart. The intuition here is that customer frustration goes down if there is a feeling of progress, e.g., after several searches a product is found and put in the shopping cart. On the other hand, the opportunity score generally goes up when something goes into the shopping cart, both because there is something in the shopping cart, and in some cases there are possibilities for cross-sells and up-sells.

Of course, the specific behavior of the attributes in a Decision Flow is determined by the business analysts and managers who program it. As a result, the Decision Flow for MIHU described here can be adapted to encompass any principles and heuristics that a business manager wants.

A key feature of Decision Flows is the use of enabling conditions or guards on the execution of attributes, modules, and external functions. For example, determine MIHU score has as enabling condition, expressed informally, that the module will be executed if the current business value is > 70, and otherwise on every third page of the web session. Likewise, determine whether to offer MIHU will be executed only if the MIHU option has not yet been offered to the customer.

Session 282 in Figure 3 illustrates how the enabling condition on determine MIHU score impacts Decision Flow executions. In this session the current business value is $\leq 70$, and so the determine MIHU score is not executed on the 2nd, 3rd or 5th pages. On the 6th page the current business value goes above 70. So determine MIHU score is computed for the 6th and 7th page.

Enabling conditions are useful in at least three contexts: (a) to permit savings on resource usage (as just illustrated); (b) to avoid the computation of irrelevant attributes (e.g., once MIHU has been offered there is no need to compute offer MIHU); and (c) to indicate which attributes should be ignored if a realtime constraint is about to be violated.

What happens if an attribute that has been disabled is referred to by the computation of some other attribute? One design principle of Decision Flows is that any attribute may have null value, and that any attribute computation must be able to work with null inputs. This is motivated in part by the observation that data retrieval over a network is not reliable, and that many decisions must be made using partial information. Suppose in the example that the MIHU option has not been offered yet. Even if the module determine MIHU score is disabled, i.e., not evaluated, the rest of the Decision Flow will be executed, and a final value for offer MIHU will be obtained. The condition language used in Decision Flows can test whether an attribute has been disabled (i.e., the enabling condition is false). Importantly, both the condition language and the attribute computation language used in Decision Flows were designed to work in the context of partial information and null values (see [12]).

As detailed in [12], a declarative semantics is associated with Decision Flows. Under this semantics Decision Flows are viewed as input-output devices, which map a given set of source attribute values (and an underlying environment, such as any databases accessed) to a given set of target attribute values. It turns out that given a set of source attribute values (and a fixed underlying environment), a well-formed Decision Flow uniquely determines the values of the target attributes. A key factor in achieving this declarative semantics is that Decision Flows must satisfy a certain acyclicity property. In particular, a graph can be formed for each module M, where the nodes are the top layer modules, attributes, and external functions of M, and which contains an edge from node A to node B if (i) [data flow] an attribute defined in A is used in the computation of B, or (ii) [enabling flow] an attribute defined in A is used in the enabling condition of B. For a Decision Flow to be well-formed, this graph must be acyclic for each module. In operational terms, the acyclicity condition implies that there will not be race conditions between different attributes being evaluated. Further, the acyclicity condition underlies our claim that Decision Flows are easier to understand than expert systems, and suffer less from the ripple effect.

There are three advantages to the declarative semantics just outlined. First, the semantics provides a clear and unambiguous meaning for Vortex Decision Flows. Second, people developing Vortex Decision Flows can largely ignore flow of control issues, and focus instead on the business logic they are trying to express. This provides a key difference between Decision Flows and conventional flowcharts. (The Vortex compiler will alert the user if the acyclicity condition is violated.) And third, the declarative semantics affords some possibilities for optimizations, of both response time and system throughput (see [11]).


next up previous
Next: Attribute Rules and Combining Up: The Vortex Language and Previous: The Vortex Language and
Rick Hull
2/19/2001