Decision Table¶
Decision matrix — instantiates Predicate Criterion Formalization
Lays out every combination of conditions as rows mapped to a single action, with a mandatory default so no case falls through.
A Decision Table lays out the combinations of a set of conditions as rows and maps each to a prescribed action, under the discipline that every possible combination is accounted for and exactly one action applies. Where a truth table reports what a compound condition evaluates to, a decision table says what to do given the conditions — and its central guarantee is completeness: no combination of inputs is left without a defined outcome, including an explicit default for the cases the authored rules don't cover. It takes the meaning of each condition as settled and spends its rigor on coverage: are all combinations enumerated, is any combination assigned two conflicting actions, and does every gap route to a default. It is the artifact that turns a tangle of nested if/else business rules into an inspectable grid.
Example¶
A property insurer triages incoming claims into one of three actions: fast-track auto-approve, route to a human adjuster, or flag for fraud review. The relevant conditions are claim amount (under or over $5k), whether the policy was active on the loss date, the claimant's prior-claims count (0, 1, ≥2), and whether the loss type matches the policy. The team builds a decision table — each row a combination of these condition outcomes, each mapped to one action.
Building it forces two discoveries. First, a gap: no rule covered "policy inactive AND amount under $5k," which had been quietly falling through to auto-approve; the completeness check surfaces it and they assign it to adjuster review. Second, an overlap: two rules both matched "prior-claims ≥2 AND amount over $5k" with different actions, and the grid makes the contradiction impossible to miss so they resolve it. A mandatory default row — any combination not matched above → adjuster review — guarantees no claim can reach an undefined outcome. The inherited if/else logic becomes a grid a claims manager can read and audit line by line.
How it works¶
- Lay conditions as columns, combinations as rows. Each row is one full combination of condition outcomes; the row set aims to cover the whole input space.
- Map each row to exactly one action. Single-hit design keeps rows mutually exclusive, so no priority or tie-break logic is needed — completeness, not ordering, does the work.
- Check completeness and consistency. Detect missing combinations (gaps) and combinations assigned conflicting actions (overlaps); a sound table has neither.
- Provide a mandatory default. An explicit else-row catches every combination the authored rules don't, so nothing falls through undefined.
Tuning parameters¶
- Condition granularity — how finely each condition is bucketed (binary versus multi-band). Finer buckets capture nuance but multiply rows.
- Don't-care collapse — merging rows where a condition is irrelevant (marked "–"), shrinking the table at some cost to explicitness.
- Hit policy — single-hit (mutually exclusive rows) versus first-hit (ordered, first match wins). Single-hit is auditable but must be complete; first-hit is compact but reintroduces order-dependence.
- Default action — how conservative the else-row is (route-to-human versus reject). This sets the safety posture for the unforeseen.
- Externalization — kept as documentation versus compiled into a rule engine that executes it directly.
When it helps, and when it misleads¶
Its strength is that it makes composite rules visible, auditable, and demonstrably complete — the grid is where gaps and contradictions in a rule set become impossible to hide, and where a non-programmer can verify the policy.
Its failure mode is combinatorial explosion[n1] — conditions multiply rows until the table is unmaintainable, tempting authors to prune rows and reintroduce the very gaps the format exists to prevent. The classic misuse is a table that looks complete but was built on conditions whose meaning is ambiguous, so two authors bucket the same claim differently — the completeness is real but the semantics underneath were never pinned. The discipline that guards against this is to fix each condition's meaning before enumerating rows, and to keep the condition count low enough that completeness can actually be checked.
How it implements the components¶
boundary_case_library— the row set is an enumerated library of condition combinations to be covered; building it forces the obvious, borderline, and unforeseen combinations into the open as explicit rows and doubles as a coverage checklist.indeterminate_case_policy— the mandatory default row is the policy for combinations the authored rules don't decide: rather than fall through undefined, they route to a stated fallback action.
It does NOT define what the conditions MEAN or prove how they compose — the composition_contract for negation/AND/OR and the necessary-and-sufficient truth_evaluation_logic are Truth Table, which a decision table takes as settled input.
Related¶
- Instantiates: Predicate Criterion Formalization — the decision table is the coverage-and-action instance, mapping every condition combination to a defined outcome.
- Consumes: Truth Table — it relies on the composition semantics a truth table settles, then focuses on covering combinations and assigning actions.
- Compare: Decision Table or State Matrix is the safety cause-and-effect / interlock twin — the same condition→action grid applied as a hardwired guard or interlock matrix — whereas this page covers general condition→action business rules.
- Sibling mechanisms: Boolean Guard Clause · SQL WHERE Clause or Query Filter · Truth Table · Eligibility Criteria Checklist · Policy Definition of Terms · Predicate Version Registry · Test Case Matrix · Counterexample Register · Unknown-State Routing Rule
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: Decision Table operates as a standing rule, threshold, contractual commitment, or policy constraint governing future conduct because it lays out every combination of conditions as rows mapped to a single action, with a mandatory default so no case falls through.
Independent corroboration: The frozen evidence defines Decision Table as 'Lays out every combination of conditions as rows mapped to a single action, with a mandatory default so no case falls through', so its operative form is Rule, Policy & Commitment.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Software specification and testing cohered decision tables that enumerate condition combinations, assign exactly one action, expose contradictory rules, and require explicit coverage of defaults.
Related originating lineages:
- Operations Research — Decision analysis supplied tabular mapping from states or criteria combinations to prescribed actions.
Review resolution: Software specification and testing cohered decision tables that enumerate condition combinations, assign exactly one action, expose contradictory rules, and require explicit coverage of defaults.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
A decision table and an eligibility checklist can look alike — both are "lists of conditions" — but they run in opposite directions. A decision table specifies, once, what to do for every case; an eligibility checklist walks one case through evidence-gathering. The table is authored ahead of any candidate; the checklist is a procedure applied to a candidate.
[n1] Combinatorial explosion — the number of condition combinations grows as the product of each condition's possible values, so a handful of multi-valued conditions can produce hundreds of rows. It is why real decision tables lean on don't-care collapse and low condition counts: past a certain size, completeness can no longer be checked by a human, defeating the format's purpose. ↩