Decision tree

A decision tree turns a policy into something you can follow without reading the policy. Each node is a question, each branch an answer, each leaf an outcome.

They are best written as text, because a tree that lays itself out stays tidy when you add a branch.


#When to reach for one

  • Triage runbooks: which severity, which team, which page.

  • Eligibility rules that people currently get wrong from memory.

  • Any decision where somebody has written a paragraph beginning "it depends".


#How to draw it in Capable

Route

Use when

Mermaid

Automatic layout, so adding a branch does not mean redrawing.

Graphviz

Large trees; its layout engine handles depth better.


#A worked example

An incident severity tree:

Decision tree

The source, which you can paste into a new diagram and edit:

flowchart TD
  A{Customers affected?} -- No --> B([Sev 3: next working day])
  A -- Some --> C{Workaround exists?}
  A -- All --> D([Sev 1: page on-call now])
  C -- Yes --> E([Sev 2: fix this week])
  C -- No --> D

#A few things that catch people out

  • Every branch must end in an outcome. A dangling branch is a rule nobody wrote down.

  • Keep the questions binary where you can; three-way branches are much harder to follow.

  • If the tree has more than about twenty leaves, it is a decision table, not a tree.



Draw the unhappy path too.