11 templates
DMN templates
DMN 1.4 decision requirement diagrams and decision tables, with every hit policy and — the point of the engine — a real check of the table's input space: which rules can both fire, and which inputs no rule answers. A column with no declared domain is reported as undecidable rather than quietly assumed complete.
DMN — Loan Risk Category (complete, no overlap)
The canonical worked example: a decision requirement diagram feeding a UNIQUE-hit table whose rules cover the whole declared input space exactly once. Copy this one — it is the shape a decision table is supposed to have, and the engine reports it as complete because it is, not because nothing was checked.
Business & StrategyDMN — Shipping Band by Weight and Destination
Two enumerated columns and one numeric one, covered completely. The pattern worth learning is the declared domain: weight is bounded [0..30] and destination is enumerated, so 'complete' means something — without the declaration the checker could only say it did not know.
Operations & OpsDMN — Stacking Discounts (COLLECT with a sum)
The hit policy that changes what an overlap means. Under COLLECT-sum, two rules firing together is the design rather than a contradiction, so overlaps are counted and reported as intended rather than accused — which is the distinction almost every decision-table tool gets wrong.
Business & StrategyDMN — Eligibility Screening (FIRST, order is the logic)
A FIRST-hit table, where rule order carries meaning and later rules are deliberately shadowed by earlier ones. Written this way on purpose: under FIRST an overlap is not a defect, and a checker that flagged it would be reporting the notation working as designed.
Business & StrategyDMN — Incident Priority Matrix (PRIORITY)
The classic impact-by-urgency matrix, written as a DMN table with an explicit PRIORITY hit policy so the output order decides which of several matching rules wins. Complete over both enumerated columns, so every incident that can be described gets a priority.
Operations & OpsDMN — Decision Requirement Diagram, No Table
The structural half of DMN on its own: decisions, input data, business knowledge models and knowledge sources, with the requirement kind derived from what sits at each end rather than spelled out a second time. The engine reports each decision as having no table, which is correct and is the point — this is the diagram DMN work starts from, and those findings are the list of tables still to write.
Business & StrategyDMN — Holiday Entitlement (the DMN specification's own example)
The example the DMN specification itself uses to introduce COLLECT with a maximum: base entitlement plus separate age and service allowances, where the answer is the largest matching rule rather than the sum. Complete over both declared domains.
Business & StrategyDMN — Deliberately Incomplete: a Gap in the Input Space
A teaching artefact. This table looks finished and is not: applicants aged 18 to 29 with a score between 600 and 649 match no rule, so the decision has no answer for them. The engine computes the missing region and prints it under the table — open this one to see what a completeness finding reads like before you meet one in your own work.
Business & StrategyDMN — Deliberately Contradictory: Two Rules, One Input
The other teaching artefact. Under UNIQUE, two rules that can both fire is a contradiction rather than a preference — an applicant aged exactly 65 with a clean file matches two rules that disagree about the answer, and the table does not say which wins. Change the hit policy to PRIORITY or FIRST and the same table becomes well defined, which is the lesson.
Business & StrategyDMN — What 'I Could Not Decide' Looks Like
The most important template in this set, and the state most decision-table tools never show anyone. The Region column declares no domain, so the checker cannot know whether the rules cover it — and it says so rather than inferring the domain from the rules' own values, which would make every table complete by construction and every completeness report worthless.
Business & StrategyArchitectural constraints — SFF and hardware fault tolerance (IEC 61508-2 Tables 2 and 3)
The IEC 61508-2 route 1H architectural-constraint lookup — safe failure fraction band by hardware fault tolerance for type A and type B elements — applied to the three subsystems of a knock-out drum level trip, for a SIL verification report.
Risk & Reliability