Principle 12:
All Branching Is Explicit
Whenever a route can go more than one way, that variation must be explicitly modeled — never implied.
OneRoute represents all branching using Decision, Option, or Repeat so alternate paths, exceptions, and loops are structurally visible, measurable, and governable.
Plain-English Summary
Whenever a route can go more than one way, that variation must be made explicit. In OneRoute, branching is represented only through Decision, Option, or Repeat—never through implied narrative.
What this Principle Means
Many processes look linear on paper but behave differently in reality. Branches happen when criteria differ, information is missing, exceptions occur, or cycles repeat. OneRoute requires those branch points to be structurally visible so the route can be understood and governed.
​​​
The Three Branching Operators
-
Decision: a selection point where one path is chosen based on criteria or judgment
-
Option: an alternate path that can be taken (often situational or conditional)
-
Repeat: a loop that returns to an earlier point until a condition changes
Why Explicit Branching Matters
Implicit branching hides real complexity. It causes inconsistent execution, makes cycle time unpredictable, and prevents reliable automation. Explicit branching turns “exceptions” into visible structure.
​
Concrete Examples
Process planning: If required documents are missing, the route must include a Decision that routes to an Action to request them (and likely a Wait).
Process understanding: A team “sometimes” escalates. In OneRoute, that becomes an Option or a Decision branch—not a footnote.
Natural phenomena: A system may transition along different pathways depending on temperature/pressure thresholds. Those alternate pathways are modeled as Decision/Option branches, with cues as triggers.
​
Mini Case: The Hidden Exception Path
A route claims “submit - approve - execute.” In practice, 30% of cases bounce back for missing information. Without explicit branching, that rework is invisible. Adding a Decision (complete?) and a Repeat/Option path reveals the true behavior and explains performance variation.
How to Apply This Principle
-
Ask: can this step lead to more than one next step?
-
If yes, determine whether it is a choice (Decision), an alternate path (Option), or a loop (Repeat).
-
Make the branch explicit in the route.
-
Ensure the trigger criteria is observable (often via Observe + Decision or Cue).
​
Common Misunderstandings
-
Writing “if needed” in text instead of modeling a branch
-
Treating exceptions as out-of-scope rather than structural
-
Using Repeat when the behavior is actually a Decision to re-route
​
Quick Diagnostic Questions
-
Where do cases diverge in real life?
-
What percentage of instances take the alternate path?
-
Is the loop/branch triggered by time (Wait), an event (Cue), or criteria (Decision)?
​
If You Only Remember One Thing
If a route can go more than one way, the branch must be explicit.
​
Canonical Statement
All variation in OneRoute is explicitly represented through Decision, Option, or Repeat.