The fsm section of a grammar description consists of a list of state descriptions. Each state description defines a list of transitions that are supported for leaving that state. Each transition in turn specifies which input event and optional guard condition combination would cause that transition, any action that must be executed when that event-guard pair occur in that state, and the next state that the state machine will jump to.

As an example, we shall consider a rule from the pedestrian crossing controller state machine whose complete grammar has been seen previously here:

    // Once the lights have gone green, there is a
    // minimum interval they must remain green before
    // the controller will respond to the next button press.
 
    TimedGreen: 
        TIMERTICK[ButtonWasPressed] Yellow
        { SetLightYellow(); SetYellowTimer(); }
    |   BUTTONPRESS TimedGreen
        { RecordButtonPressed(); }
    |   TIMERTICK[!ButtonWasPressed] Green
    ;  

Notice the basic syntax for a state description. The name of a state that is being defined is followed by a colon. This is then followed by a list of transition descriptions, separated from each other by the vertical bar character. The state description is then ended by a semi-colon.

Each transition description consists of the name of an input event, as previously listed in the events or tokens section of the grammar. The input event name may optionally be followed by guard condition in square brackets if a guard condition should also be true for the event when it occurs as an input to the state machine. The input event and optional guard are then followed by the name of the next state to jump to.

For example, in the excerpt above, the state TimedGreen has a transition that says: if a TIMERTICK event should occur, and the guard function ButtonWasPressed returns true, jump to state Yellow.

After each transition rule there can appear an optional block of C# code enclosed in an outer set of curly braces. This indicates to the state machine generator that when this transition is recognised and takes place, that block of code should be executed as the action function. Hence in the above example, when transiting from TimedGreen to Yellow, the functions SetLightYellow followed by SetYellowTimer will be executed.

Sometimes when designing a state machine we discover that all transitions out of a state have to execute some action code regardless of which state we are transiting to, or which event occurs. This typically might be some clean-up operation necessary before exiting the state. Rather than add this action code at the beginning of each action for every transition away from the state, we can refactor this by declaring an exit action for the state. This is written as a special rule after the state name and its colon have begun a state description. The reserved word exit or onexit is followed by the code block to be executed on leaving the state by any transition.

Similarly, an action to be taken on arriving at a new state via any transition can be introduced by using the reserved word entry or onentry.

When exit actions, actions on transitions and entry actions all are implied by a particular transition, the order of execution of these actions is clearly defined. Exit actions for the previous state are executed first. Transition actions are executed next. Lastly the entry actions of the new state to which the machine has transferred are executed.

There are no examples of these entry or exit actions in the pedestrian crossing example as it stands, but imagine there was a panic button that could be pressed to set all lights to red (the AllRed) state if something hazardous had happened on the crossing that warranted stopping the traffic for an indefinite period of time. In this case, regardless of which state we were arriving at the AllRed state from, we would want to execute the action function SetLightRed. The AllRed state description might now be rewritten as follows:

    AllRed: 
        entry
        { SetLightRed(); }
        TIMERTICK RedAndYellow
        { SetLightRedAndYellow(); SetRedAndYellowTimer(); }
    |   BUTTONPRESS AllRed
        { RecordButtonPressed(); }
    ;

Note that the Yellow state's transition to the AllRed state on a TIMERTICK event would now no longer need the SetLightRed action as it is implied by the entry action above. Moreover, the developer of the state machine should convince him/herself that it is acceptable to move the SetLightRed action along the list of actions to be executed so that it becomes the last action rather than the first.

Note that the layout used here for rules is not mandated, as white space and newlines are merely separators. It is however a common layout so that the separate rules and rule groups are easily identified.