Decisions are configuration
Replacing hard-coded branches with versioned decision tables the business can read and change.
00 // BriefingThe rule that hid in the code
Every business process has decisions that change more often than the software around them: who approves what, which cases go straight through, which go to review, what counts as eligible. When those decisions live in if-else branches, every change becomes a development task, a test cycle and a release, and nobody outside engineering can read the current rules.
The alternative is to treat decisions as configuration: explicit, versioned tables that the business can read, that engineers can test, and that the system evaluates the same way every time.
01What a decision table is
A decision table lists conditions and outcomes in rows. The system checks the rows against the facts of a case and applies a hit policy, such as "first matching rule wins".
| When | Then |
|---|---|
| Sum assured within the automatic limit and all documents verified | Straight through to the policy system |
| Document AI confidence below 0.85 on any field | Human review queue |
| Medical disclosure present | Underwriter queue |
| Otherwise | QC sampling |
This is the routing table from the insurance case on this site. Anyone in the business can read it, and the order of the rows is itself part of the rule.
Standards help. DMN (Decision Model and Notation) describes decision tables in a form many tools can execute, which keeps your rules from being locked into a single product.
02What belongs in a table, and what does not
Decision tables are powerful because they are simple. Keep them that way.
- Good fits: routing, eligibility, thresholds, approval limits, risk categories and pricing factors, meaning decisions that map facts to an outcome.
- Poor fits: long calculations, loops and the order of work. Calculations belong in code, and the flow of a case belongs in a workflow model such as BPMN.
- One decision per table. If a table answers two questions, split it and chain the tables explicitly.
- Small tables. A table with hundreds of rows is usually reference data in disguise. Move the data into a lookup and keep the rule about how to use it.
- An explicit hit policy. Say whether the first match wins, whether rows may overlap and what happens when nothing matches. "Otherwise" is a rule too.
03Versioning and publishing
- Every published change gets a new version, such as route-application v14, and published versions are never edited.
- Each case records which version decided it, so a decision from last year can be explained with last year’s rules.
- Drafts are kept apart from published rules, and publishing is a deliberate, approved step.
- Rolling back means publishing the previous version again, not editing in place.
If you cannot answer "which version of the rules decided this case?", you do not have configuration. You have a database of if-statements.
04Testing a change before it goes live
Configuration the business can change still needs tests. The difference is that the tests can be business examples rather than code.
- Keep a set of test cases with expected outcomes for each table, written with the rule owner.
- Before publishing, run the new version against those cases and against a sample of recent real cases.
- Show the difference: how many cases would now take a different route, and which ones.
- Publish only when the owner has reviewed that difference, not just the new rows.
A one-row change can reroute thousands of cases. Always look at the impact on past cases before publishing, not only at the rule itself.
05Who owns the rules
Moving rules into configuration moves responsibility. Be explicit about it.
- Each decision table has a named business owner who approves changes.
- Engineering owns the engine, the tests and the audit trail, not the content of the rules.
- Changes follow a light process: draft, test, review the impact, publish.
- Rules that carry regulatory or financial risk get a second approver.
Done well, this is what lets a small team run several products on one workflow core: the platform stays stable, and each product’s decisions change at the speed the business needs.
06Common traps
- Rules hiding elsewhere. Moving routing into a table helps little if the same logic still lives in screen validation, reports or batch jobs. Find every copy and point it at the table.
- Configuration only engineers can change. Rules in a file in the code repository are versioned, which is good, but if only developers can edit them the business still waits for a release. Decide who edits, and give them a tool they can use.
- No explanation in the result. The engine should return which row matched and why, not just the outcome. That one detail makes support, audit and debugging far easier.
- Silent defaults. When no row matches, the case should land somewhere visible, not slip through with an empty route.