Decision Management (ODM, ADS)

 View Only

Decision Modeling: Input Data and Knowledge Sources

By James Taylor posted Tue December 05, 2023 06:26 PM


Posts in the series:

  1. Benefits of Decision Modeling
  2. What is a decision model and what is DMN
  3. Decision Modeling: Decision Requirements
  4. Decision Modeling: Decision Logic
  5. Decision Modeling: Finding and modeling decisions
  6. Input Data and Knowledge Sources [this post]
  7. Building decision tables from decision models
  8. ML, AI and other forms of Data Analysis and Advanced Analytics


The core of any decision model is the network of decisions and sub-decisions. Just building this core will deliver tremendous value. A complete decision model also has Input Data and Knowledge Sources.

  • Input Data objects represent the information that will be passed into your decision-making. Today, this might mean fields on a form or UI, data from an API, notes captured in a conversation. Even images or video. Input data are required by the Decisions in your model just like sub-decisions.
  • Knowledge Sources, on the other hand, play a different role. They act as structured annotations, capturing sources of know-how and documentation in your model so you can show why the model is the way it is.

As a reminder, here’s how the links look:

Decisions can require Input Data, and this is shown with a solid arrow. Knowledge Sources act as an authority for a Decision, and this is shown with a dashed line/circular arrowhead.

Entities and Data Structures

Every input data will ultimately have a data structure and each element in it is defined with a data type. DMN calls these Information Items and Information Types. Information Items act a lot like an XML document in that they can contain additional Information Items and can be singletons or sets. Information Types can have validation logic to enforce specific values and ranges etc. as well as a base type like number or text. This means that an Input Data object can represent a single piece of data – like a date of birth – or a complex data structure with sub-structures and lists like a credit bureau report. As long as the data structure is defined, DMN allows you to group your Input Data however you like.

In general, though, the most useful way is to use logical entities from your data model. Each Input Data represents a single entity and is reused whenever a decision needs fields from that entity. You might split very large entities into several pieces, to make it clearer which groups of fields are used in which decisions for instance, This doesn’t need to be a hard and fast rule,  but it does seem to work best as your SMEs generally understand the entities, a given entity is typically relevant to a coherent set of decisions and data normalization means that each is well structured.

One of the powerful side effects of building a decision model is that you can show which of your data entities is used in each decision. The requirements from your various diagrams will enable you to generate views like this one that show all the ways in which Customer data is used in this decision model:

A note on APIs

When data is passed into an API, it can be easy to think of all the data as input data. Often this is true but not always. Sometimes data is being passed in that was decided earlier – either by a person or by another system or service. In this case, the API is populated with decision outcomes as well as input data. These should be modeled as decisions not input data. If an upstream decision service calculates your credit rating and passes this to another decision service, the credit rating is still a decision. It doesn’t become input data just because you are passing it to a service. Decision Service definitions allow both input data and the results of other decisions to be passed in.

Similarly, APIs often contain data elements that are not needed in the decision model. This might be a legacy of a redesign or to allow the decision to evolve in the future without needing to change the API. This data can and should be modeled as Input Data but you should resist adding requirements to it unless they exist today.

Rule Sources, Policies, Regulations and more

Building a decision model involves analyzing rule sources such as policies and regulations as well as requirements documents, SME expertise, best practice guidelines, training materials and more. Any or all of these can be modeled as Knowledge Sources. Generally, it is worth tracking two kinds of knowledge sources – permanent ones and temporary ones.

Permanent knowledge sources are those that will continue to exist once the model is finished. A credit risk policy or a fair lending regulation will continue to be relevant even once you have a decision model of the decision. These documents will have their own update cycle and knowing how they impact the decision model can help with impact analysis and with regulatory compliance. They should be linked to the decisions they impact– those whose logic is based on them – using authority requirements so that this impact is clear moving forward.

Many of these permanent knowledge sources are large and complex. A network of knowledge sources can be developed using authority requirements so that, for instance, a large regulation can be shown as consisting of several chapters or that a policy is based on a regulation. This can improve impact analysis in situations where policies and regulations are complex. For example, using an example from the book I wrote with Jan Purchase, consider the Federal Reserve Bank regulatory specification 294  Advanced Best Practices controlling the disclosure of liquidity movements (“FED 5G”). This consists of different sections which address how assets are defined, counterparties are classified and how disclosures are made. The latter is further divided into liquidity inflow, outflow and supplementary reporting sections. These can be shown in a hierarchy like that below. Decisions can be linked to the whole regulation, as here, but can also be linked to specific sections or subsections where that makes more sense.

Temporary knowledge sources can also be captured. These are sources analyzed to create the decision model, but which are likely to be retired once it is complete. For instance, the know-how of a particular group of people, a requirements document or list of rules extracted from legacy code might be analyzed to build a decision model but then be retired once their content was represented in the model. Retiring large numbers of such documents is a powerful side effect of decision modeling. These knowledge sources are documented initially to show which decisions are expected to be based on them but can be deleted once the model is complete.

Another powerful way to use knowledge sources is to document analytics, machine learning and AI projects. I’ll cover that in a later post.

If you want more detail, you can get a text book on the approach (written by me and Jan Purchase): Real-World Decision Modeling with DMN 2nd Edition. If you or your company need help with decision modeling, drop me a line and we can schedule a quick call to discuss. And if you’re excited about decision modeling and keen to do more, why not join DecisionAutomation.Org and participate?