Something this formally explicit about FSMs strikes me as most valuable for Product Managers or QA who, in my career so far, tend to need help clarifying their thinking, so as a backend to some tool like that.<p>Most engineers are encoding a state machine <i>somewhere</i> in their code, either implicitly or not. But whether an engineer gets more value out of formalizing the code around it like this is up for debate to me. Maybe as a first iteration as way to approach correctness first for those Javascript projects whose requirements aren't too demanding or where the team has issues around thinking explicitly about how to eliminate invalid states (which, to be fair, there are enough of those some team somewhere should consider it), but at the same time a testing regime could accomplish the same thing (ensuring only valid edges between states are traversible, the right IO called at entry/exit of a state, etc but IIRC it assumes a JS environment) without "stretching out" your code surface to formally describe a compound state machine.<p>I do think as a data representation though, SCXML is likely very attractive for IVR projects, or any project where a user is navigating some state machine via input cause you can separate the domain from the FSM description (via XML namespacing is one way, though SCXML does have elements for describing domain data, simple logic, etc), which makes the data you really care about more framework/language agnostic