Support for simple Decision Requirement Diagrams which depict Decisions, Input Data and Knowledge Source elements, linked by Information and Authority Requirements. Each element and requirement shape must conform to the DMN specification.

Support for groups (dotted rectangles that encompass one or more shapes) is provided. In addition, the ability to add textual annotations both free-standing or associated with specific groups or elements.

The product supports a single DRG (per model) to which one or more, potentially overlapping, DRDs relate. The DRG holds node metadata and the totality of their interrelationships. If two DRDs contain a node of the same name it is understood that these are references to the same underlying object (or the tool supports this possibility).  

Each node in a DRG can have relevant metadata attached to it, both the metadata defined by the standard (e.g., Business Owner, Questions and Answers) and custom metadata defined by users. This metadata is accessible from DRDs referencing the node.

The ability to define decision logic with free form (non-executable) natural language or pseudo-language or examples.

The ability to associate decisions with business value metrics (e.g., profitability, reduction in client churn, security, failure rate). At this level the KPIs are unregulated and exist for the sole purpose of documentation of business value.

KPIs are defined using a (extendable) set of quantities (e.g., MTBF, client retention, profit) with a strongly typed goal (e.g., percentages, amounts of money, failure rate) and time frame. In other words, they are valid SMART (Specific, Measurable, Achievable, Relevant, Time-bound) goals. These are still for documentation purposes although external tools could utilize this metadata.

The ability to define a set of data types that support a specific business purpose. For example, a cash-flow ladder, a medical risk or an applicant.

Ensure that the DRD and decision logic have consistent connection semantics.

Missing dependencies: The product can inform users if their DRD is inconsistent with the needs of their logic (e.g., the logic definition has an unsatisfied dependency).

Unused dependencies:  The product can prevent dangerous practices such as 'push-'through' dependencies (i.e., information items passed into a decision, A, with the sole aim of passing them to decisions which have an information dependency on A rather than using them itself).

The ability to search for all the diagrams using a specific node by node name. Both interactive search and a list of search results (a report) is covered by this Dimension.

The ability to use an execution language in a boxed context.

The ability to interchange the core DMN elements: Decision, Input Data and Knowledge Source. In addition, the ability to interchange other supported nodes, for example BKMs. The metadata includes owner, questions and allowed answers and KPIs (if supported).

The relative placement of all nodes in the diagram. In addition, this covers additional styling (e.g., color, font).

The ability to interchange all other functionality supported by the product.

The ability to visually wrap one or more nodes in a decision service element that reflects a 'service's public API, the logic it encapsulates (publicly and privately), its internal and external data requirements and the external requirements it have.

This one covers all boxed expressions as defined by the DMN standard but literal expressions and decision tables, which have their own nodes in the dimension diagram.

The ability to define decision logic with execution language that can use structured data (with no side effect), as defined by the item definitions of the decision model, and perform calculations and transformations on it.

The tool is able to show, visually, how two (or more) revisions of the same DRD are different. The depiction of differences must be contextual (a mere side by side comparison of version A and B is not sufficient). The DRDs may be in different branches if branching is supported.

The product can be integrated into a broader release management lifecycle, and this may include DevOps support, integration with one or more of the following revision control systems or equivalent: Git, Perforce, ClearCase, SVN etc.

The support for generating and sharing comments on any part of a decision model that is visible to all involved modelers. This feature, akin to social media, might involve integration with a chat platform or email to support contextual discussion of issues and tasks.

The ability to retrieve all nodes with metadata that contains a specific text, term or hashtag. For example, show all the nodes that are owned by a specific entity or that have a term in their description.

The ability to search advanced or user-defined metadata for specific terms and hashtags. For example, to find all decisions that contribute to the profitability KPI.

The product is able to support a single, multiuser branch of revisions with commented milestones in the evolution of a decision model.

Find all decisions with information, authority or knowledge requirements on a specific node.

For example: find all decisions and decision table rows impacted by 'basket price.discount' for a specific data instance (so some knowledge of the data dependencies on logic calculations would be required).

The ability to interchange DMN item definitions: custom data types, their properties and relationships, as well as any associated documentation and metadata.

The functionality to group users in hierarchies to enable permission to be allocated at a coarser grain.

