Initial transitions

A lifecycle whose instances are created dynamically needs to say which state a brand new instance lands in, and which event puts it there. That's what the initial transitions section is for.

It's optional, and it goes after the Events section and before the first state block.

Here it is in the Transfer lifecycle, which is the Elevator Management model that does create instances on the fly:

initial transitions
    Execute > WAITING FOR CABIN
--

The grammar:

// Initial transitions
initial_transitions = it_header transition* block_end
it_header = "initial transitions" EOL*
transition = INDENT event_name (SP '>' SP state_name)? EOL*

The unindented initial transitions header (note: two words, one space, all lowercase) is followed by any number of indented transitions written exactly the way they're written inside a state — see Transitions for the anatomy of that line — and closed with an unindented --.

So Execute > WAITING FOR CABIN says that a Transfer instance is created by the Execute event and begins life in the WAITING FOR CABIN state.

More than one

The grammar allows several initial transitions, which is what you want when an instance can be created in different circumstances. A different creation event then drops the new instance into a different starting state.

Do I need one?

Only if instances of this class are created while the domain is running. The Door lifecycle has no initial transitions section at all, because the doors in a building are all there from the moment the domain is initialized. Assigners don't generally need one either.

The mirror image of this section is the Deletion states mechanism at the other end of the lifecycle.

What the parser gives you

A list of Transition_a named tuples in the initial_transitions field of StateModel_a, each with an event and a to_state. Parsing the Transfer model above gives you [Transition_a(event='Execute', to_state='WAITING FOR CABIN')].