Decision-table overlap checks for policy changes
The policy change
Before you change a condition in your policy, identify the job those words have in the decision. “Age 25 to 34: 20 points” contributes to a total in a scorecard; “Age 25 to 34: refer” selects what happens to the applicant in a table, rule set or tree. In a scorecard, the 20 points are multiplied by the predictor’s weight and added into a total; in a table, the refer row writes an outcome when it matches.
The four rows of the referral table below can be released as a decision table or as nested conditions in a rule set, and both run. The form decides what you can check, not only the answer.
The useful comparison depends on the form you are editing. A decision table can compare every pair of rows and report the pairs that some input could satisfy both of; it also lists pairs it could not compare instead of treating them as clean. It does not report gaps in coverage. A decision tree shows gaps in numeric ranges, and a scorecard warns when a predictor’s bins overlap. A rule set has no authoring-time comparison of overlapping branches. Its impact analysis comes after decisions have been recorded: it can show which rules fired, which rule decided, and which only repeated another rule, including a rule contained in or mostly overwritten by another. It says nothing about inputs that have not yet arrived.
The table test
| Row | Credit score | Debt-to-income | Outcome |
|---|---|---|---|
| 1 | 700 or more | under 35% | approve |
| 2 | 620 to 699 | under 35% | refer |
| 3 | under 620 | under 100% | decline |
| 4 | 650 to 720 | 20% to 30% | approve |
This is a demo case: a referral table for a small consumer loan built for this article. The first three rows set three broad credit bands: scores of 700 or more with debt-to-income under 35% approve; scores from 620 to 699 with debt-to-income under 35% refer; and scores under 620 with debt-to-income under 100% decline. The later exception approves applicants with scores from 650 to 720 and debt-to-income between 20% and 30%. That row does not sit apart from the bands above it.
It overlaps the 700-or-more row and the 620-to-699 row, so the overlap check reports two pairs: row 1 with row 4, and row 2 with row 4. The check leaves zero pairs unchecked.
The conflict changes the answer for one applicant. Consider a score of 680 and debt-to-income of 25%. That applicant matches the 620-to-699 row and the later exception, so the table setting decides which outcome stands. When every matching row writes in order, the last match is row 4 and the outcome is approve. When the table stops at the first matching row, row 2 applies first and the outcome is refer. The applicant has not changed, and neither have the rows. Only the rule for handling multiple matches has changed the decision.
An applicant with a credit score of 620 or more and debt-to-income of 35% or more matches no row, so the table writes no outcome. The overlap check does not report this gap. A reviewer finds it by reading down the debt-to-income column, which the grid makes possible.
The boundary
You can write the same four outcomes as nested conditions, release that policy, and execute it successfully. The distinction appears before a decision is recorded. A rule set does not compare its branches for overlap or coverage at authoring time, and its release checks do not measure how deeply the conditions are nested or how large the rule set has become; a deeply nested rule set remains valid if it passes those checks.
For logic that remains in a rule set, impact analysis can identify rules that merely repeat another rule once recorded decisions are available. Each shape has a job; the useful question is which check gives you something to inspect before you release the change.
The next change
That leaves the policy’s job as the practical test for its form. Rows 1, 2 and 4 are three combinations of credit score and debt-to-income that select an outcome, and the overlap check compared them. Contributions to a total belong in a scorecard, where overlapping bins are flagged. Independent pass-or-fail tests stay in a rule set; arithmetic goes into a function, with a rule set beside it for the branch.
For your next threshold change or exception, first decide which job the condition has, as the opening of the article does. Ask whether the condition selects an outcome or contributes to a total. In this demo, run the overlap check before the change goes live: it would have named rows 2 and 4 before the 680 applicant was approved under one setting and referred under the other.
Frequently asked questions
When should I use a decision table instead of a scorecard or rule set?
Use a decision table when combinations of inputs select an outcome, a scorecard when predictors contribute to a total, and a rule set for independent pass-or-fail tests. Put arithmetic in a function, with a rule set beside it for the branch.
What does a decision-table overlap check find?
A decision-table overlap check reports pairs of rows that some input could satisfy at the same time. It also lists pairs it could not compare instead of treating them as clear, and it does not find gaps in coverage.
What happens when an applicant matches more than one decision-table row?
When an applicant matches multiple decision-table rows, the table setting determines which outcome stands. If every matching row writes in order, the last match applies. If the table stops at the first match, the first matching row applies.