Machine Learning is a heavily overloaded term, often used for marketing purposes. We will define Machine Learning (ML) here to avoid uncertainty and misunderstanding in this context. A strict subset of artificial intelligence, ML is a statistical approach in which a learner performing a task T, with a performance metric of P, can automatically increase P over time with experience (i.e., past instances of the task, optionally with a correct answer). No explicit programming of the learner is involved; the learner is conditioned by examples only. Common examples of ML are learners that classify email (as spam or ham) or predict individuals' creditworthiness.

Although not defined by the DMN standard, we feel that machine learning (ML) decisions engage in relationships that ordinary decisions do not. For example, an ML decision would require training data, knowledge about the historical statistical distribution of inputs and the ability to learn given experience. Therefore, they merit their own node in the progression graph.

In addition, consider that ML decisions have properties that other decision do not. They have a distinct development and deployment lifecycle. ML decisions using techniques like reinforcement learning, Markov models, ARIMA and Kalman filters have the ability to learn, incrementally from their experience, while they are deployed – they are learning decisions. Unlike , . Hitherto, decision modeling has assumed that decisions are repeatable and this is often a desirable property. Adaptive decisions are not repeatable by design and need to be distinguished, even if only by a subtle variation on the rectangle shape. This important difference may require some visual representation and supporting metadata.

The product offers facilities to check or improve model soundness.

The tool is able to support generation of new DRDs based on a DRG. For example, 'nearest 'neighbors' of a specified node, all nodes required to define a specific Information Item or all nodes with a specific hashtag.

The entire DRG and individual nodes within it can be documented (using highly-structured, rich text) in a manner that supports the definition of business value, responsibilities, integration and key use scenarios, and optionally allow the generation of a document taking into account the decision model and that rich, structured text.

The ability to support DMN decision tables as defined by the standard, which allows decision tables that are not executable as well as ones that are. Decision tables can have cells containing free form text, structured logic or a path language.

Logic expressed in a structured fashion and which should be easy to understand and verifiable by means of an automated process, although not necessarily executable.

Simple log of all sub-decisions and data leading to each outcome.

The ability to fabricate an explanation for an outcome as an additional output of the decision model itself. This can be done using the decision model to produce extra output (i.e., deliberately collecting additional information to substantiate an outcome). A common example is including the annotations of executed rows in a decision table as a step-by-step explanation. Another technique is to animate the execution of a decision (with movements and color), showing step-by-step how an outcome is derived from inputs and interim results.

Alternatively, tools can use generative networks to create natural language explanations[4] or graphing tools to create visualizations of why a specific outcome was reached in a specific decision instance. Tools could also visualize the border between one outcome and another given the inputs. Typically, this is achieved by graphically representing the relationship between inputs and outcomes.

Facility that tools provide that make models easier to understand e.g. filter out all the rules that lead to one outcome.

• [1] https://www.statistik.uni-dortmund.de/useR-2008/slides/Strobl+Zeileis.pdf
• [2] https://arxiv.org/abs/1602.04938
• [3] https://arxiv.org/abs/2202.05594
• [4] https://www.arxiv-vanity.com/papers/1811.00196/

The ability to determine the importance or weight of each input in decision making. For example, for a decision model that determines student loan and grant awards, determining the weight of each input in determining the grant award. In practice this can be done globally - by determining the importance of the inputs across all possible outcomes of the decision – or locally - by determining the importance of inputs in a specific case.

Global importance can be measured by seeing how the accuracy of the model declines if individual inputs are shuffled or omitted entirely (permutation importance[1]) or by statically analyzing the model to measure the influence of each input (by, for example, determining how many times it was used to select between different outcomes). To make global methods more useful the analysis is performed separately for each major class of outcome (e.g., for each income bracket of loan applicant) because the importance of inputs can differ between classes.

Local methods focus on how important each input is to a given instance of a decision. For example, by how much would each input (e.g., 'student's income) have to change to yield a different outcome (e.g., grant award). Alternatively, one could determine the contribution to the outcome of each input. This measurement of how sensitive an outcome is to change in the input is called perturbment analysis. Methods to determine this include LIME[2] and Shapley Values[3].

The ability to define a vocabulary of single business words and phrases and label them in context. That is, highlight the fact that a sequence of words (e.g., ""cross-funded hedge transaction"") is linked to a dictionary definition.

Part of this is the recognition and demarcation of the use of these terms in the names of DMN nodes, in metadata, in documentation or in logic definitions. Another part is the ability to maintain a dictionary of these terms, remind users of their meaning and support consistent usage.