Alpha Decision Trees (Keuzebomen)
How branches, junctions and fallbacks decide which model, restriction or variable applies
Decision Trees (Keuzebomen)
Static models, restrictions, variables, mass models, viewsheets, option changers, footsteps and light sources are all configured the same way: as a tree of branches. Every branch says "when these choices are made, this is the result". This page explains how the tree turns your branches into one answer, so you can predict what a house will get.
The mental model
- A branch is an AND of conditions.
Woningtype = HW∧Beukmaat = 5400→ modelVG_HW_5400. Several codes of the same option in one branch mean any of (Dak ∈ {A, B}). - A tree gives exactly one result per set of choices. If two branches could both apply, the more specific one wins (see Fallback below). If no branch applies, the tree gives nothing for that house.
- Choices you don't make are filled with the option's base code (the first code of the option) before the tree is evaluated.
Junctions and split order
The editor shows the branches as a tree of junctions (one per option) with edges per code. The tree is built from your branches automatically:
- Take the option that occurs in the most branches: that is the first junction.
- Under every code of that option, repeat with the branches that have that code.
- A branch that has no choice for the junction option becomes the "otherwise" edge at that junction.
The order of junctions is therefore a property of the whole tree, not of a single branch. Adding an unrelated branch can change where the tree splits first; the chip "splitst op A › B › C" above the canvas shows the current order.
Fallback ("otherwise")
A branch that does not constrain the option the tree splits on is filed under the dashed otherwise edge. It fires when the chosen code has no own edge there, or when the option is not chosen at all.
| Branches | Choices | Result |
|---|---|---|
A = 1 → R1 · B = 1 → R2 | A = 1, B = 1 | R1 (A is the junction, A = 1 has its own edge) |
A = 1 → R1 · B = 1 → R2 | A = 2, B = 1 | R2 (no edge for A = 2, so otherwise → B = 1) |
A = 1 → R1 · A = 1, B = 2 → R2 | A = 1, B = 2 | R2 (more specific) |
A = 1 → R1 · A = 1, B = 2 → R2 | A = 1, B = 3 | R1 (otherwise) |
A branch without any choices is the tree's default: it fires whenever no other branch applies. A tree can have only one such branch; a second one has the same conditions and is ignored.
Things the editor warns you about
The chips above the canvas come straight from the backend's interpretation of your branches:
- dubbele takken genegeerd: two branches with exactly the same conditions; only the first one can ever fire.
- 'anders'-takken: branches that act as fallback at one or more junctions (see above). Not wrong, but worth knowing.
- elk-van takken: branches with several codes for one option.
- verouderde keuzes: conditions that refer to an option or code that no longer exists; they can never be true.
Use Test keuzes to pick codes and see which leaf fires and the path the tree takes, or, on a miss, the junction where it stopped.
Exhaustive options
If you select all codes of an option for a branch, the option is not stored as a condition; instead the branch is marked exhaustive for it and the model name keeps an <OptionName> placeholder that is filled in per house. One branch then covers every code. The canvas can expand these virtual leaves; coverage is stored per expanded name.
Names, overrides and coverage
The name of a static model leaf is generated from the prefix and the chosen codes. A name override maps the generated (un-expanded) name to the name your Revit/3D files use; overrides may keep <OptionName> placeholders, which are expanded with the same codes. The viewer, the project coverage and the concept coverage all resolve names through the same rule, so a model that shows as covered in the editor is the one the viewer will load.