Library · Data Practice OS

Decision modelling with DMN

Reference guide · Published · Source reviewed 2026-11-06

Short answer. Before automating or AI-assisting a decision, draw it: what it depends on, what knowledge governs it and what logic produces the answer. DMN (Decision Model and Notation) (Decision Model and Notation, an OMG standard) gives you a shared notation for that. For the logic itself, a decision table is often clearer than code and more reliable than an LLM.

Status. Proposed practice. Not an agreed decision. The platform team's executable-rules options paper (draft, not ready for a decision) scores DMN or GoRules ZEN as one option among several (Where business rules run after migration). This page is about modelling, which is useful whichever engine is chosen.

Two parts of DMN

1. The decision requirements diagram (DRD). Boxes and arrows that show:

Decisions: the question answered ("Eligible for renewal?", "Defect priority").
Input data: the facts consumed (licence status, medical condition flag, defect size).
Business knowledge models: reusable logic (the fee calculation, the risk matrix).
Knowledge sources: the authority behind the logic (the regulation, the maintenance standard, the delegation instrument), with an owner.

A DRD is the cheapest useful artefact in this handbook. It fits on one page, a business owner can read it, and it tells you which layers of the From data to decisions - the decision stack the decision needs. Draw one for each decision that scores high in the Decision inventory.

2. Decision logic. Usually decision tables, plus expressions in FEEL (DMN's expression language). A decision table has input columns, output columns, one row per rule and a hit policy that says what happens when several rows match (first match, unique, collect, priority).

Illustrative defect priority table (hit policy: first):

Defect type	Traffic volume	Speed zone (km/h)	→ Priority	→ Response
Pothole > 300 mm	High	≥ 80	P1	24 hours
Pothole > 300 mm	any	any	P2	7 days
Edge break	High	≥ 80	P2	7 days
any	any	any	P4	Next programme

The values are placeholders. The point is that a business owner can review every row, a tester can write one case per row, and the table carries an effective_from date (Effective dating).

Where decision tables beat code

The business owns the logic. Owners can read and approve a table. They cannot approve a function.
The logic changes on a schedule. New thresholds take effect on a date. A table row with effective dates is easier to change, test and replay than a code release.
Completeness matters. Gaps and overlaps in a table are visible, and tools can check them. Gaps in nested if statements are not.
Appeals and audits. "Row 3 of version 2026-07 applied" is an explanation. A stack trace is not.

Where decision tables beat LLMs

A model can read a policy and suggest logic. It should not be the logic for a rule-based decision:

The same inputs must give the same answer every time. An LLM is not guaranteed to.
The rule must be approved before use (Rule authority). An LLM's reading of a policy is evidence, not an approved rule.
The answer must cite a rule version (Decision provenance).

Good uses of an LLM around a decision table: drafting a first table from a policy document for an owner to correct; extracting the input facts from unstructured text (the defect size from an inspector's note); and explaining the table's result in plain English. Each still needs an evaluation set (Evaluating AI systems).

Where code or ML is better

Heavy calculation (geometry, optimisation, scheduling): code, tested against Given/When/Then cases (Extracting business rules).
Judgement learned from history (likelihood a defect deteriorates): a predictive model, whose output becomes one input column of the decision table, not a replacement for it.

From model to running logic

Draw the DRD with the business owner. Name the knowledge source and owner of each box.
Write the decision table as the rule of record, or as a projection of the rule card in the governed repository (Where business rules run after migration).
Write one test case per row, plus the hard cases: boundaries, missing inputs and conflicting sources.
Run it where it fits: as a dbt model over effective-dated parameters (dbt), in a DMN engine, or in service code generated or tested against the table.
Log every evaluation into a Decision record with the table version and the matched row (Decision records and provenance).

Not when

A decision with two or three stable conditions. A case expression with tests is enough.
Decisions that rest on professional judgement (a medical fitness assessment). Model the requirements (what evidence is needed) with a DRD, but do not pretend a table makes the call.
Do not buy a DMN engine before the platform team spike has run real hard cases (Where business rules run after migration).

Source links: Data Practice reading list.