What DMN gives us
The Object Management Group describes Decision Model and Notation as a language and notation for the precise specification of business decisions and business rules. It gives business specialists and technical implementers a shared visual and semantic form for discussing repeatable decision logic.
A Decision Requirements Diagram can show how a decision depends on information, knowledge and other decisions. Decision tables make rule conditions and outcomes inspectable. FEEL supplies an expression language intended to keep the logic precise. Those capabilities are valuable because they move important rules out of ambiguous prose and into models that can be reviewed, tested and, in suitable environments, executed.
Where the scope changes
A DMN model can tell us how a defined decision reaches a result. It does not, by itself, establish why the decision belongs to the enterprise, who owns its objective, which authority may approve a new version, how a human override is governed or how an action is connected to a later business outcome.
Those are not defects in DMN. They are questions at another architectural level. An organisation still needs to relate the model to capabilities, policies, operating roles, service contracts, deployment controls, evidence retention and measures. It must also decide how DMN works with forecasts, optimisation, simulations, graphs and human review when the determination cannot be expressed as a single rule model.
The modelling standard and the enterprise architecture are complementary. Confusing their scopes weakens both.
Five layers of a usable decision system
Brillion separates the work into five layers. The decision landscape identifies where material determinations sit across objectives and capabilities. The dependency model shows how a decision relies on sub-decisions and information. Decision logic expresses rules, calculations and repeatable requirements, often using DMN. Analytical mechanisms contribute scores, forecasts or optimised alternatives. The operational decision service defines the inputs, output, authority, explanation, version and monitoring contract used in production.
The layers prevent a common mistake: beginning with a rule table and assuming the enterprise problem has been solved. A technically correct table can still implement the wrong policy, use the wrong authority or optimise an outcome that nobody has agreed to own.
How EDAF™ and DecisionOne use the distinction
EDAF™ describes the Enterprise Decision Object around the model: purpose, trigger, context, policy, mechanisms, constraints, authority, action, outcome, measures, feedback, version and evidence. DecisionOne provides the operating environment in which those assets can be modelled, approved, executed and observed.
DecisionOne supports DMN where its semantics fit the problem. It does not require every mechanism to be represented as DMN. A decision may use a rule table for eligibility, a forecast for likely demand, optimisation for feasible alternatives and an accountable person for an exception. The decision record preserves how those contributions led to the authorised result.
That boundary is important to Brillion’s product position. DecisionOne is not presented as another rules engine and EDAF™ is not presented as a replacement for an established modelling standard. The aim is to give each artefact a clear role in a governed operating system.