Decision Tables
A decision table is a compact, tabular representation of a set of rules that govern a single, repeatable decision. Each rule occupies a row, each condition a column and the final column carries the action or outcome selected once every condition of the rule is satisfied. Its value rests on a property that prose does not give: the completeness and consistency of the rules become verifiable by construction. For n binary conditions there are 2ⁿ combinations, and the grid makes them all visible at once, so a tester derives their cases from it, an auditor confirms that no situation is left unanswered and a rules engine executes it as it stands. The BABOK describes it among the decision-modelling techniques, alongside the decision tree and the decision requirements diagram; the OMG standardises its notation, including the hit policies that remove the ambiguity when several rules can apply.
Purpose
The decision table captures a single, atomic, repeatable decision as an exhaustive set of condition-action rules. Atomic means that one outcome is selected on each pass, chosen from a set fixed in advance; repeatable, that the same decision arises many times over different data. Where a policy written in prose scatters its rules across paragraphs and leaves the reader to check that they cover every case, the table aligns them in a grid where completeness and consistency can be read off.
Its distinctive value rests on two properties that become verifiable by construction. Completeness: for n binary conditions the grid holds 2ⁿ combinations, and one sees at once whether one is missing. Consistency: two rules cannot prescribe contradictory outcomes for the same inputs without the conflict leaping out. This is what makes the table the deliverable handed to whoever automates or audits the decision: a rules engine executes it as it stands, a tester derives their cases from it, an auditor confirms that no situation is left unanswered. On prose rules these three checks are done by hand and missed; on the table they are done by reading.
The deliverable is the filled table itself: the conditions and their possible values, the action attached to each combination, one rule per row, the declared hit policy and the guarantee that every combination of valid inputs falls under the number of rules the policy allows. A table with no declared hit policy is ambiguous the moment two rules can apply to the same input. A table whose completeness has not been checked silently lets through the cases it does not foresee.
Usage
When to use it
- Atomic decision with a single outcome: one outcome from a fixed set, driven by a manageable set of conditions that combine.
- Completeness or consistency to be proven: the 2ⁿ grid shows that no case is forgotten or handled twice, which prose rules do not.
- Rules to hand to automation: a rules engine or a DMN platform executes the table without rewriting.
- Flat conditions that combine freely: most conditions count in most cases, and the table stays compact where a tree would repeat its sub-branches.
- A regulated, pricing or routing decision to audit or test: the exhaustive grid is both the test basis and the audit trail.
When not to use it
- Many, strongly hierarchical conditions: when a condition counts only on certain paths, the 2ⁿ grid explodes and reads badly, prefer a decision tree.
- A non-atomic decision that breaks into sub-decisions: fed by other decisions and knowledge sources, map it first with a decision requirements diagram and let each leaf be its own table.
- Behavioural rules or contextual judgement: a fixed set of conditions forces false precision, document the rule in natural language, where useful through business rules analysis.
Description
Anatomy: conditions, entries, actions, rules
Four elements make up a decision table. The conditions are the inputs of the decision, each tied to a specific data element: the applicant's residence, the existence of a contract, the level of an income. The condition entries are the values each condition can take: two boolean values, yes and no, in a limited-entry table; values, ranges or expressions in an extended-entry table. The actions, or outcomes, are what the decision produces, one per rule under a Unique policy. The rules, finally, are the heart of the table: each is a complete combination of condition entries to which an action is attached, and each occupies a row. The orientation where each rule is a row and each condition a column is the one the OMG takes by default; the classic orientation, each rule a column, carries the same information, and the choice between the two is a matter of readability.
Limited-entry and extended-entry
The distinction between the two forms settles how hard the check is. A limited-entry table carries only booleans and don't-cares, and its completeness is exact arithmetic, 2ⁿ. An extended-entry table carries values and ranges, more compact, but its completeness depends on how the ranges join up, and that is where the gaps lodge. Reducing a decision to binary conditions, even at the cost of multiplying their number, is often what makes completeness checkable at a glance rather than through an examination of boundaries.
Building the table
- Fix the decision and its set of outcomes
Write the decision as an unambiguous statement and list the possible actions. - List the conditions and, for each, its possible values
Only those that tip the outcome. - Choose the hit policy and write it on the table
Unique by default, as long as no intended overlap requires otherwise. - Enumerate the combinations
2ⁿ for n binary conditions, more as soon as a condition takes more than two values. - Assign an outcome to each combination
This is where the intent of the rule is read, and it is the only step that calls for judgement. - Check completeness and consistency
The 2ⁿ combinations are covered, no contradiction, no overlap under Unique. - Collapse the redundancies through don't-cares
Without masking any real distinction.
Completeness: the 2ⁿ combinations
Completeness is the most teachable property of the technique and the most mechanical to check. Each binary condition doubles the number of combinations: one condition gives two, two give four and n binary conditions give 2ⁿ. A limited-entry table is complete when its rules, unfolded, cover these 2ⁿ combinations without forgetting or double-counting any. The check is an addition, and an addition is not delegated to judgement.
The trap shifts to extended-entry tables, where the cells carry ranges rather than booleans. Boundaries that slip or overlap from one range to the next leave silent gaps. A rule that handles "amount greater than a threshold" and another "amount less than or equal to that same threshold" join cleanly; but a threshold written "greater than 18" on one amount band and "greater than 21" on the neighbouring band leaves a whole range with no rule, and the decision fails without anyone having intended it. It is a boundary error, "greater than" set for "greater than or equal to", or a threshold that moves from band to band, and it is the most common way a table that looks complete is not.
Consistency and the collapse on don't-cares
Consistency requires that two rules never prescribe contradictory outcomes for the same inputs. Under a Unique policy, any overlap is a construction error, since the policy promises that at most one rule applies.
An exhaustive table of 2ⁿ rules is most often redundant, because the outcome does not always depend on every condition. Where the outcome is identical whatever the value of a condition, that cell is replaced by a don't-care, marked with a dash, and the rows that this value distinguished are merged. An exhaustive table of eight rows commonly collapses to three or four. The collapse loses no coverage as long as the dash is honest. The trap lies there: a dash placed too quickly masks a real distinction and makes the table say something false for half the cases it covers. A dash is placed only where the outcome stays the same for every value of the condition, and the check consists in mentally unfolding the dash and verifying that the outcome holds for each of those values.
The hit policies
When several rules can apply to the same input, one must say which prevails, and that is the role of the hit policy, which the OMG places in the top-left corner of the table as a letter. The Unique (U) policy is the first to teach: at most one rule applies to any input, and any overlap is an error. It is what makes the table verifiable, because it forbids ambiguity.
The other policies serve tables where overlap is intended. Any (A): several rules apply, but they all give the same outcome. Priority (P): several apply with different outcomes, and the outcome highest in a declared priority order prevails. First (F): the first rule that applies in row order prevails, the reading order then carrying meaning. Collect (C): the table returns every outcome that applies, possibly aggregated by a sum, a minimum, a maximum or a count. A table that declares no policy is ambiguous as soon as two rules can apply, and the reader cannot tell whether the omission is an error or a choice.
Table, tree and requirements diagram
Three techniques of decision modelling resemble one another to the point of being confused, and the boundary settles the right choice. One takes a table when the decision is atomic and one wants completeness and consistency verifiable at a glance: the 2ⁿ grid is exhaustive and is checked by an addition. One takes a decision tree when the conditions are hierarchical and prune, when a condition does not count on every path, as in a segmentation: a flat table would there repeat whole sub-branches. One takes a decision requirements diagram when the decision is not atomic: it breaks into a network of sub-decisions, input data and knowledge sources, and each leaf sub-decision is itself a table or a tree. Table and tree are two notations of one and the same atomic decision; the requirements diagram is the level above, which organises several of them.
What makes the table fail
A boundary error
"Greater than" written for "greater than or equal to", or a threshold that slips from one band to the next, leaves an input in no rule or in two.
A don't-care placed too quickly
A dash that masks a real distinction makes the table say something false for half the cases it covers.
An undeclared hit policy
The table stays silent on what happens when two rules apply, and each reader assumes their own.
Conditions that are not independent
Two conditions bound by a constraint, one implying the other, create impossible combinations that one thinks must be filled although they do not exist.
A behavioural rule slipped into a definitional table
Forcing a judgement rule into a grid gives it a false precision it does not have.
A table out of sync with the policy it encodes
A rule changes in the regulation and not in the table, and the table lies silently until the next audit.
AI considerations
The first useful use is drafting a first pass of rules from a policy or regulation text. A language model given a directive in prose draws from it a list of candidate conditions and rule rows, which is the tedious half of the preparation. The second use is a check before the table even exists: give the model a set of rules written in natural language and ask it to flag the uncovered combinations and the apparent contradictions. The third extends the collapse: spot the rules where a condition does not change the outcome, hence the candidate don't-cares and the redundant rows.
What AI cannot do lies in the nature of the exercise. The completeness of the grid is mechanical, 2ⁿ is arithmetic; the correctness of the rules against reality is human. A model does not know whether a rule is faithful to the intent of the policy or the legal text it encodes. Nor does it know how to choose a boundary: writing "greater than" or "greater than or equal to" for an income threshold is a domain decision, often set down in a regulation. And it does not know what consequence to attach to each outcome, which is the substance of the decision. AI draws the table; the analyst answers for its correctness.
Data protection closes the subject the moment the table bears on people. An eligibility table filled with real cases contains personal data within the meaning of the revised Federal Act on Data Protection (nFADP), incomes, situations, statuses. It is not pasted into a public model, and the assistance is carried out on a tool whose data processing is controlled or on a table whose sensitive values have been replaced by condition symbols.
Examples
A decision on eligibility for a cantonal vocational-training grant is taken on three binary conditions: the applicant is resident in the canton, an apprenticeship contract is signed, the household income is below the ceiling, set at CHF 60'000. The grant is accorded only if all three are met. Two properties make the technique. Completeness: three binary conditions give 2³ = 8 combinations, all covered. The collapse on don't-cares: the exhaustive table of eight rows reads in four, because as soon as one condition suffices to refuse the grant, the following ones no longer matter. Rule 1 refuses any non-resident applicant, whatever the contract and the income, which its two dashes state, and this single row covers 1 × 2 × 2 = 4 of the eight combinations. Rule 2 covers 2, rules 3 and 4 one each, so 4 + 2 + 1 + 1 = 8: the collapse has lost nothing. The hit policy is Unique, marked U in the top-left corner, and one verifies that it holds, the four rules excluding one another pairwise, so that every input falls under exactly one rule. The order of the rows has no bearing on the outcome, because the rules do not overlap; this would be false under a First policy, where the table would return the first satisfied row and where the order would carry meaning.
Decision table
Cantonal vocational-training grant
| U | Resident in the canton | Signed apprenticeship contract | Household income below CHF 60'000 | Decision |
|---|---|---|---|---|
| 1 | no | - | - | Refused |
| 2 | yes | no | - | Refused |
| 3 | yes | yes | no | Refused |
| 4 | yes | yes | yes | Granted |
Visualisations
The output of the technique is a table. The condition columns set apart from the outcome column show the condition-action structure at once. The dashes aligned in a column make the collapse visible: one sees which conditions cease to count and where. The policy marker in the top-left corner says how to read a possible overlap, information without which the table would be ambiguous.
The collapsed form is the one shown because it is the one read. The exhaustive form of 2ⁿ rows exists only for the length of the check: it proves that nothing is forgotten, and the collapsed form then serves to decide quickly.
Cost
| Phase | Level | Rationale |
|---|---|---|
| Preparation | Medium | Agreeing on the conditions, on the values each takes and on the rule owner's intent is the substance of the work. The ambiguity lodges here, in a term of a regulation that admits two readings or a boundary that no one has settled. |
| Execution | Low | Once the conditions and the actions are fixed, enumerating the combinations and checking completeness is mechanical: 2ⁿ is arithmetic, and the collapse on don't-cares is done by hand or in a spreadsheet. No long workshop, no data to gather. |
| Documentation | Medium | The table is a living artifact. It is versioned and re-checked at every change of the rule it encodes, failing which it drifts out of sync with the policy and lies silently until an audit or an edge case catches it. |
Tools
The spreadsheet (Excel, Google Sheets) is the everyday tool. One row per combination gives completeness by construction, one column per condition holds the structure, and a formula checks the boundaries or counts the rows. It is where the table is thought out; the meaning of the rules stays with the analyst.
The DMN modelling tools (Camunda Modeler, Trisotech, SAP Signavio, Sparx EA, Drools and its KIE suite) are the level above. They know the hit policies, flag the uncovered combinations as well as the overlaps and produce an executable table rather than a mere document. This is where a table meant for automation is validated and executed.
The rules engines and business-rules management systems (BRMS) execute the table at runtime, on production data, once it has been validated. The table then ceases to be an analysis deliverable and becomes a component of the system.
The whiteboard remains the tool of the initial elicitation, as long as the conditions and their values are still under discussion. The practical rule fits in one sentence: the spreadsheet to think, the DMN tool to validate and execute.
Sources
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.17 Decision Modelling: the definition of the decision table, its anatomy in conditions and actions, the use of blank or don't-care cells and the strengths and limits of decision modelling.
- Object Management Group, Decision Model and Notation (DMN), Clause 8 (Decision Table): the standardised notation, the default orientation where each rule is a row, the policy marker in the top-left corner and the hit policies Unique, Any, Priority, First and Collect.
- ISTQB, Certified Tester Foundation Level Syllabus, Decision Table Testing: completeness, consistency and the elimination of redundancies as a test-design discipline, including the derivation of test cases from the combinations of conditions.