Decision Trees
A decision tree is a graphical representation of the full set of rules that govern a repeatable decision. It is read from a single root down to a set of leaves: each internal node tests one data element, each branch carries a condition on that element, and each leaf is an outcome or an action. A complete path, from root to leaf, is exactly one business rule, and rules that begin with the same conditions share the nodes nearest the root, which makes the common structure visible at a glance. This is the same logic a decision table lays out in rows and columns, arranged in space so the reader follows a path of conditions rather than reading a grid. A variant, borrowed from decision analysis, adds chance nodes carrying probabilities and numeric payoffs at the leaves, to compare options under uncertainty and keep the one with the highest expected value.
Purpose
A decision tree draws the logic of a single, repeatable decision: the set of rules that, from a set of data elements, select one outcome among several. Its distinctive value is spatial. Where a table aligns rules in rows, the tree spreads them out as paths, so a stakeholder follows a sequence of conditions to an outcome without having to read a grid. This layout makes legible what a table keeps implicit: rules that share their first conditions share the same upper nodes.
This explains the strength BABOK grants the technique: segmentation. Routing a request, a case or a customer along a path to the segment or the action it belongs to is precisely what a tree shows well. The decision stays atomic, a single outcome is selected on each pass, but the path leading to it remains legible to someone who does not know the notation.
The deliverable is the tree itself: a root, decision nodes that each test one data element, branches that carry the conditions and leaves that carry the outcomes, with the guarantee that any valid set of inputs reaches exactly one leaf. A variant answers a different goal, comparing options whose consequences are uncertain. It adds chance nodes, one probability per outgoing branch and a payoff at each leaf, then keeps the option with the highest expected value. Both share the tree form, they do not answer the same question, and confusing them is the technique's first pitfall.
Usage
When to use it
- Rules sharing their first conditions: the upper nodes make the common structure visible.
- Segmenting a customer base or a flow of cases: route each input to its segment or its action.
- A small or medium rule set to communicate: a path is followed faster than a dense grid.
- A decision with sequential, dependent conditions: when the order of evaluation itself carries meaning, the tree shows it.
- Choosing between options under uncertainty: the chance-node variant compares expected values.
When not to use it
- Many independent conditions over shared data: the tree explodes and duplicates its subtrees, prefer a decision table.
- A complex decision that breaks down into sub-decisions: a single tree hides the dependencies, map it first with a decision requirements diagram.
- Logic to be learned from historical data: this is statistical classification, it belongs to data mining.
Description
The elements of the tree
Four elements make up the tree, and each carries a constraint that must hold on pain of producing a tree that lies. The decision nodes are the internal nodes; each tests a single data element, a condition variable such as a loan amount, an age or a debt ratio. Their order matters: the most discriminating element is placed near the root, because it is the one that separates the cases earliest and keeps the tree small. The branches leaving a node each carry a condition on the tested element, and the branches of a single node must be mutually exclusive and exhaustive: no value falls into two branches, no value falls outside all of them. The leaves carry the outcomes, one per path, and the set of leaves must likewise stay mutually exclusive and collectively exhaustive, so that any valid set of inputs lands on exactly one leaf. The levels, finally, correspond by convention to one data element each: one level asks about the amount, the next about the debt ratio and so on. BABOK puts the property that holds the whole together thus: every complete path, from root to leaf, is one rule and only one.
Building the tree
The standard gives the elements rather than a numbered procedure. Practice orders them into a sequence.
- Name the decision and its set of outcomes
Write the decision as an unambiguous statement and list the possible actions, which will be the leaves. - List the data elements
Those the decision depends on, those alone that tip the outcome. - Order the elements
Place near the root the most discriminating element, or the one the most rules share, so that the common structure rises to the top of the tree. - Draw the tree
One data element per level, one branch per condition value, until each path reaches an outcome. - Validate with three checks
Completeness, every path ends on a leaf and no value is left without a branch; consistency, no set of inputs satisfies two paths leading to different outcomes; exclusivity, the branches of each node do not overlap.
The decision-analysis variant
The same form serves a distinct goal when the consequences of a choice are uncertain, and the notation then takes on two node shapes that must be told apart. A decision node, drawn as a square, is a point where the analyst chooses between options. A chance node, drawn as a circle, is a point where the outcome escapes the choice: each outgoing branch carries a probability, and the probabilities of a single chance node sum to 1. Each leaf carries a payoff, usually a value in francs. The tree is evaluated by fold-back, from the leaves toward the root: at each chance node the expected value is computed, the sum of the probabilities multiplied by the payoffs, and at each decision node the branch with the best expected value is kept. This is expected-monetary-value analysis, which PMI places among the quantitative risk-analysis tools. Labelling the two node shapes carries the meaning: a probability placed on a branch the analyst controls makes no sense, and it is the distinction between the square and the circle that forbids it.
Tree, table and requirements diagram
Three techniques of decision modelling resemble one another enough to be confused, and the boundary decides the right choice. The decision table carries the same rule logic of an atomic decision, in tabular form: one row per rule, one column per condition or action. Same logic, different form. The table wins when the rules are many and independent and the point is to control completeness and the absence of contradiction; the tree wins when the rules share conditions and the point is to show the path and the segmentation. The decision requirements diagram is something else: the map of what feeds what. It shows how a complex decision breaks down into sub-decisions, input data, business knowledge models and knowledge sources, linked in a network. A single node of that diagram, a knowledge model, can itself contain a tree or a table. Table and tree are two drawings of a decision's rules; the requirements diagram is the drawing of how several decisions connect.
The pitfalls
Combinatorial explosion
Each new data element can multiply the number of leaves, and the tree becomes illegible. A tree that has overflowed the page is a sign to switch to a table.
Duplicated or unbalanced subtrees
The same sub-decision reappearing under several branches is a strong sign that the logic is really tabular or that a shared sub-decision should be extracted into a requirements diagram.
Incompleteness
A missing branch, an unforeseen value, leaves an input with no outcome: the decision fails silently or slips through without anyone having decided it.
Overlapping or contradictory rules
Two paths that one real input satisfies yield two outcomes. The tree hides this less than a table does, but nested conditions can still conceal it.
Hidden or conflated probabilities
Mixing the rules tree and the expected-value tree without saying which one is being drawn misleads the reader. A rules tree carries no probability; the branches of a chance node in an expected-value tree sum to 1. Labelling the node shapes avoids the confusion.
Hand-tuned overfitting
Adding a special branch for every edge case seen last quarter ends up carving anecdotes rather than a policy. An edge case usually belongs to an exception rule.
Poor root choice
A badly chosen order of data elements makes the same tree several times larger and harder to read than it needs to be.
AI considerations
A difficulty peculiar to this technique comes from another discipline having borrowed its form and its name. The business analyst's decision tree is a constructed and governed encoding of known rules. The machine-learning decision tree (CART, ID3, C4.5 or an ensemble such as random forest or gradient boosting) is induced from historical data: an algorithm chooses the splits that maximise information gain or minimise impurity, in order to predict an outcome. Same drawing, opposite epistemology, one written from policy, the other inferred from the data.
Assistance serves three jobs. It produces a first draft of a tree from a documented rule repository or a decision table and converts one into the other. It performs a mechanical check: spotting a path with no leaf, an unreachable branch, two overlapping rules. It proposes a split order drawn from past decisions, as a starting point the analyst then governs. These are gains in formatting and checking. The judgement stays with the analyst.
Three limits are firm. An induced tree must never silently become the governed decision logic: in a regulated Swiss setting, a credit grant under the Consumer Credit Act, an insurance eligibility rule, the decision has to be explainable and defensible with respect to policy and law. The training-data biases and hidden proxy variables enter an induced tree invisibly, where a governed rule set is auditable. Finally, the probabilities of an expected-value tree are a judgement about the world: a model may propose them, a stakeholder owns them.
Examples
Routing a consumer-credit application
A consumer-credit grant decision under the Consumer Credit Act is routed on two data elements, the amount requested and the applicant's debt ratio. The tree carries four rules, one per path, and the two rules under each amount branch share their first condition, that common node being drawn only once: this is the textbook case of rules that share a condition, which the drawing shows better than a grid. The same four rules would be written just as well as a decision table; the tree is chosen because the path gives a front-desk clerk the course of an application at a single glance.
Deciding whether to bid under uncertainty
An SME weighs whether to submit a bid on a public tender. The decision, a square node, sets bidding against not bidding. Bidding leads to a chance node, a circle: the contract is won with a probability of 0.35 for a payoff of CHF 52'000 (net margin on the CHF 60'000 contract less CHF 8'000 of bid cost), lost with a probability of 0.65 for a loss of CHF 8'000, the bid cost spent in vain. The expected value of bidding is 0.35 × 52'000 + 0.65 × (−8'000), that is CHF 13'000, against CHF 0 for not bidding: the firm bids. The only point a reader might miss is that the conclusion rests on the probability: below a break-even threshold of about 0.13, the expected value drops under zero and the decision reverses.
- Decision (square): the analyst chooses
- Chance (circle): the world decides
Visualisations
The rules tree is drawn as rectangular nodes joined by labelled branches, read from the root, at the left or the top, toward the leaves. The fan of branches at a node is where exclusivity is read: each outgoing branch is a value of the tested element, and together they must cover every value. The shared subtree reads as a common ancestor, a node near the root sitting on the path of every rule below it, which a table does not show at a glance.
The decision-analysis variant uses two distinct shapes: a square for a node the analyst controls, a circle for a node the world controls. To lose the distinction is to lose the meaning, since a probability on a branch the analyst controls would be absurd. The drawing carries the nature of the node; a table of the same numbers does not.
Beyond a handful of data elements, the tree overflows the page and duplicates its subtrees. That is the signal to change representation: the logic that made the tree explode is the one a table condenses, and moving from one to the other changes only the drawing, the rules stay the same.
Cost
| Phase | Level | Rationale |
|---|---|---|
| Preparation | Low | Naming the decision, listing its outcomes and its data elements for a single decision takes little effort. No data to prepare, no tooling. The only substantive decision is the order of the elements, which is corrected as you draw. |
| Execution | Low to Medium | Drawing the tree and validating it with the three checks is done by hand or in a spreadsheet. The effort grows with the number of data elements, each added element multiplying the leaves. The switch to a table contains that explosion risk. |
| Documentation | Low | The tree is its own documentation: it is enough to keep the conditions and leaves labelled, renumbering the rules if the tree changes. An automated decision additionally requires the data elements to be defined and named consistently, failing which the coded rule inherits the ambiguity of the term. |
Tools
The whiteboard and paper are enough for first drafts and workshops: as long as the order of the elements is still under discussion, moving a branch is free.
The spreadsheet carries the same rules as a decision table as soon as they multiply, and it holds the fold-back arithmetic of the expected-value variant, a column of probabilities, a column of payoffs, one expected value per node.
The diagramming tools (draw.io/diagrams.net, Lucidchart, Visio) produce a clean tree to publish, review or embed in a document. They draw, they check neither completeness nor exclusivity.
The DMN and decision-management platforms (Camunda, Drools/KIE, Signavio) are the level where the decision executes. They standardise on the decision table and the requirements diagram, so a tree is generally designed there first, then transcribed into a table for execution.
The decision-analysis tools (PrecisionTree and @RISK, TreeAge, the dtree package for R) serve the chance-node variant: they hold the probabilities, the payoffs and the expected-value fold-back, then compute the break-even threshold beyond which the decision reverses.
Sources
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.17 Decision Modelling: the definition of the decision tree, the property that makes each path a rule, the sharing of conditions, the strength in segmentation and the limits of decision modelling.
- Object Management Group, Decision Model and Notation (DMN): the context of the decision-modelling family and its neighbours. OMG standardises the decision table and the decision requirements diagram, not a tree notation.
- PMI, A Guide to the Project Management Body of Knowledge (PMBOK Guide): the treatment of the decision tree by expected monetary value within quantitative risk analysis, which grounds the decision-and-chance-node variant.
- Howard Raiffa, Decision Analysis: Introductory Lectures on Choices under Uncertainty, Addison-Wesley, 1968: the primary reference for the decision-analysis tree, decision and chance nodes, expected value and fold-back evaluation.