Why decision tables are the rule format every Business Analyst should know
Last quarter I sat with a Senior Business Analyst at a $1.6B GWP P&C carrier in the Midwest. She had 47 rule-change requests sitting in JIRA, the oldest 8 weeks old, all blocked on engineering capacity. She showed me one of them: a Texas auto underwriting eligibility update covering 12 conditions across credit score, prior carriers, MVR, vehicle age, and policyholder tenure. "It's a 4-cell change," she said. "It should not take 8 weeks."
It should not. The reason it does is that the carrier's underwriting logic lives in Java code, where any change requires a developer ticket, a code review, a release window, and a UAT cycle. The same 12-condition rule rewritten as a decision table sits in a spreadsheet-like grid. The same BA could change the 4 cells, run UAT against 6 months of historical quotes, and deploy to production - in an afternoon, without filing a ticket.
In my experience, decision tables are the single most under-rated feature when carriers evaluate BRMS platforms in an RFP. Architects fixate on throughput and integration patterns; CTOs fixate on TCO. Both forget that the daily reality of running a rules library is whether the Business Analyst who owns the rules can actually edit them. Decision tables answer that question.
This article covers what decision tables are (with a concrete IF-THEN insurance example), how they differ from decision trees, the four hit policies every BRMS engineer should know, the OMG DMN standard, where Higson Studio fits, and best practices I have learned over 200+ insurance implementations. Skip to Section 4 if you want the Higson Studio walkthrough; Section 8 is where I admit when decision tables are not the right format.
What is a decision table?
A decision table is a tabular representation of business rules that maps conditions (inputs) to actions or outcomes (outputs) in a grid format. Each row represents one rule; each column represents one condition or output. Decision tables compress what would otherwise be dozens of nested IF-THEN statements into a single auditable, business-user-editable grid. They are the default authoring format in modern Business Rules Management Systems (BRMS) like Higson, and they map directly to the OMG Decision Model and Notation (DMN) standard - the formal specification for how decision logic should be expressed in 2026.
A concrete insurance underwriting decision table looks like this:
Six rows. Six rules. Compare that to the same logic written as nested IF-THEN-ELSE in Java: roughly 80-120 lines of code, with the credit-score thresholds and state-restriction lists scattered across the file. The decision table is what the Linda BA persona reads, edits, tests, and deploys. The Java is what a developer maintains. Decision tables move the rule logic from "developer ticket" to "BA workflow."
Decision tables vs decision trees: when to use which
Decision tables and decision trees both encode if-then logic, but they answer different questions and fit different problems. The distinction matters because choosing the wrong format triples the maintenance burden later.
Ronald G. Ross, the leading authority on the business rules approach, recommends intersection-style decision tables as the friendliest format for business users - because they let the auditor see every rule at once. Decision trees are more compact for sequential decisions but harder to validate for completeness.
In my experience, 75-85% of an insurance carrier's operational decisions are best expressed as decision tables. The remaining 15-25% - claims complexity routing, multi-step fraud workflows - belong in decision trees or process flows. A modern BRMS supports both; the decision is which fits the specific rule.
Anatomy of a decision table in Higson Studio
Here is what a working decision table contains in Higson Studio - the no-code authoring tool the Linda BA persona uses every day. The same structure applies to any DMN-compliant BRMS, but Higson Studio's choices around hit policy, formula columns, and audit logging matter for production use.
Condition columns (inputs)
Each condition column represents one input to the decision. Conditions can be ranges ("credit score 680-719"), enumerations ("state in {TX, CA, MD}"), exact matches ("vehicle class = sedan"), or references to nested expressions. Higson Studio supports type coercion - the BA can leave credit-score values as integers and the engine handles the rest. Best practice: 3-7 condition columns per table. Beyond 8 columns, the table starts losing the visual clarity that justified using a table over code in the first place.
Action / outcome columns (outputs)
Outcome columns represent what the rule produces - a tier assignment, a premium amount, a routing decision, an action flag. Tables can have multiple outcome columns when one rule produces multiple outputs (e.g., approve + tier + commission rate from one underwriting rule). Higson Studio supports formula columns where the outcome is calculated from inputs ("base rate x territory factor") rather than statically set.
Hit policy
Hit policy determines what happens when multiple rules match a given input. The four standard hit policies are:
- First: Rules evaluated top to bottom; the first match wins. Use for fall-through logic ("check exceptions first, defaults last"). Most common in underwriting eligibility.
- Unique: Only one rule can match; engine throws an error if two rules overlap. Use when the rule set is mutually exclusive by design. Catches authoring mistakes early.
- Any: Multiple rules may match but all must produce the same outcome. Use when the same answer can be reached by multiple paths. Common in eligibility consolidation.
- Priority: Rules ranked by explicit priority; highest-priority match wins. Use when business needs explicit ordering different from physical row order. Common in pricing override rules.
Higson Studio defaults to Unique because it catches the most authoring errors during development. In my experience, I recommend Linda BAs leave it on Unique during initial authoring and only switch to First or Priority when the rule logic specifically requires fall-through.
Versioning, audit log, and deployment
Every cell change in Higson Studio is version-stamped with timestamp, author, and a required change reason. Every decision the table fires in production logs the inputs received, the row that matched, the outputs returned, and the version of the table at the time of execution. For state DOI examinations and NAIC Model Bulletin on AI Use in Insurance audit-trail requirements, this is the difference between a 2-hour examination response and a 2-week one.
Decision tables and the DMN standard
The Object Management Group's Decision Model and Notation (DMN) specification is the formal standard for how decision logic should be expressed in 2026. It defines decision tables, decision requirements diagrams (DRDs), and a calculation expression language (FEEL - Friendly Enough Expression Language). Most modern BRMS - Camunda, Higson, InRule, IBM ODM, Sparkling Logic - implement DMN to some degree.
Why DMN matters for the architect:
- Portability: DMN-compliant tables can in theory move between vendors. In my experience the reality is less portable than the standard suggests, but the gap is shrinking each year.
- Standard vocabulary: RFP conversations are easier when both sides know what a DRD is, what FEEL syntax looks like, and what hit policies the DMN spec defines.
- Auditor familiarity: DMN is increasingly the format regulators expect for AI-assisted decision documentation. NAIC's 2024 Model Bulletin on AI Use in Insurance does not mandate DMN but increasingly references it as the de-facto standard.
Higson's decision tables map cleanly to the DMN spec, with extensions for insurance-specific patterns (state-restriction lists, ACORD-aligned field types, regulatory-disclosure triggers). For pure DMN portability needs, Camunda is more strictly compliant - the trade-off is that Camunda is BPMN-process-centric, where Higson is decision-centric. Pick the tool based on whether your problem is a process with embedded decisions (Camunda) or a decision system with light orchestration (Higson).
Decision tables in insurance underwriting and pricing
Concrete decision-table patterns I have implemented with mid-market P&C carriers. These are the shapes Linda the BA authors most often.
Underwriting eligibility table
Inputs: credit-based insurance score, state, prior at-fault claims (36 months), MVR violations, prior carrier coverage history, vehicle age, vehicle MSRP. Outputs: approve / refer / decline + tier + applicable surcharges. Typical size: 40-60 rows. Hit policy: First (state exceptions ranked above generic rules). Refreshed quarterly during rate filings.
Premium rating decision tables
Inputs: territory (5-digit ZIP), vehicle class, driver age band, multi-policy status, telematics score. Outputs: rate factor (multiplied into base rate by the calling code). Typical pattern: 8-15 separate tables per state - one per rating factor. Hit policy: Unique (each input combination produces exactly one factor). Refreshed at every rate filing.
Claims routing and STP table
Inputs: line of business, severity estimate, fraud-heuristic flags fired, ML fraud score, attorney representation flag. Outputs: route-to (STP / adjuster level 1 / adjuster level 2 / litigation desk / SIU) + initial reserve range + required documentation flags. Typical size: 25-40 rows. Hit policy: First (severity exceptions ranked above defaults). Refreshed when fraud patterns shift.
Producer commission calculation table
Inputs: producer code, new-business vs renewal, premium amount band, line of business, override flag, bonus-eligibility flag. Outputs: commission rate + bonus rate + clawback eligibility. Typical size: 20-30 rows per producer hierarchy level. Hit policy: Priority (override rules ranked above defaults). Refreshed when commission agreements change.
Notus Finance, a Polish bank, migrated their commission calculation from Drools to Higson and now runs 100 000 calculations in 8 seconds - 1.75x faster than the Drools baseline, with business users updating the commission rules themselves through Higson Studio's decision tables. The pattern is consistent: decision tables turn a multi-week IT request into an afternoon BA task.
Best practices for authoring decision tables
These are the lessons I have collected over 200+ insurance implementations. Some are obvious in retrospect; all of them are mistakes I have watched carriers make in production.
Keep each table focused
A single decision table should answer one question. Underwriting eligibility belongs in one table; premium rating in others; claims routing in yet others. The 4 000-row "underwriting matrix" pattern - I've seen this attempted by carriers consolidating spreadsheets - is impossible to test, impossible to audit, and impossible for the BA to navigate. Smaller, focused tables with clear ownership beat one giant matrix every time.
Order conditions from most to least discriminatory
In hit policy First and Priority tables, the order of conditions affects performance. Put the conditions that eliminate the most rules first. For an underwriting table, state usually comes before credit score (because state restrictions are coarse-grained), and credit score before vehicle make/model (because credit is more discriminatory than vehicle for most personal lines). Higson Studio shows row-evaluation count metrics that help BAs identify suboptimal ordering.
Name everything consistently
Use a glossary for input field names. "creditScore" and "credit_score" and "CBIS_score" are three different identifiers to the engine even if they look the same to humans. Higson Studio's data dictionary feature enforces consistent naming across tables. I recommend setting this up in the first sprint of any implementation - retrofitting it later costs more than doing it once upfront.
Document the source of every rule
Every rule should have a source field pointing to where the rule came from: state code citation, NAIC reference, internal policy document, regulator letter, actuarial memo. In Higson Studio this is captured per-row. When the regulator asks during a state DOI examination why a Texas applicant with a credit score of 622 was referred to underwriting, the answer should be retrievable in seconds, not days.
Test with historical data before production
Higson Studio supports shadow-mode testing - run the new decision table against the last 6-12 months of quotes or claims, compare outputs to what the legacy system produced, reconcile differences. This catches the unintended consequences that always surface when a rule changes. The 2-3 weeks shadow-mode discipline saves the 2-3 months production-incident discipline later.
Set up automated regression testing
Once a decision table is in production, every change should pass a defined regression test suite before deployment. Higson Studio supports test sets at the table level - the BA defines a set of test cases ("this input combination must produce that output") and any change that breaks an existing test triggers a UAT block. This is the discipline that separates a working rule library from a chaotic one.
When decision tables are not the right format
I would rather lose a deal than win one badly. Three places where I tell prospects decision tables are not the right authoring format for their specific rule:
- Rules with deeply sequential logic. If your claims-adjudication workflow involves "first check A, then if not A then check B, then if not B then escalate to a human and wait for input," you have a process problem with embedded decisions. Use a decision tree or BPMN flow, not a flat decision table. Camunda is the right tool for this shape.
- Rules involving heavy mathematical computation. If the rule involves matrix operations, time-series analysis, or anything beyond basic arithmetic and lookups, push the math into a function or a referenced ML model and let the decision table call the function. Trying to model an actuarial reserve calculation in a decision table will end badly.
- Rules requiring fuzzy logic or probabilistic outputs. If the rule's output is a probability ("likelihood this claim is fraudulent") rather than a discrete category, use an ML model. Higson supports this via ONNX integration - the rule says "if model output > 0.8 AND rule heuristic fired, route to SIU." The decision table holds the orchestration; the ML model produces the probability.
Decision tables are the right answer for structured, condition-action rules with discrete outputs - which describes 75-85% of insurance operational decisions. The remaining 15-25% need different tools, and an honest BRMS evaluation acknowledges where the table format runs out of road.
FAQ
What is a decision table in business rules management?
A decision table is a tabular representation of business rules that maps conditions to actions in a grid format. Each row represents one rule; each column represents one input or output. Decision tables compress what would otherwise be nested IF-THEN statements into a single auditable grid that business analysts can read and edit. They are the default authoring format in modern BRMS like Higson and map directly to the OMG Decision Model and Notation (DMN) standard.
What is the difference between a decision table and a decision tree?
A decision table presents all rules in one grid where each row is an independent rule - best for eligibility, pricing tiers, and segmentation logic. A decision tree branches sequentially through conditions - best for claims triage, fraud workflows, and multi-step adjudication where order of evaluation matters. Decision tables are easier for auditors and business users; decision trees are more compact for genuinely sequential decisions. Modern BRMS like Higson support both formats.
What are the four hit policies in a decision table?
The four standard hit policies are: First (top-to-bottom evaluation, first match wins - common in underwriting fall-through logic), Unique (only one rule can match, engine errors on overlap - catches authoring mistakes), Any (multiple rules may match but all must produce the same outcome - used for eligibility consolidation), and Priority (rules ranked by explicit priority, highest-priority match wins - common for pricing override rules). Higson Studio defaults to Unique to catch authoring errors during development.
How do you create a decision table for insurance underwriting?
Start by identifying the decision question (e.g., "approve / refer / decline this applicant"), then list all condition inputs (credit score, state, prior claims, MVR, vehicle data), then list all possible outputs (approve / refer / decline plus tier and surcharges). Build one row per logical combination of conditions. Use 3-7 condition columns per table for readability; split larger logic across multiple tables. Order conditions from most to least discriminatory for performance. Test against 6-12 months of historical quotes before going to production.
What is the DMN standard for decision tables?
DMN (Decision Model and Notation) is the OMG specification that formally defines how decision logic should be expressed. It covers decision tables, decision requirements diagrams (DRDs), and FEEL (Friendly Enough Expression Language) for calculation expressions. Most modern BRMS - Camunda, Higson, InRule, IBM ODM - implement DMN to some degree. DMN matters because it provides shared vocabulary across vendors and is increasingly referenced by regulators including NAIC for AI-assisted decision documentation.
Can business analysts edit decision tables without writing code?
Yes - this is the primary value of decision tables. In a no-code BRMS like Higson Studio, business analysts edit decision-table cells through a spreadsheet-like interface, run UAT against historical data, and deploy changes to production without filing a developer ticket. The pattern that works: BAs author rules, architects review for system impact, automated regression tests catch unintended consequences. Carriers typically move from 4-week rule-change cycles (in code) to 24-72 hour cycles (in decision tables).
How many decision tables does a typical mid-market insurance carrier use?
A mid-market $500M-$5B GWP P&C carrier typically maintains 12-25 decision tables across underwriting (eligibility, tier placement), pricing (rating factors per state), claims (routing, STP eligibility, reserves), and compliance (state disclosure logic). Each table holds 25-150 rules. Total rule count across all tables: 2 000-10 000. The Linda BA persona owns the tables; the architect maintains the integration layer that calls them; the actuary contributes the pricing-factor tables.
What are best practices for managing decision tables over time?
Six practices I recommend from 200+ implementations: keep each table focused on one decision question (no 4 000-row matrices), order conditions from most to least discriminatory for performance, enforce consistent field naming via a data dictionary, document the source authority for every rule (state code, NAIC reference, policy doc), test changes against 6-12 months of historical data in shadow mode before production, and maintain automated regression test sets at the table level so any change that breaks an existing test blocks UAT.
Related reading
- What is a Rules Engine? Complete Guide for Insurance 2026 - the BRMS primer.
- Common Business Rules Examples - 50+ patterns that become decision tables.
- Operational Decisions Are the Backbone of Every Business - the decisions decision tables encode.
- Types of Decision-Making in Business - higher-level decision framework.
- Higson Decision Tables - product overview and Higson Studio demo.
- Higson Business Rules Management System - full BRMS product page.
Talk to Higson
Decision tables are the daily reality of running a rules library. The architecture decisions about throughput and integration matter for the RFP; the decision-table choices about hit policies, naming conventions, and authoring discipline matter for the next 5 years. The carriers I work with who get this right run their first decision-table workshop in week 1 of the implementation - not in week 12 when the BAs start hitting friction.
Higson Studio is built specifically for the Linda BA persona authoring decision tables daily. We support DMN-aligned decision tables, four hit policies, type-safe inputs and outputs, automatic versioning, NAIC-grade audit trail, shadow-mode testing, and a data dictionary that enforces naming consistency across tables. Where Higson is not the right fit - pure BPMN workflow problems, rule sets under 50-100 rules, .NET-only shops - we will say so on the first call.
If you would like to see Higson Studio in action - the decision-table authoring interface, the shadow-mode testing flow, and how a $1.6B GWP carrier's 47-rule JIRA backlog goes from 8 weeks to one afternoon - I would be happy to walk you through it.
Three ways to start:
- Schedule a 30-minute Higson Studio demo - we will walk through your top 3 decision tables and show the BA authoring flow.
- Try Higson on AWS Marketplace at $0.63 / hour - author your first decision table in 15 minutes.
- Download the BRE Comparison Guide - vendors compared on decision-table tooling, hit policies, and DMN support.
Citations
- OMG Decision Model and Notation (DMN) Specification - the formal standard for decision tables and FEEL.
- Ronald G. Ross, "Principles of the Business Rule Approach" (Addison-Wesley, 2003) - foundational text on intersection-style decision tables and the business-rules approach.
- Ronald G. Ross, "Designing Decision Tables" series, Business Rules Journal - recommended decision-table styles for business users.
- Jan Vanthienen, "Quality by Design: Using Decision Tables in Business Rules" - Business Rules Journal academic source on completeness and consistency verification.
- NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers (2023, updated 2024-2025) - audit-trail requirements that decision tables natively satisfy.
- Gartner Hype Cycle for Decision Management Software (2025) - BRMS market context.
- Forrester Wave: Digital Decisioning Platforms (Q1 2026) - vendor landscape for decision-table tooling.
- Notus Finance / Higson case study (Drools migration, 100 000 calculations in 8 seconds) - decision-table-driven commission calculations.
- McKinsey & Company, "Building Workflow-Enabled Decisioning" - rule-change cycle time research.
Take Full Control of Your Product Logic
We provide fee Proof Of Concept, so you can see how Higson can work with your individual business logic.
