Decision Table

A decision table explicitly maps condition combinations to specific actions using a grid structure. Each row represents a distinct rule where condition stubs (inputs) are evaluated against condition entries (values like '> $10,000' or 'International'). When all conditions in a row are satisfied, the corresponding action stubs are triggered. This eliminates ambiguity inherent in sequential 'if-then-else' code, ensuring that for any given set of inputs, the output is always predictable and auditable. The table enforces a complete function over the input space, making it ideal for compliance-heavy domains like loan origination or insurance underwriting.

Decision tables externalize business rules from application source code, allowing domain experts and business analysts to modify policies without deploying new software builds. The table is stored as a standalone artifact—often in a spreadsheet, database, or Business Rules Management System (BRMS) like Drools. This separation adheres to the Single Responsibility Principle, where the application handles data orchestration and the rules engine handles decision logic. Changes to thresholds, eligibility criteria, or risk classifications become configuration updates, drastically reducing the change management cycle from weeks to minutes.

Decision tables implement a hit policy that defines how multiple matching rows are resolved. Common policies include:

• Unique: Only one rule can match; overlapping conditions are forbidden.
• First: The first matching rule in table order fires, ignoring subsequent matches.
• Priority: Rules have a salience value; the match with the highest priority executes.
• Collect: All matching rules fire, and outputs are aggregated (e.g., sum, min, max, list). This mechanism prevents contradictory actions and ensures the engine behaves deterministically even when rule conditions overlap, a critical feature for risk scoring engines where multiple policies may apply to a single transaction.

A well-formed decision table allows for automated completeness verification. By analyzing the Cartesian product of all condition entries, the system can identify missing rule combinations—gaps where no defined action exists. For example, if conditions are 'Account Age: New/Established' and 'Amount: High/Low', the table must have 2x2=4 rules. A gap indicates an unhandled scenario, which would cause a runtime exception or undefined behavior in imperative code. Tools can auto-generate a default 'Else' rule to catch these gaps, ensuring the decision logic is total and never fails silently in production.

The two-dimensional format makes decision tables inherently verifiable by inspection. Auditors and compliance officers can trace a specific transaction outcome by locating the single row where all conditions match, without needing to understand programming constructs like loops or variable scope. This white-box transparency is essential for model risk management (MRM) and regulatory frameworks like SR 11-7. Each rule can be annotated with a regulatory citation or business justification, creating a direct lineage from a decision output back to the governing policy, simplifying both internal audits and external regulatory examinations.

Decision tables are executed by a rules engine using pattern-matching algorithms like the Rete algorithm or PHREAK. The engine compiles the table into an optimized discrimination network that caches intermediate condition evaluations. When a fact (e.g., a transaction object) is asserted into the engine's working memory, the network efficiently determines which rules match without re-evaluating all conditions. This allows decision tables to scale to thousands of rules while maintaining sub-millisecond execution latency, making them suitable for real-time fraud scoring pipelines and authorization flows.