DMN stands for Decision Model and Notation.

It is an industry standard which dictates how business rules should be modelled and represented.

This modules adopts v1.1 of the specification.

Please read more about the specification here:


A “decision” can be a simple “yes” or “no”, i.e. it may denote the option that is chosen. Or it could be the act of choosing one decision out of many decisions. The spec usually refers to the latter definition.

The most common form of representation is called a Decision Table. However, in practical decision modeling situations we commonly have decisions depedent on other decisions. Such complex decisions are associated with other decisions by some relationship - usually called as associations or requirements.

This whole picture is adequately captured by something called a Decision Requirements Diagram (DRD). In other words, a DRD is a visual representation of a decision (or a set of decisions as the case may be).

In a more technical lingo, a DRD represents a graph, where your decisions are the nodes or vertices, and, the associations are the edges. Hence, in ordinary parlance, when we talk about decisions - it is probable to expect complex relationships or associations. Therefore, in the context of modeling business rules or decisions, a decision is synonymous with its decision graph, unless otherwise specified. The complete graph is called decision requirement graph

When it comes down to defining “what” a decision is, or “how” it is to be computed, we are implicitly defining some rule or “logic”. This is also known as decision logic.

At the decision logic level, the specification defines the following constructs:

  1. Decision Table
  2. Boxed Context
  3. Boxed Invocation
  4. Business Models
  5. Knowledge Sources
  6. Input

We may define business rules with one of more of these constructs provided they are suitably associated with each other.

Note: The engine we use currently may not support all of the above constructs. Please visit FEEL to know more about them. You can still model rules without those constructs