This glossary provides our agreed-to definitions of "terms of art" in DI, to reduce ambiguity and increase clarity, reducing confusion, as we work together.

The behavior that implements a Choice that has been made with the intent of achieving an Outcome. Actions are enacted by Decision Maker(s) once Decision Making is complete.

For example, an Action might be to budget $3,000 for marketing activities. This Action would follow after making the Choice for this specific budget, out of a range of possible budgets encapsulated in a Lever.
Compare this to the examples given for Choice and Lever.

Note:
Unlike in a process model, DI does not model a series of actions, tasks, or choices, but rather addresses the consequences of Actions over which the Decision Maker has no further control after the Action is taken. In our example, we think through the consequences of the marketing budget decision during the DI process, but tasks taken to spend that money are modeled using non-DI approaches like a project schedule.

Note:
There are things we do that aren't actions in the DI sense. For instance, we might gather some data, talk to employees, or commute to work and back. In the DI context, we talk about Actions in a specific sense as one of several choices we might make.

The process of using forward simulation to explore how different values of actions lead to different intermediates and outcomes.

Without DI, most action-to-outcome exploration is done "in your head", imagining the consequences of various actions you might take. DI says, "let's use a computer to help with that process", providing this exploration through a user interface or performed overnight in a batch setting.

A software interface with well-defined inputs, outputs, and behavior that allows a program like a CDD simulator to use the services of another independently developed piece of software like a Technology Service implementing a Decision Asset.

In decision modeling or decision simulation, an assumption is an external factor about which we have some uncertainty.

A cause-and-effect path through a Causal Decision Diagram starting at a Lever (Action) and ending at an Outcome.

Note that in DI, there are varying levels of what we mean by "causal" in a causal chain. When we first elicit causal chains from subject-matter experts, we can honestly say that they are more "causal-ish" than anything else, because people aren't great at separating causation from correlation, and because they sometimes mix in the fact that 3 and 5 "cause" 7 if we add them together - ways of causal thinking that don't fit a strict formalism.

In DI, we find it's important to capture these "causal-ish" chains, and then to refine them as needed into software, when ends up being more constrained and formal.

A diagram that shows theDecision Elements, linked by Causal Chains, pertinent to a Decision.

See also: Causal Decision Model (CDM), which is a computer implementation of the CDD.

For an introduction to CDD concepts, see this article by Mark Zangari.

An analytical or software model that provides qualitative or quantitative information about a Dependency or Causal Chain.

Examples include machine learning models, statistical models, and economic models.

A computerized representation of a Causal Decision Diagram (CDD).

One selection from the options encapsulated in a Lever.

Choices are later implemented as Actions taken by the Decision maker.

For example, "we will invest $3,000 in marketing" is a choice.
Compare this to the examples given for Action and Lever.

An interactive whiteboard where a distributed team can collaborate on building a CDD.

Examples include:

Resources necessary for decision simulation, managed and used by Decision Simulation Managers and Decision Simulation Builders.

Examples include:

Synonymous with Analytical thinking, and somewhat like Kahneman's System 2, it means thinking carefully through some reasoning process.

Compare to Divergent Thinking.

In the context of DI, a decision is about Actions leading to Outcomes.

Understanding a decision means understanding causal relationships in Causal Chains.

Note:
The word "decision" has other meanings in the world, most often a decision to label or predict something, like a picture of a cat or tomorrow's weather. These are not action-to-outcome decisions, and so are different (but still important!).

A high-level methodology that guides the decision-making process.

Sometimes approaches may be presented as dichotomies.
Examples include:

Decision approaches may inform and contribute to a decision at a high level, or guide the use of certain Decision Elements. If a particular decision approach is important for a decision, it should be documented in a Decision Artifact.

A record linking documentation about Decision Approaches with their associated CDD(s).

Any important piece of documentation for a decision.

Examples include:

A register listing all repositories used to store Decision Artifacts, what artifacts belong in which repository, who curates each repository, and instructions for submitting artifacts to the repository.

In the Decision Assessment process, the Decision Team identifies concerns and decides how they may deal with the risk each concern creates (accept/mitigate/avoid).

Areas of concern may include uncertainty, provenance, bias for Decision Elements. It is important to consider concerns that you know exist, as well as ones you can infer exist from your CDD.

A component of a CDD or CDM.

The types of decison elements are as follows:

