Expected Value Computation

This page explains how the model turns impact multipliers and organization characteristics into expected values.

Terminology

Term	Meaning
`Impact Differentiator`	The multiplier name defined in the `imp` sheet.
`SOW`	State of the World. In implementation terms, this is the sampled multiplier value for a given differentiator and simulation.
`OC`	Organization Characteristic. This is the organization-specific value from the `fos` sheet for the same differentiator.

Overview

The engine computes expected values in three stages:

Combine each sampled multiplier with the corresponding organization characteristic.
Multiply those per-differentiator values together to get a base expected value for each organization and simulation.
Propagate that base expected value across years using temporal modifiers.

After that, portfolio optimization may apply additional bracket-level utility adjustments.

For the separate post-EV noise step driven by Model Coverage, see Noise And Model Coverage.

Step 1: Combine SOW And OC

For each impact differentiator, the engine combines:

the sampled multiplier value from imp, and
the organization-specific value from fos.

It does so according to the multiplier type:

Type	How the organization-level value is computed
`SOW x OC`	Multiply the sampled multiplier by the organization characteristic.
`OC ^ SOW`	Raise the organization characteristic to the sampled multiplier.
`SOW ^ OC`	Raise the sampled multiplier to the organization characteristic.

These are the only multiplier types used in the base expected-value calculation.

Step 2: Multiply Across Differentiators

Once the engine has one value per differentiator, it multiplies those values together to get the base expected value for that organization in that simulation.

Important detail:

If an organization-characteristic entry is NA for a differentiator, that term is omitted from the product rather than making the whole expected value NA.
If all differentiator values were NA, the current code would behave like the product of an empty set and return 1.

Step 3: Propagate Expected Values Across Years

Temporal modifiers are not part of the base expected-value calculation. They are applied afterwards when the engine expands expected values across years.

TempModifier-Compounded

This creates a year-by-year propagation factor.

Year 1 starts from the organization-specific value.
Later years repeatedly apply the sampled multiplier.
If no compounded temporal modifier is provided, the engine inserts a default value of 1.

Example:

Suppose:

the sampled temporal multiplier is 0.95,
the organization-specific value is 1,
the model has 4 years.

Year	Applied factor
1	starts at the organization-specific value = `1.0000`
2	`1.0000 * 0.95 = 0.9500`
3	`0.9500 * 0.95 = 0.9025`
4	`0.9025 * 0.95 = 0.8574`

The same organization's expected value is therefore multiplied by a smaller factor in later years.

TempModifier-SingleYear

This adds an extra one-year adjustment.

It is applied only in years whose analysis-year number appears in the multiplier name.
It multiplies whatever compounded factor is already in force for that year.

Example:

a multiplier named GrantDelay2,
sampled value 0.8,
organization-specific value 1.

Then:

year 1: no extra effect from GrantDelay2
year 2: expected value gets an extra 0.8 multiplier
later years: no extra effect from GrantDelay2 unless another single-year modifier matches them

UtilityDeclineParameter

UtilityDeclineParameter is not applied directly to the base expected value. Instead, it is used later when the engine builds per-bracket utility multipliers for portfolio optimization.

Important implementation detail:

UtilityDeclineParameter is a sampled multiplier from imp.
It does not use a corresponding organization characteristic from fos.
The engine excludes it from the base expected-value calculation and then reads its sampled value directly when constructing bracket-level utility multipliers.

The implementation combines three pieces:

Component	Source	How it enters the effective multiplier
Base discount	`orgmeta` rows such as `Discount` / `Utility decline`	Applied as `(1 - discount)`
Base utility multiplier	`orgmeta` rows such as `Utility multiplier`	Applied multiplicatively
Computed decline from `UtilityDeclineParameter`	`imp` multiplier of type `UtilityDeclineParameter`	Converted into an additional bracket-specific discount and combined with the base discount

How The Bracket-Specific Discount Is Computed

For each simulation:

The engine takes the sampled UtilityDeclineParameter value.
It clamps that value into [0, 1].
It converts it into an exponent:

exponent = log2(p + 1)

For each organization, it computes cumulative funding across brackets using the Room for funding values from orgmeta.
It then computes the marginal utility of each bracket from the function:

total_utility = cumulative_funding ^ exponent

From that, it derives bracket-level cost-effectiveness:

ce = (utility gain from the bracket) / (funding in the bracket)

Finally, it converts that into a computed discount:

computed_discount = 1 - ce

So the computed discount is:

simulation-specific because it depends on the sampled UtilityDeclineParameter,
organization-specific because organizations can have different funding-bracket sizes,
bracket-specific because it is derived from cumulative funding by bracket.

After that, the engine combines everything as:

effective_multiplier = (1 - combined_discount) * base_multiplier

where combined_discount is the sum of:

the bracket discount from orgmeta, and
the extra discount implied by UtilityDeclineParameter,

capped at 1.

Practical interpretation:

earlier funding brackets usually keep a higher effective multiplier,
later brackets usually get a lower effective multiplier,
UtilityDeclineParameter controls how quickly marginal value declines as cumulative funding increases.

Input Reference

The input-side definitions of these multiplier types are documented in Impact Multipliers.