How do you collapse a full decision table using don't-care entries without losing coverage?

## Why collapse at all The untouched table has one column per combination, so the count is the product of each condition's outcome count. Five yes/no conditions give 32 columns; adding two more gives 128. Beyond about twenty columns a table stops being read, stops being reviewed, and stops being maintained, and an unreviewed table is worse than no table because it looks authoritative. Collapsing keeps the table at a size a group of people can walk through in one sitting. ## The merge rule The operation is mechanical: 1. Pick two columns whose **action entries are identical in every row**. 2. Check whether their **condition entries differ in exactly one row**. 3. If both hold, the value of that one condition demonstrably does not change the outcome, so replace the pair with a single column that carries a don't-care mark — conventionally a dash — in that row. 4. Repeat over the reduced table, including over columns that already carry dashes. Stop when no pair qualifies. Two properties are worth stating out loud in an interview. First, the result is not unique: different merge orders produce different but equivalent tables, exactly as different minimisations of a boolean function can. Second, no information is lost by a legal merge, because the merged rule reproduces the actions of both originals for both values of the dashed condition. ## Worked example A ride-hailing dispatcher table has five conditions — subscription active, pickup inside a priority zone, predicted wait over the threshold, driver supply below the floor, rider's stored fare cap exceeded — giving 32 columns. Most of them fire nothing at all: whenever supply is healthy and the wait is short, none of the three actions fires regardless of the other three conditions, and those eight columns merge into one rule with three dashes. Working down the table, a 4-person team collapsed the 32 columns to 11 in about seventy minutes, and the 11 rules were readable enough that a product owner reviewed them the same afternoon. That review is the real return on the collapse. ## Don't-care is not the same as three other things Most of the marks on a mistake-ridden table come from conflating a dash with something else. - **Don't-care**: either outcome produces these actions. A claim about behaviour, and a strong one — it must be justified by the merge, not assumed. - **Infeasible / impossible**: the combination cannot arise in the real system, for instance a rider holding a subscription discount while flagged as never having registered. These are kept and annotated. Deleting them silently loses the audit trail, and they are the first thing to re-check when the specification changes, because a change can make an impossible state reachable. - **Not specified**: the specification never said. This is a defect in the requirement, not a dash. Marking it don't-care hides a missing rule behind a legitimate-looking symbol. - **Not tested**: a scope decision. It belongs in the test plan, not in a cell of a specification artefact. A table that uses one symbol for all four is unreviewable, because a reader cannot tell a decision from an omission. ## What collapsing costs The collapsed table has fewer test cases, and that is the intended saving — but the saving is real only if the don't-care claim is true of the implementation, and the table is built from the specification, not the code. If two conditions happen to be handled by shared logic, a dash can conceal a defect that fires for only one of the two hidden combinations. So treat collapsing as a risk-weighted decision rather than an automatic step: - For low-risk rules, one case per collapsed rule is right. - For rules covering money, safety, access control or anything with a regulatory audience, re-expand the dashes and test each concrete combination. This is sometimes called expanding to full rule coverage for the rules that matter. - If a defect is ever found inside a dashed rule, expand that rule permanently and add the specific combination as a regression case. A dash that has failed once has lost its credibility. ## Reviewing a collapsed table Two checks catch most damage. The **count check**: expand every dash back mentally — a rule with *k* dashes over yes/no conditions stands for 2^k combinations — and confirm the total equals the full combination count minus the annotated infeasible ones. If it does not, either a combination is uncovered or two rules overlap. The **overlap check**: no two rules should match the same concrete combination, because a combination matched by two rules with different actions is a contradiction, and one matched by two rules with the same actions is redundancy that will drift apart at the next edit. A candidate who offers the count check unprompted is showing the thing the technique exists for: the table is only valuable while it is provably complete.