A record of Decision Uncertainties for a CDD.

An asset that can inform a Decision.

Decision Assets may or may not exist before the decision making process has begun. Decision Assets can include data, information, and human knowledge, as well as statistical, machine learning, behavioral, cognitive, mathematical, and other models.

A record of Decision Assets for a CDD.

The person responsible for setting up the boundaries and goals for decision making. The Decision Team answers to the Decision Customer, who may or may not be on the team itself.

Note:
The Decision Maker and the Decision Customer may or may not be the same. The Decision Customer requests the decision. They may or may not delegate making the decision to the Decision Team, The Decision Team Leader, or someone else, or they may retain decision making and use the Decision Team as advisors.

Because the Decision Customer does not interact with OpenDI software in ways that are different than any other role, their role is not formally described in this document.

Any documents that captures the rationale for the decision and the work done by the Decision Team.

Constraints, boundaries, and/or requirements for the decision that come from outside of the Decision Team.

The person who actually makes the decision, that is the person who at some point takes an irrevocable Action (or Actions) that begin a cause-and-effect chain that are intended to eventually lead to Outcome(s).

This role is described in Roles and User Stories.

Note:
The Decision Maker and the Decision Customer may or may not be the same. The Decision Customer requests the decision. They may or may not delegate making the decision to separate Decision Makers, or they may retain decision making and use the Decision Team as advisors.

The process of utilizing the CDD to put in place everything the Decision Maker(s) need to make the decision and take Action.

This includes adding existing Decision Assets to the CDD, understanding uncertainties and constraints, modeling decision behavior, and determining the Approaches the Decision Maker will use to make the decision.

The process of creating a CDD that models the decision, showing the chains of dependencies that lead from actions to outcomes and allowing Decision Maker(s) to align about the decision rationale.

A computational rendering of a Causal Decision Diagram (CDD).

Understanding the dynamics of the decision model and identifying patterns of decision behavior like feedback loops and unintended consequences and understand the sensitivity of the decision to various decision elements.

A form recording the information and insights gained by simulating a Scenario.

The act of observing and/or measuring attributes of Levers, Intermediates, and other Decision Elements as a decision unfolds over time.

This is performed by the Decision Monitor, described in Roles and User Stories.

The high-level statement of the purpose (objective) of the decision, provided by the Decision Customer.

For example, "Determine if offering an Unlimited Usage plan would be a good idea".
Objective statements are usually vague and may need further clarification before a Decision Model can be created.

Use of software automation to apply Decision Simulation to a large number of Scenarios in order to determine the Lever values that produce the best Outcomes for a given set of External assumptions or for several sets of External assumptions.

Assessment of the decision process quality and recommending process improvements as needed.

A record of Decision Retrospective work.

A model showing actions to outcomes that appears as part of a (or another) decision model.

A Decision Sub-Model may be any existing Decision Asset that shows cause and effect. It need not necessarily be expressed as a CDD.

A team of persons (or a single person) responsible for implementing one or more steps of the Decision Intelligence process.

Possible roles for members of the Decision Team are described in Roles and User Stories.

A Decision Element representing a "causal-like" link that shows how upstream factors influence downstream factors.

Dependencies form the arrows in a CDD. Dependencies can be annotated to show direction of influence or more complex relationships between the Decision Elements they connect.

A Decision Asset that is attached to a Dependency to model characteristics of that dependency.

Such characteristics may include directionality and magnitude. Examples of dependency models include machine learning models, mathematical and economic models, and human behavioral models.

Creative thinking that leads to innovation. Brainstorming is an example of divergent thinking.

Compare to Convergent Thinking.

Leading a team through the process of creating a CDD.

This team may include, but is not limited to, members of the Decision Team.

A Decision Element representing something that the Decision Maker(s) cannot control, which nevertheless influences Intermediates and Outcomes.

