# 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](https://help.gocapable.com/images/att1417871399.svg)

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.

---

## Related

[Decision tableDMN rules with real hit policies.](https://help.gocapable.com/diagrams/decision-table.html)

[Value stream mapWhere the time actually goes.](https://help.gocapable.com/diagrams/value-stream-map.html)

[ExamplesWorking diagrams you can copy.](https://help.gocapable.com/diagrams/examples.html)

---

_Draw the unhappy path too._