Here's is a simplistic example of a state machine:

  let transition (state: State) (action: Action) : State option =
     match (state, action) with
     | (StateA, ActionA) -> Some StateB
     | (StateA, ActionB) -> Some StateC
     | (StateB, ActionA) -> Some StateB
     | _ -> None

If you get the quoted representation of the transition function, it can be visualized as a tree data structure (like code-as-data in LISP). You can analyze that tree to understand that if current state is StateB, only ActionA can be applied on it.

Couple this with another realization: "Any sufficiently complicated model class contains an ad hoc, informally specified, bug-ridden, slow implementation of half of a state machine." (not sure where I read this quote).

This means all the entity framework/ORM crap work that we do can actually be neatly represented as transforms on a F# state machine, which suddenly makes the application more powerful if you give it this structure.

We use this technique to auto-generate admin panels.