Influencing Event Not in a Known State

In the course of an analysis, even experienced DPL users may encounter the message "Influencing Event Not in a Known State." This error can be roughly restated as "Your decision tree and your influence diagram don't agree." This note explains more about this common error and gives some insight into the relationship between decision trees and influence diagrams in DPL.

Default Trees

There are two points to keep in mind about default trees. First, DPL will never overwrite your tree with a default tree, so once you have changed the decision tree in any way, DPL will leave it alone. Second, you can get the default tree back by deleting the entire decision tree. To do this, Model | Build default tree. DPL will recreate the new default tree.

Get/Pay Expressions

When you run an analysis, DPL checks to make sure it has have enough information to evaluate each get/pay expression. For this to be true, values in a get/pay expression may only depend on events (decisions or chance nodes) that have already appeared in the tree (i.e., to the left of the get/pay expression). Consider the model below:

When this model is compiled, DPL's reasoning will be something like this:

• I see a get/pay expression: Profit
• Profit is Sales - Costs
• Sales has 3 values, one for each state, as does Costs. When I need to calculate Profit, I will be at an endpoint and will know the state of both Sales and Costs.
• OK

In contrast, consider this model:

Here the reasoning is:

• I see a get/pay expression: Profit
• Profit is Sales – Costs
• Sales and Costs each have 3 values, one for each state
• When I need to calculate Profit, I will know the state Sales is in, but I don't know which state Costs is in.
• Error: 'Influencing Event "Costs" Not in a Known State'

This decision tree causes trouble because it doesn't have all the nodes that condition Profit. However, it is also a problem when all events are present in the tree but the get/pay expression comes too early in the tree. The model below also causes the error 'Influencing Event "Costs" Not in a Known State.'

Adding a Node

When you add a decision or chance node to your influence diagram, you need to make sure the node is included in the tree. If you haven't changed the tree yourself, then DPL will update the default tree to include the node. If you make make changes to the default tree that DPL considers structural (such as re-ordering nodes), DPL will not automatically update the default tree. If you haven't made any real changes to the tree, then delete it and let DPL create a new one.

If you have made true structural changes to the tree, then you need add decision/chance instances yourself to place the node in the appropriate place in the tree.

Asymmetric Trees

Making sure all conditioning events are in known states is more difficult when the tree is asymmetric. Once you make a tree asymmetric, DPL can no longer update it for you, so you will need to update it yourself.

Suppose you add an uncertainty about whether regulatory approval will be given to sell the product in the above model. If regulatory approval is denied, costs are the same and sales are zero. The model below shows one way to handle this:

The node data for Sales is all zeros if "Approved?" is No. Suppose for efficiency's sake (which may be needed for large models linked to spreadsheets) you want to use asymmetry to decrease the number of paths to run in the tree. It's clear Sales does not need to be considered when regulatory approval is denied. The revised decision tree below reflects this:

While this seems reasonable, DPL will generate the error message 'Influencing Event "Sales" Not in a Known State' when you run it. The influence diagram indicates that calculating Profit requires both Sales and Costs. Of course, Sales are all zero when the product is not approved, but DPL cannot make this assumption.

The problem is the manner in which the "Approved?" event was included. In order to include "Approved?" in such a way that an assymetric tree can be used without generating an 'Influencing event not in a known state' error, a different approach is needed. Make Profit, rather than Sales, be influenced by "Approved?". Consider the new influence diagram below:

A blue arrow from "Approved?" to Profit allows you to enter a separate Profit expression for each state of "Approved?" Taking advantage of this, you may put in "-Costs" for No and "Sales-Costs" (the previous definition) for Yes. Now DPL's line of reasoning for the get/pay expression on the "Approved?" = "No" branch is:

• I see a get/pay expression: Profit
• "Approved?" is No, so Profit is -Costs
• I know Costs
• OK

DPL understands that Profit depends only on Costs when approval is denied, so it runs the model.

Tree-based Dependency Checking

Sometimes rearranging a model to avoid influencing event issues requires major changes. This is most often the case in models which have asymmetric trees linked to spreadsheets. For these situations, DPL provides an override switch. When you turn on "Tree-based dependency checking" in Tools | Options | Spreadsheet, DPL will assume that your decision tree structure defines the correct dependencies and will ignore any unsatisfied influence arcs. Use this switch with caution: you are turning off a safety feature, and if some paths in your tree omit nodes that matter, you could get incorrect results.