Matrices, tables and analysis panels
Typed decision table — unique match
A typed decision table where exactly one rule may match any input: overlapping conditions are defects, not style.
decision.rules@1New DDN source
Why use it?
Uniqueness is the strongest review contract a rule set can carry — any ambiguity fails loudly.
When it helps
Rules that must be exhaustive and mutually exclusive (fee codes, eligibility).
How to read it
- Every input hits exactly one row — or the table is broken.
- Type domains on inputs define what "match" may claim.
What you need
- The input fields and domains
- Non-overlapping rule rows
- The output column
Things to check
- Do not write two rows that can both be true.
- Do not leave a domain hole: unique also requires complete.
Scope of this diagram
Bounded evaluation against one input record; no arbitrary rule-language execution.
Work with the converted example
- Open the viewer and select
decision_unique. Inspect the rendered view and its source. - Open the designer. Keep the selected profile and inspect its legal palette and property controls.
- Change one displayed title or an appropriate data value. Apply the edit and check the resulting diagram.
- Run the verifier and review its diagnostics before moving complete content into review.
- Download your edited DDN source to retain the change.
The example uses the indentation-based ddn-next-1 dialect. The language guide explains reusable definitions, dotted data rows and explicit property blocks.