Special Evaluation Specifications for Decision Rules: How to Support Very Smart, Very Friendly Business Decision Systems

Ronald G.  Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal and Co-Chair, Building Business Capability (BBC) Read Author Bio       || Read All Articles by Ronald G. Ross

A breach occurs for a business rule when the business rule isn't satisfied upon being applied to some set of circumstances (state of affairs).  Normally we think about breaches occurring for behavioral rules, where a breach means a violation has occurred (e.g., you violated the posted speed limit).

The potential for violations of behavioral rules raises several important questions that business analysts should answer in advance of deployment for each behavioral rule:[1]

  1. What level of enforcement should be applied?

  2. What special response to a violation is appropriate, if any?

  3. What special message, if any, should be returned to some worker(s) upon a violation?

Unlike behavioral rules, no definitional rule[2] can ever be violated.  Literally, things must be correct under such rules by definition.

Let's take an example.  Suppose somebody asserts "2+2=5".  According to the rules of mathematics, we know the correct answer is 4.  The answer "5" is deemed irrevocably wrong.  But is the asserted answer ever allowed to stand?

  • If the rule is defined as a decision rule, the asserted answer is never allowed to stand.  More precisely, the assertion would never be recognized to have happened in the first place.  If someone asserts "2+2" the answer "4" is concluded immediately.  Period.  No breach, no opportunity for error.

  • If defined as a behavioral rule (one that is not strictly enforced), the asserted answer is allowed to stand, but a violation is recognized.  How might that capability be useful?  Suppose the error were made by a student in grade school.  It might be quite useful for the student and/or a tutor to know about it immediately and automatically.  Specifying an appropriate violation response can make such notification happen.

In business, of course, definitional rules can be far more complex.  Nonetheless, your ability to respond in appropriate ways to the specific, selective circumstances where certain rule-related events occur — automatically and independently of processes — provides exactly the mechanism you need to support very smart, very friendly operational business decision systems.

Decision Rules and Breaches

Decision rules[3] are a special kind of definitional rule involving implications (e.g., A implies B).  They support inferences and determinations — identifying an appropriate outcome from among a set of alternatives.

Like all decision rules, definitional rules cannot be violated.  They are simply deemed true by definition.

Purely from a business perspective, however, some assertions of fact(s) may make it appear that a breach-like event has occurred.  I take pains to emphasize any such perception is purely from the business perspective, not from the perspective of logic.  You perceive a breach of a decision rule simply because it's useful to do so, not because any true violation has occurred.

In evaluating some particular case (situation, set of circumstances, or matter of concern), for example, things might not follow the 'happy path'.  Think of a breach of a decision rule as a bump in the road — a gap along the happy path.

Let's return to the three questions listed earlier.  Although the first question about enforcement level obviously doesn't apply to decision rules, adjusted versions of questions 2 and 3 remain in play.

Consider the following simple business example.  Suppose a bank has this decision rule:

A credit application must be considered discrepancy-free with respect to a credit report for the applicant if all the following are the same:

  • name
  • date of birth
  • Social Security Number
  • current address
  • previous address

Let's suppose that an applicant uses just the initial for her middle name on her credit application.  If the credit report shows her full middle name, then the names are not the same and the credit application will not be considered discrepancy-free.

Note carefully the rule hasn't been violated; it did its 'work' correctly and it did reach the proper conclusion (not discrepancy-free).  But a gap — a breach — for her case has been identified from a business perspective because the rule failed on one of the conditions.  We should be able to take advantage of that breach to take appropriate action — selectively, automatically, and in real time.

For example, the desired response to the breach might be to insert the following to-do item in the work queue of the responsible staff member:  "Review discrepancy and manually ok if appropriate."  (The to-do item should naturally also provide ready access to the related documents.)  The breach of the rule causes this action to occur automatically.

Think about how many decision rules might exist for determining credit-worthiness, and how many selective conditions they might have.  Could you build a responsive system by incorporating the selective responses needed into the related process model(s)?  Not a chance — that approach won't scale.  Instead, the selective responses need to be specified based on the business-rule side of things.

Kinds of Breach Specifications for Decision Rules

Breach specifications for a decision rule can be of the following two kinds.[4]

Breach Response.  A breach response can be an action of virtually any kind.  For example, a breach action might be to:

  • add some task(s) to a (non-redundant) to-do list in some appropriate work queue.

  • add some documentation items to a (non-redundant) not-yet-received list.

By these means, very selective follow-up processing/handling ("what to do next") can be organized pertaining to any specific issue (breach) for a given case.  Such selectivity is made possible by the granularity of the rules.

Breach Message.  A specially-worded breach message can be forwarded to any involved party, either inside or outside the company.  A breach message generally explains one or both of the following at any level of detail desired:

  • Why the rule or condition failed.  (The rule or condition statement already indicates very precisely what the issue is, but the breach message can explain in a more friendly manner.)

  • What should be done to address the issue.

More Complex Example

Breach specifications apply selectively and specifically to a decision rule and/or any of its conditions.  A breach specification applies if and only if that decision rule and/or condition fails (is not true) in evaluating some specific case (e.g., a specific credit application).  An example of a decision rule with condition-specific breach specifications is illustrated in Table 1.

Table 1.  Example of More Complex Decision Rule with Condition-Specific Breach Specifications.
Decision Rule
Breach Response
Breach Message
A fluctuating income must be considered eligible if all the following are true:



