Premium Discount Decision Table Hit Policy
A health insurer's premium discount is calculated inside a BPMN model by 14 chained exclusive gateways with 23 sequence-flow conditions. Underwriting cannot audit why a policy received 8%, 10%, or 12%. A decision table was drafted with six rules over loyalty years, multi-policy flag, claim-free years, and payment method. It uses hit policy FIRST. The rules include: '5+ years loyalty and multi-policy -> 12%'; '3+ years claim-free -> 10%'; '5+ years loyalty and 3+ years claim-free -> 12%'; and 'multi-policy and claim-free -> 10%'. The business wants the highest applicable discount, never a sum, and a documented rationale. In the last quarter, 3,400 policies were processed, 212 received an incorrect discount, and 61 complaints were logged. Audit found four overlapping rule combinations and one gap: self-employed applicants with 4 years' loyalty and no claims had no matching rule. A business analyst proposes changing the hit policy to COLLECT and summing outputs to 'reward loyalty and claims equally'.
1. Critique the proposed COLLECT/sum approach and recommend a hit policy and decision-table structure that satisfies the business intent.
Read the worked answer
COLLECT with summing violates the stated intent. The business wants the highest applicable discount, never a sum, because discounts are not additive. Under COLLECT the engine would return multiple outputs, and summing 12% + 10% would produce 22%, which is both commercially unintended and hard to audit. COLLECT is appropriate when multiple independent outputs must all be retained - for example, listing every applicable warning - not when rules compete for one maximum.
Use hit policy PRIORITY if the rules can be given a total precedence order and the highest-priority matching rule should win. Alternatively, use FIRST only if rule order is explicitly governed and tested, but FIRST makes the outcome depend on row order, which auditors often find fragile. A cleaner structure is to decompose the decision: first determine eligibility categories (loyalty, multi-policy, claim-free), then apply a priority-ranked discount table. Output the winning rule ID and discount rate, not just the percentage. Add a completeness check so every combination either matches a rule or returns 'no discount'; add a consistency check so no two rules with the same priority produce different outputs for the same input.
2. How should the overlapping rules and the gap for self-employed applicants be resolved? Include verification steps.
Read the worked answer
Resolve overlaps by deciding precedence explicitly, not by relying on row order. For example, if '5+ years loyalty and multi-policy' and '5+ years loyalty and 3+ years claim-free' both yield 12%, they are not a conflict in output but they are redundant; consolidate them or give one higher priority. If one yields 12% and another 10%, the business must state which prevails. With PRIORITY, assign distinct priority numbers and document the rationale. The gap for self-employed applicants with 4 years' loyalty and no claims should be handled deliberately: either add a rule if the policy intends coverage, or add a catch-all default rule that returns 0% and a reason code. Do not let the engine fail silently.
Verification: build a completeness grid over the input domains (loyalty years bands, multi-policy Y/N, claim-free bands, employment type), generate test cases for each cell, and check that exactly one output is produced where required. Use decision-table analysis to find overlapping columns and missing combinations, then have underwriting sign off. Replay the 3,400 historical policies and reconcile the 212 errors before deployment.