Methodology for Modeling Decisions - Gnorion/BizVR GitHub Wiki

Identify the decision being made.

At the most general level every decision looks like this

It transforms a set of inputs into a set of outputs. In general a decision is side effect free. The task of implementing side effects falls on the entity that invokes the decision. A decision may be implemented using decision Tables (BizVR) or procedural code such as BizCOD) or other tools such as decision trees and deep learning.

A BizVR decision is one or more rules that may be organised into a number of rule groups for convenience.

Rule Groups are also called rulesets, decision tables or rule methods

An example of a decision:

• Determine the overall insurance risk for a property

Identify the factors that affect the decision.

For example, the business insurance underwriter may know that the insurance risk is based on three factors:

• The customer risk
• The property risk
• The coverage risk

This can be represented in BizVR as

The grey box in the middle is a single decision table. Clicking on it will reveal the details of that set of rules:

Note: This table does not yet cover all possiblilities. A later validation step will address completeness and consistency

The left column represents the data elements being tested (financial, property, coverage) or set (risk) The other columns each represent a distinct rule that covers a particular combination of data values being tested and the value of the result to be set

Further they may know:

• Customer risk is based on customer bankruptcies, years at current address and years in business.
• Property risk is based on type of construction, age, value and prior losses
• Coverage risk is based on the type of peril and the coverage required

Additional tables can then be created to determine each of the main factors:

Note: The connecting arrows that show dependencies are inserted automatically

List in English the rule statements that make the decision

Example: Customer Rules (not necessarily complete or consistent)

• Customers with more than one bankruptcy are poor risk (rule 1)
• Customers with one bankruptcy who have been in business for less than 5 years and have lived at their current address for less than 5 years are poor risk (rule 2)
• Customers with one bankruptcy but more than 5 years in business or at current address are average risk (rules 3 and 4)
• Customers with no bankruptcies and credit score over 700 are considered excellent risk (rule 5)

This can be represented in decision table form as:

Property Rules and Coverage Rules would be listed similarly.

Identify the business objects, attributes and data types of these factors.

Up to this point we have not needed to define a formal vocabulary. We just used informal labels and this works fine during the early stages of design. We can concentrate on defining a solution to the problem without getting lost in technical detail. But at some point we will need to define all the data elements that are used by the rules.

Customer has

• number of bankruptcies (which might be retrieved from a credit report),
• years in business and
• years at current address (as reported on the application form)

Property has

• type of construction (Brick, Sticks, Straw),
• year of construction (from which age is determined),
• value (based on latest Zillow reports) and
• total amount of prior claimed losses (either reported by new customers or obtained from the database for existing customers)

Coverage has

• type of peril (wolf attack, wind)
• type of coverage (medical, content)

Develop a formal vocabulary that defines the business objects, factors, attributes and types

This could be done with a UML diagram or using BizCOD Data Modeling

Define the relationships between the various business objects

Customers can have one or more property. Properties can have one or more coverage. These are typically expressed as collections, array, list, sets. In relational databases this may be done with primary and foreign keys or in a non-relational database with embedded data- for example json.

Identify the sequence of steps involved in making the decision

This may be defined in the decision diagram which is generated automatically as you add rulesets based on the dependencies between them. If an inference engine is being used then it may automatically determine the order of execution based on the goal and the various dependencies

Group the rules into rule groups.

Typically all the rules that set the value of a given attribute will be in the same rule group (ruleset or decision table) though that is not a requirement. But putting them ion one place makes in easier see all the logic in one place. The validator will still check the rules for completeness and ambiguity even if they are in different rulesets.

Enter all of the English rule statements that apply to each rule group.

Initially these can be plain English statements. And should be independent of whether they may later be modeled as rules or decision tables. Later you may find it helpful to supplement these with actual values that occur during execution. If the source of the rules is actual code then you can also copy that into the rule statements as a reference.

Enter the natural language for each condition and action in the rule statement

Initially you don’t need any special syntax here – the important thing is to capture the intent of the rule regardless of what data or attributes might later be used to implement it. Natural language expressions in multiple language can be entered.

Enter an expression that implements each of the natural language statements

There are usually many different ways to implement a particular business intent. Decisions and Rules Involving Expressions Ideally try to find an implementation that mirrors the structure of the English rule statement. Users can toggle between their preferred natural language version and the technical implementation.

Check the rules for consistency

Fix any ambiguities by making the rules more specific. Avoid the temptation to use the override or priority mechanism – it’s just too hard to see what’s happening if you do that. Checking the consistency of the rules

Check the rules for completeness

Add any required missing rules. Checking the completeness of the rules Even if you don’t care about those missing cases sometimes it’s helpful for the rules to explicitly say so just to avoid any misunderstanding. You may find that the completeness checker adds a lot of extra rules to deal with null values. You can write rules for them in the rule group if there aren’t too many and its important to identify missing values. But a better approach is to create a validation rule group at the beginning of the decision that ensures that all required data is present. If it’s not then there may be no point in trying to execute the rest of the rules. If null is a valid value the rules need to deal with it in the rule group where it arises.

Create a test case for each rule group on its own.

If you make sure that each rule group is giving the proper results on its own you will have less headaches when you start putting them together in a decision. Tutorial How to test a decision model

Create a test case for every rule in your rule group.

That’s the only way you can be sure it’s fully tested. You can usually do this by entering multiple test data entities in a single test. Sometimes you need multiple tests. For example to test the case where there is no input at all you will need a separate test.

Once rule groups are created and tested you can start assembling them into decisions.

BizVR will do this automatically based on the dependencies. If your rulesets are not connecting as you want, check to make sure that the output of one ruleset is actually tested by the other.

You could just put all the rulesets into one very big decision diagram.

But in general it’s better to group related rulesets into subdecisions. This allows those subdecisions to be used as independent decisions components of many different business decisions. An example of this might be a decision that gets a credit score from each of the major bureaus and creates a suitable aggregate. TLP Insurance Using Credit Scoring Sub Decision

You can always drill down into the subdecision to see more details.

Create test cases for the entire decision.

If you have already thoroughly tested the individual rule groups this step should be fairly easy. Decision Test cases At this point you are more concerned with the interaction of the rule sheets than their individual behavior. If the decision is particularly complex it can be helpful to develop additional rule groups whose purpose is to provide a cross check on the other rule groups. One example of this is a ruleset/decision table that cross checks totals of records processed. Another example is a ruleset/decision table that check to make sure that all rules have been tested by at least one test case.

MEP Thoughts 2021

1. My personal preference would be to make the DECISION TABLE the primary means of representing related rules
2. supplemented with the ability to make function calls and backward chain to source any unknown variables
3. in theory the inference engine should be able to take any set of rules or decision tables and figure out the interdependencies between them for forward or backward chaining.
4. We should accommodate the DMN standard - i.e. be able to import a DMN definition and be able to export a DMN definition in order to support the ability to exchange rule sets but I don't think its necessary to slavishly adhere to the standard. Particularly as I expect we will exceed its functionality anyway.
5. Currently the DMN standard has no provision to accommodate the processing of collections of hierarchical data in a decision table. Its expecting that some other procedural code will take care of that. Our decision tables should be capable of processing complex hierarchical data structures without resorting to traditional programming mechanisms (such as loops)