Designing Decision Tables Part 3: Representing Meaning (Semantics)

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
Extracted from Decision Tables: A Primer: How to Use TableSpeak™, by Ronald G. Ross, 2013, available (free) on

See [glossary definitions] for terms colored like this:  decision table

No decision table is complete until its meaning (semantics) has been fully exposed.  Otherwise, opportunities for misinterpretation abound.

The meaning of a decision table involves two core aspects:

Aspect of Meaning 1.  The individual meanings of terms and wordings — i.e., the business vocabulary — used for the decision table.

A decision table should always be based on a structured business vocabulary (concept model).

Aspect of Meaning 2.  The collective purpose and relevance (semantics) of the decision table.

Three TableSpeak approaches for explicitly communicating the collective semantics of a decision table are discussed below, along with advantages and possible disadvantages of each.  The discussion focuses on two items of special importance, name and scope.

Other important items include defaults, exceptions, and restrictions.

Without adequate clarification of both aspects of meaning, a decision table cannot serve its purpose very well, whether for actually running the business or as a requirement for IT development.  Remember, as is true for all business rules, you can never be sure who will eventually view a decision table, or for what purpose they might try to use it.

About TableSpeak™

TableSpeak is a BRS set of conventions for business-friendly representation of decision tables and their meaning (semantics) in declarative fashion.

Central to TableSpeak are:

  • Highly pragmatic guidelines and thresholds for selecting the best decision-table format.  TableSpeak avoids simplistic and counterproductive one-size-fits-all approaches.

  • The principle of single-sourcing, essential for achieving true business agility.

  • Restrictionsbusiness rules for ensuring the integrity (correctness) of decision-table content.

TableSpeak optimizes for readability by non-IT professionals and business people.

  • The question the decision table answers is always emphasized.

  • Scope (applicability) is declared explicitly.

  • Unnecessary complications to decision-table structure (such as exceptions) are externalized.

  • Meaning is comprehensively expressed.

  • Business vocabulary is carefully used.
Decision tables based on TableSpeak are free of hidden assumptions and implicit interpretation semantics.

The Name of a Decision Table

Common industry practice is to name a decision table roughly after what it concerns.  The decision table in Figure 1, for example, concerns the choice of coats, so it might be called Coat Table.

Figure 1. Example of a Simple Decision Table

TableSpeak, however, recognizes the central importance to the business of the question that a decision table answers.  That question is fundamental to what the decision table represents (i.e., its meaning).

We strongly recommend using the question as the table's name.

Instead of Coat Table, for example, we would recommend What coat should be worn?

The Scope of a Decision Table

Addressing scope is essential for analyzing operational business decisions and representing the decision logic that supports them.  Delineating scope for operational business decisions is often not a trivial matter.  With respect to decision tables, misuse is almost guaranteed without adequate specification and communication of scope.

For example, suppose the decision table in Figure 1 was created to represent decision logic applicable to just females, and just to San Francisco.  Use of the decision logic for males or any other city would therefore be unwarranted and very likely incorrect.  Such use would represent inductive reasoning, something generally inappropriate for business rules.

Unless the scope of a decision table is universal within a business (not impossible but seldom the case), some explicit scope item(s) should be expressed for the decision table.  The scope items for the decision table in Figure 1, for example, could be expressed as follows.  (An implicit 'and' is always assumed between scope items.)

  • gender:  female

  • city:  San Francisco

Scope items also serve as a TableSpeak technique to achieve the crucial objective of keeping decision tables as simple as possible.  For example, treating gender and city as considerations for the decision table in Figure 1 is pointless (at least at the present time).  Doing so would simply add complexity — and that complexity would compound as the size of the decision table grows.

A final observation:  Scope items do not preclude modifying a decision table to broaden its coverage.  When the scope is broadened, the relevant scope items should simply be dropped or revised as appropriate.

Now let's examine the three approaches for explicitly communicating the collective semantics of a decision table.

Approach to Semantics 1:  Wrapper Rule Statement

A concern in rule management is often that decision tables participate fully in a larger body of guidance (business rules) that also includes a significant number of textual business rule statements.  In this circumstance writing a wrapper rule statement for the decision table often proves the best approach.  That way each decision table has a specific textual 'handle' in and among all the other rule statements.

The wrapper rule statement for a decision table indicates what the decision table represents and how it should be interpreted — i.e., how to 'read' the decision table.  For example, an appropriate wrapper rule statement for the decision table in Figure 1 might be expressed as follows.  (Note that the two scope items have been carefully included as qualifications.)

Wrapper Rule Statement:  The coat for a female person to wear in San Francisco must be as in the decision table 'What coat should be worn?'

Suppose these scope items can be suitably documented elsewhere and still remain highly visible whenever the decision table is used (a bit doubtful).  A shorter 'stub' version might be:

Revised Version:  The coat to wear must be as in the decision table 'What coat should be worn?'

Approach to Semantics 2:  Embedded Semantics

A second approach aims at making the decision table itself as self-explanatory and as self-contained as possible.  This approach involves embedding its collective semantics directly into it.  No wrapper rule statement is necessary.  Figure 2 illustrates.

Figure 2.  Decision Table with Embedded Semantics

In this approach, both of the following have been directly embedded within the decision table:

  • the question the decision table addresses (which also serves as the name of the decision table)

  • the two scope items

This approach serves quite well for this simple example.  As additional semantics are added, however, such representation can become increasingly cluttered.

Approach to Semantics 3:  Decision Box

A third approach aims toward providing a focal point for managing all the interrelated semantics of a more complex decision table.  This approach involves creating a paired decision box for each decision table, which always appears whenever the decision table itself appears.  Again, no wrapper rule statement is necessary.  Figure 3 illustrates.

Figure 3.  Decision Table with Paired Decision Box

This decision table features a paired decision box providing the table's collective semantics:

  • the question the decision table addresses (which also serves as the name of the decision table)

  • the two scope items

The usefulness of a decision box becomes more and more apparent as the number and complexity of specifications related to the decision table increase.  As mentioned earlier, such specifications can include defaults, exceptions, and restrictions.

Besides high visibility for these aggregate semantics, the decision box also provides a focal point for managing all such specifications as a unit (i.e., single-sourced).  These specifications can prove quite difficult to coordinate on an individual basis apart from the decision table.

To highlight the importance of the aggregate semantics, sometimes the best approach is to put the decision table inside its decision box.  Figure 4 illustrates.

Figure 4.  Decision Box with Embedded Decision Table

# # #

Standard citation for this article:

citations icon
Ronald G. Ross , "Designing Decision Tables Part 3: Representing Meaning (Semantics)" Business Rules Journal Vol. 15, No. 6, (Jun. 2014)

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 IPSpeak 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 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 For more information about Ron visit Tweets: @Ronald_G_Ross

Read All Articles by Ronald G. Ross
Subscribe to the eBRJ Newsletter
The Business Agility Manifesto — The Authors Speak Out Q&A with Roger T. Burlton, Ronald G. Ross, & John A. Zachman
Whirlwind Tour of the Business Agility Manifesto
Agree/Disagree? IT Departments Should be Evacuated
Agree/Disagree? Deep Subject Matter Expertise Irrelevant
Agree/Disagree? Empowerment Key to Business Agility
In The Spotlight

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.