Conditions of the
Decision Rule



  • the applicant has a 3-year proven track record of consistent income



  • the applicant is likely to have comparable income in the future
Add to-do item for that credit application:  "Contact employer to verify applicant has reasonable opportunity for future income.


  • the income is validated
Add required documentation items not yet received to a pending list for the credit application. To applicant:  "[date] Here's a list of documentation items related to your income we have not yet received.  [pending list]."

Using Breach Specifications

Breach specifications can be:

  • general for an entire decision rule, including all its conditions.  (The example in Table 1 doesn't include any whole-rule specifications.  If the rule did, they would appear in the first row.)

  • specific to a given condition.

  • specific to collections of conditions (none shown for the example).

A breach is detected only if the conclusion of the rule as a whole, or some particular condition within it, evaluates to not true.  Things being true should be viewed as moving the case along the desired path (i.e., no breach has occurred).[5]  Decision rules (and breach specifications) should be expressed carefully so as to preserve this positive orientation.

Generally, breach actions should be specified only if something can be done to overcome a failure (of a rule or condition).  The goal is to move things forward in the case.[6]  In the example above, for instance, if nothing whatsoever can be done to correct an issue, the credit application should simply be declined.  A behavioral rule to that effect should be specified.

In hierarchies of decisions (e.g., as in Q-Charts[7]) and decision rules (e.g., as based on series of logical dependencies), breach specifications should generally be made only at the lowest level of rule reduction/decomposition.  A rule at a higher level in a logical hierarchy only evaluates to not true if some rule(s) below it evaluate to not true.  Define breach specifications at the lowest level of granularity.

For further information, please visit BRSolutions.com      


[1]  Ronald G. Ross, "Breaking the Rules:  Breach Questions," Business Rules Journal, Vol. 14, No. 2 (Feb. 2013), URL:  http://www.BRCommunity.com/a2013/b688.html  return to article

[2]  Ronald G. Ross, "What Is a Business Rule?" Business Rules Journal, Vol. 11, No. 3 (Mar. 2010), URL:  http://www.BRCommunity.com/a2010/b525.html  return to article

[3]  Ronald G. Ross, "Decision Rules vs. Behavioral Rules," Business Rules Journal, Vol. 14, No. 7 (July 2013), URL:  http://www.BRCommunity.com/a2013/b709.html  return to article

[4]  Although rules can be specified in violation specifications for behavioral rules (e.g., to express some sanction or penalty), they should never be specified within breach specifications for a decision rule.  Such 'nesting' of rules, especially on the basis of 'not true', is inappropriate.  return to article

[5]  Otherwise the advantages of overall declarative specification can be forfeited.  return to article

[6]  By default, breach specifications for a decision rule apply only the first time it is evaluated for each case.  The assumption is that all business rules, including decision rules, are evaluated on a continuous basis.  Re-application of any breach specification for a case therefore requires additional timing and iteration criteria.  Whether a case is evaluated iteratively on the same set of decision rules based on timing criteria applied by or for some external process or platform is outside the scope of this discussion.  No matter what the scheme of evaluation, the expression of the decision rules — as for all business rules — should be completely unaware of it.  return to article

[7]  Ronald G. Ross, "Modeling Decision Structures — Part 2:  Question Charts (Q Charts™) and Hybrid Diagrams," Business Rules Journal, Vol. 14, No. 10 (Oct. 2013), URL:  http://www.BRCommunity.com/a2013/b722.html  return to article

# # #

Standard citation for this article:

citations icon
Ronald G. Ross, "Special Evaluation Specifications for Decision Rules: How to Support Very Smart, Very Friendly Business Decision Systems" Business Rules Journal, Vol. 15, No. 12, (Dec. 2014)
URL: http://www.brcommunity.com/a2014/b787.html

About our Contributor:

Ronald  G. Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal and Co-Chair, Building Business Capability (BBC)

Ronald G. Ross is Principal and Co-Founder of Business Rule Solutions, LLC, where he actively develops and applies the BRS Methodology including RuleSpeak®, DecisionSpeak and TableSpeak.

Ron is recognized internationally as the "father of business rules." He is the author of ten professional books including the groundbreaking first book on business rules The Business Rule Book in 1994. His newest are:

Ron serves as Executive Editor of BRCommunity.com and its flagship publication, Business Rules Journal. He is a sought-after speaker at conferences world-wide. More than 50,000 people have heard him speak; many more have attended his seminars and read his books.

Ron has served as Chair of the annual International Business Rules & Decisions Forum conference since 1997, now part of the Building Business Capability (BBC) conference where he serves as Co-Chair. He was a charter member of the Business Rules Group (BRG) in the 1980s, and an editor of its Business Motivation Model (BMM) standard and the Business Rules Manifesto. He is active in OMG standards development, with core involvement in SBVR.

Ron holds a BA from Rice University and an MS in information science from Illinois Institute of Technology. Find Ron's blog on http://www.brsolutions.com/category/blog/. For more information about Ron visit www.RonRoss.info. Tweets: @Ronald_G_Ross

Read All Articles by Ronald G. Ross
Subscribe to the eBRJ Newsletter
In The Spotlight
 Silvie  Spreeuwenberg
 Ronald G. Ross

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.