diff --git a/docs/functional-areas/supervisor/conditions.md b/docs/functional-areas/supervisor/conditions.md
index 1b6dc0509d..c55c8376c7 100644
--- a/docs/functional-areas/supervisor/conditions.md
+++ b/docs/functional-areas/supervisor/conditions.md
@@ -10,3 +10,5 @@ All conditions are collected in a bit field that expresses the full state of the
 that are relevant to the supervisor.
 
 All conditions can be found in the `src/modules/interface/supervisor_state_machine.h` file.
+
+The condition bit field is used to trigger [state transitions](transitions.md).
diff --git a/docs/functional-areas/supervisor/index.md b/docs/functional-areas/supervisor/index.md
index 58197f900a..a26d45fb37 100644
--- a/docs/functional-areas/supervisor/index.md
+++ b/docs/functional-areas/supervisor/index.md
@@ -14,8 +14,8 @@ situations or for protection.
 
 The update sequence is separated into a few steps:
 1. Collect data from sensors and the system. We call these [conditions](conditions.md).
-2. Based on the conditions, check if the state machine should transition into a new [state](states.md)
-3. If there is a state transition, possibly execute one ore more actions
+2. Based on the conditions, check if the state machine should [transition](transitions.md) into a new [state](states.md)
+3. If there is a state [transition](transitions.md), possibly execute one ore more actions
 4. Set the new state
 
 ## Modifying behavior
diff --git a/docs/functional-areas/supervisor/transitions.md b/docs/functional-areas/supervisor/transitions.md
new file mode 100644
index 0000000000..0ecebed10e
--- /dev/null
+++ b/docs/functional-areas/supervisor/transitions.md
@@ -0,0 +1,30 @@
+---
+title: Supervisor transitions
+page_id: supervisor_transitions
+---
+
+A state transition takes the state machine from one state to another. The [conditions bit field](conditions.md) is used to identify
+which, if any transition to trigger. Transitions are defined as a list per state and are evaluated in order. If a
+transition is triggered, the evaluation is terminated and no further transitions will be checked. That means
+that the order of a transition list sets the priority, two transitions might have settings that makes both valid, but
+the first one will "win".
+
+A state transition is defined with a bit field of triggers. The bits in the trigger bit field are compared to the bits
+in the current [conditions bit field](conditions.md) to see if they are set. There is also a bit field with negated triggers where the
+bits in the condition bit field should be zero to trigger. To tie it together there is a trigger combiner that describes
+the logical operation to use to decide whether the state transition should be triggered or not
+* `supervisorAll` = all `trigger` bits must be set and all `negated trigger` bits must be zero in the condition bit field.
+* `supervisorAny` = at least one `trigger` bit must be set or at least one `negated trigger` bits must be zero
+* `supervisorAlways` = ignore the condition bit field and treat the condition as true
+* `supervisorNever` = ignore the condition bit field and treat the condition as false
+
+The second part of a state transition definition is a blocking functionality that works the same way as a trigger, but
+is negated. It contains a bit field called blockers, a second bit field called negated blocker and a blocker combiner.
+If the blocker evaluates to true, the trigger will not happen.
+
+The final data of a state transition definition is the new state that the state machine will enter, if the trigger
+condition is met and the blocking condition is not met.
+
+The system of state transition definitions with triggers, negated triggers, blockers and negated blockers, match with
+combiners provides a high degree of freedom. Note that it is possible to express a set of state transitions with trigger
+conditions in multiple ways.