A bounded worked example · Decision assumptions
What do your decision weights imply?
Imagine a team shortlisting project-management software. Its toy decision tree branches through budget, integration, usability and scale, ending at fictional options A–I. How often would each option appear if we followed the supplied weights?
This example holds the tree and its weights fixed. It calculates each option’s exact probability, then samples paths so you can compare the two. A frequent outcome reflects the assumptions in the tree; it does not establish which product is best.
Try this. Run 1,000 samples, then 100,000. Compare the sampled percentages with the exact column. Repeat a run to see random variation. The larger sample usually settles nearer the fixed probabilities; it learns nothing new about the products.
Assumptions first. Frequencies second.
Exact probabilities are ready. Choose a run size to add sampled results.
| Option | Exact | Count | Sampled | Gap (pp) |
|---|
Exact probabilities are shown to three decimal places. “pp” means percentage points: sampled minus exact. Option B has zero weight and is never sampled. These are probabilities within the toy model, not measured customer preferences.
Follow one path through the tree.
Branches show their share of the weight at that fork. After a run, the most frequent sampled path is coloured copper; the same path is written below. Scroll the diagram horizontally on a small screen.
Loading the diagram. All weights and paths are also available as text below.
Run a sample to inspect its most frequent path.
Read every branch and its supplied weight
Each child’s weight is divided by the total of its siblings. For example, weights 1 and 1 mean a 50/50 split. Some original branch descriptions repeat or overlap; they are retained here to make the toy’s assumptions inspectable, rather than presenting it as a complete requirements model.
What this example teaches
Multiplying the conditional branch probabilities along a path gives its exact probability. Random sampling approximates those same numbers. More samples can reduce sampling noise; they cannot repair poor assumptions, missing options or an unsuitable tree.
A weighting detail matters. Options E and F each have a supplied weight of 1. At that fork they therefore get half the probability each, not 100% each. Their full-path probabilities are 0.6 × 0.3 × 0.5 = 9%. Option A instead has 0.6 × 0.7 × 0.85 × 0.75 = 26.775%. The diagram and branch list expose each conditional probability.
Method, sources & the earlier claim
The earlier page called this Monte Carlo Tree Search and described an “80th percentile technology manager”. Its code supplies no evidence for that persona. It repeatedly samples a fixed tree; there is no reward function, expansion of a search tree or learning from rewards. The accurate description is weighted Monte Carlo path sampling.
For the distinction, see Guillaume Chaslot’s Monte-Carlo Tree Search (2010), chapter 3, which explains selection, expansion, simulation and backpropagation. That is background reading, not a method this example implements.
The tree, nine options, descriptions, weights and three run sizes are retained from the earlier published source. The repair adds exact probabilities, preserves the identity of repeated-label nodes when highlighting a path, and excludes zero-weight branches at random-number boundaries. Model checks cover this limited construction.