We call these days 'the dark days'.  Where I live, the days are short and cold at this time of the year.  It means that I wake up before the sun rises, travel to work in the dark, and when I get home from work, it's dark again.  The shortest day of the year is behind us and I look forward to the light days.  I am looking forward to the day when the sun wakes me.  It will energize me and give me a feeling of freedom and opportunities.

I believe that feeling is the origin of what is named 'the light world assumption' of SBVR.^[1]  In a light world, freedom is promoted and opportunities are encouraged.  In this world, everything is permitted except when explicitly prohibited with a rule.^[2]

In this exemplary world, everyone gets a credit card except when one of the following rules apply:

Compare this to a dark world assumption:  a world where everything is forbidden unless explicitly permitted.  In this dark world, nobody gets a credit card unless the following rule applies:

Funny, the rules give me a completely different perspective, while the result will actually be the same.  In a dark world I am given a checklist that describes the desired result (when to get a credit card), while the light world provides me with a list of constraints describing undesired situations.

There is no need to describe both situations.  A decision table approach would enforce us to do so:

… possibly resulting in huge tables, as you can imagine.  We are happy that we found decision table compression:

But then again, it's not difficult to imagine the results with more than 10 criteria!  But this is a digression.  Let's get back to my two worlds.

The choice for a light world or a dark world is a great way to handle completeness and exceptions, as I've discussed in an earlier column.^[4]

But how to choose between the light world and the dark world?

Typically a dark world approach is chosen if you are protecting something valuable.  For example:  You have a large fund available for grants targeted at a specific audience.  Someone may apply for a grant, and an authority will decide if the applicant belongs to the target audience for the fund.  Hopefully, some objective criteria for the decision are used in the form of business rules.  When this is a large fund, expecting many grant requests, such a process may be automated, including automated decision making.

By contrast, the light world is typically used in situations where exploration of possibilities is to be promoted.  The motto is:  "Just try and we will tell you when a line is crossed."  So a light world is more likely to be chosen when human actors are heavily involved using rules as guidance.  But the approach is also used in software programs, especially when databases want to collect and store as much information as possible and need rules to guarantee some consistency.

To summarize:

In a dark world assumption:

• Rules indicate when something is allowed.
• Typically used to protect something valuable.
• Strong relationship with (automated) decision making.

In a light world assumption:

• Rules indicate when something is not allowed.
• Typically used to promote initiative.
• Strong relationship with data collection and data entry.

Benefits of choosing the right color of your world:

• No need to cover all possible situations with rules because the color of your world provides default behavior.
  
  
• Consistency is promoted when all rule authors in a team write rules under the "same color assumption" as stated in Check-number 13 of the checklist for non-ambiguous rules and requirements.^[5]

A final observation is that US-based projects follow the light world assumption more often than European-based projects.^[6]

References

[1]  Semantics of Business Vocabulary and Business Rules (SBVR), v1.2, Object Management Group (Nov. 2013), p. 186.

[2]  The concept was first introduced by Ron Ross in the BRCommunity to deal with authorizations.

[3]  As usual in these columns I am omitting some obvious details in these rules that you should normally state (like the date on which age of the credit card owner is calculated, etc.) so that my examples are short and readable.

[4]  See my column "Exceptions are just 'some more rules'," Business Rules Journal, Vol. 10, No. 12 (Dec. 2009), URL:  http://www.BRCommunity.com/a2009/b512.html

[5]  Checklist for Non-ambigous Rules and Requirements:  http://www.silviespreeuwenberg.com/checklist/

[6]  Read more about the cultural differences when dealing with rules in my first column in this Rule Obseratory (November 2004): "Observations on Business Rules in Europe and the U.S.," Business Rules Journal, Vol. 5, No. 11 (November 2004), URL: http://www.BRCommunity.com/a2004/b211.html

# # #