Similar to Levers, the effect of Externals can be variable. While some externals represent binary occurrences (things that either happen or don't happen), some represent things that may occur to a greater or lesser degree. Within a CDM, Externals can be modeled as sliders, enabling Decision Makers to model different possible intensities or configurations of Externals.

Examples of Externals include weather, customer behavior, competitor behavior, vendor pricing, the macro economy, etc.

See Decision Element.

A portion of a CDD where a Causal Chain starting at a given Decision Element loops back to become a cause of that same Decision Element.

The process of determining Outcomes from specific values of Levers and Externals.

This typically uses a Causal Decision Model.

A model that can be copied, used, tailored — either in whole or in part — by others. Some have started calling Foundation decision models "Large World Models" (LWMs), so this language here might change if the consensus shifts.

A computer-based resource that stores Foundation Decision Models. A FDMR may be public or private, and it may be cloud-based on local.

A Decision Element which tests an Outcome, often to measure success.

More generally, a Goal partitions an Outcome into a binary .

For example, if a Decision has an Outcome of "return on invested capital, measured as the percentage (net profit on [new product] / net of capital investment), after 18 months", then an associated Goal might be "2%".

Fundamental or observed truth used to calibrate a system. Often, these systems are Decision Assets.

For example, a remote sensor reading against a measurement on-site, "on the ground" or machine learning input data against known labels.

A CDD that incorporates Decision Sub-Models.

A Hierarchical Decision Model is a linked-up decision system, which doesn't narrowly optimize for one thing while creating unintended negative consequences on other things.

An upstream Causal Chain from an Outcome, Intermediate, or proxy for a Lever to find real Lever(s) that the Decision Maker(s) have authority over.

For example, a team might suggest that to "lower the cost of parts" they should "improve relationships with our vendors." "Improve relationships with our vendors" is not a Lever; it is not an action the Team or Decision Customer can take. If you ask, "how can we improve relationships with our vendors?" someone might suggest "talk with them" and if you ask "how?" again you might eventually arrive at "schedule the VP of Production to meet every month with an executive from each of our key vendors."

See also: "Why" Chain

A Decision Element that forms the links in Causal Chains that connect Levers to Outcomes.

Intermediates answer the question of why or how a Decision Maker makes a Choice, which leads to an Action, resulting in an Outcome.

Note that Intermediates often correspond the Key Process Indicators (KPIs) used by many organizations. DI adds a causal connection structure and integration with technology like AI and data to KPIs, which provides considerable advantages.
Intermediates can also be thought of as leading indicators, measurements you can track to provide "early warning". For instance, you might detect a problem with the outcomes of a program that has received $1M budget spend when you have only spent the first $100K: it gives you a formal method for detecting problems early and for supporting a new plan.

The process by which a CDD develops in a stepwise manner over time.

CDDs typically begin as a simple diagram with a limited number of Decision Elements, to which more elements, additional details, and connections to other Decision Assets are gradually added as needed to support decision making.

A Decision Element that encapsulates a Choice or set of choices that could be made to achieve an Outcome.

Levers always represent Actions that the Decision Maker(s) have the ability and authority to take. While some Levers represent binary options (something a decision maker will either do or not do), and some represent a fixed set of Choices, others represent things that the decision maker can do to a greater or lesser degree. These Levers can be thought of as sliders, representing a range of choices.

For example, "amount to invest in marketing" is a Lever.
Compare this to the examples given for Choice and Action.

Software that is, in some sense to be crystallized at a later date, consistent with the standard described by OpenDI, including this document.

A Decision Element that represents an expected result of the decision being modeled.

Well-defined Outcomes are measurable.
For example, an Outcome could be "return on invested capital, measured as the percentage (net profit on [new product] / net of capital investment), after 18 months".

A test on an Outcome is a Goal.

Something that may be easier to measure or manage, but which is not a true outcome/goal.

For example, much of the world treats money as a proxy for happiness.

The process of using a decision model to work "backwards" / "upstream" in a causal chain from effects to causes.

See "How" Chain.

A scenario is a set of Choices for the Levers in a decision, which we may examine in a CDD or simulate in a Causal Decision Model to see the result.

An analysis usually done as part of Decision Simulation that determines which Levers, Externals, Intermediates, and Causal Chains have the greatest impact on Outcomes.

A curve that can be sketched as a hand-drawn graph, used to annotate a Dependency. Sketch graphs capture human knowledge about cause and effect.

A Decision Asset implemented as a software service.

A Feedback Loop that reinforces undesirable effects.

A Feedback Loop that reinforces desirable effects.

A downstream Causal Chain from a Lever, Intermediate, External, or Proxy Outcome to find real Outcomes that better capture the effects of a Decision.

Asking, "why," is also a way to Elicit new Decision Elements to the right-hand-side of an existing Element. "Why" chains are downstream Causal Chains from Intermediates and Proxy Outcomes to real Outcomes.