FlowFSM: Finite-State Workflow Extraction

• FlowFSM is a finite-state-machine-centered workflow that extracts FSM structures from unstructured protocol specifications using LLM-driven chain-of-thought reasoning.
• It decomposes the extraction process into sequential subtasks handled by distinct agents for command extraction, state-transition analysis, and rule-book synthesis, reducing hallucinations.
• The approach is versatile, supporting both protocol verification in cybersecurity and FSM-driven streaming inference in industrial video analytics with robust performance metrics.

FlowFSM denotes a finite-state-machine-centered workflow in which FSM structure is produced or applied through an explicit staged flow rather than assumed as a fixed artifact. In the literature, the term primarily refers to an agent-based framework for automatically extracting finite-state machines from raw RFC and protocol specification documents by combining LLMs with prompt chaining, chain-of-thought reasoning, and a structured rule-book representation (Wael et al., 15 Jul 2025). The label has also been used for an FSM-driven streaming inference pipeline in industrial video analytics, where frame-level detections are converted into events and then integrated over time through a state-transition function (Zhang et al., 2 Mar 2026). This suggests a broader family resemblance: FlowFSM names workflows in which FSMs mediate between unstructured inputs and downstream verification, counting, reverse engineering, or decision logic.

1. Protocol-specification extraction as the primary meaning

FlowFSM was introduced to address the problem of automatically extracting finite-state machines from RFC and protocol specification documents, especially where protocols such as FTP and RTSP are specified in natural-language RFCs that only implicitly describe states, events or commands, preconditions, postconditions, and allowed sequences (Wael et al., 15 Jul 2025). The paper frames explicit FSM recovery as essential for verification and model checking, vulnerability discovery and fuzzing, reverse engineering, and security analysis, noting that many attacks exploit “weird” or unintended state transitions.

The system is positioned against three established extraction families. Static analysis, exemplified by Statelifter, analyzes code but suffers from path explosion and scalability problems. Dynamic analysis and network traffic analysis, exemplified by Ferry and NetPlier, observe only exercised behavior, so rare or corner-case transitions are missed. Prior NLP and ML approaches from specifications, including RFCNLP, Hermes, and PROSPER, demonstrate that useful FSMs can be obtained from text, but the cited limitations are ambiguity and incompleteness in natural language, brittleness and sensitivity to prompt design or heuristics, hallucinations when using LLMs in a monolithic way, and significant manual effort for cleaning and post-processing (Wael et al., 15 Jul 2025).

Within this framing, FlowFSM is not presented as a general FSM formalism. It is an extraction workflow whose main technical contribution lies in decomposing the task into chained subtasks with structured intermediate representations. The paper explicitly states that the focus is the flow, architecture, and rule-book representation; the final step of drawing a canonical FSM graph is treated as conceptually straightforward (Wael et al., 15 Jul 2025).

2. Agentic architecture and prompt-chained workflow

FlowFSM is implemented on top of CrewAI, a multi-agent orchestration framework, and organizes extraction as a sequence of LLM-mediated stages in which later prompts consume earlier outputs (Wael et al., 15 Jul 2025). The conceptual pipeline begins with RFC preprocessing and segmentation, proceeds through command extraction and state-transition analysis, and culminates in rule-book synthesis and FSM construction.

RFC preprocessing removes headers, footers, page numbers, and formatting artifacts to obtain continuous raw text $T \in \mathbb{S}$. A section parser then defines the RFC as a tree

$\mathcal{T} = (N, E),$

with parsing function

$P(T) = \bigcup_{i=1}^{k} P(S_i),$

where $S_i$ are contiguous subsections identified via regex on section numbering. Each node is represented as JSON with title, body, path, and list of subsections; leaf nodes satisfy

$\forall m \in N, (n, m) \notin E.$

The outputs are leaf-node bodies used as chunks for LLM input and an ordered appendix structure $A$ listing all paths in $\mathcal{T}$ (Wael et al., 15 Jul 2025).

The extraction stages are then assigned to distinct agent roles. The Command Extraction Agent takes RFC chunks, identifies textual phrases that denote protocol commands, classifies them into functional categories, and provides short descriptions. The State Transition Analysis Agent takes the command inventory plus chunk context and determines when each command can be used, what state changes it causes, and which commands can directly follow it. The Rule-book Synthesis Agent merges and reconciles these findings into a final structured rule-book entry per command (Wael et al., 15 Jul 2025).

The chaining mechanism is formalized as

$R_{i+1} = \mathcal{M}(\mathcal{P}_i(R_i)),$

where $\mathcal{M}$ is the LLM, $\mathcal{P}_i$ is the $\mathcal{T} = (N, E),$0-th prompt function, and $\mathcal{T} = (N, E),$1 is the model response at step $\mathcal{T} = (N, E),$2. The paper emphasizes sequential decomposition, intermediate structure, and chain-of-thought reasoning. Rather than asking for the full FSM in one shot, the model first identifies commands, then reasons about precondition and postcondition states, then synthesizes rules. This decomposition is used to reduce hallucinations and increase coverage (Wael et al., 15 Jul 2025).

3. Rule-book representation and implicit state recovery

The operational representation used by FlowFSM is the rule-book. Although the paper does not give a full formal tuple such as $\mathcal{T} = (N, E),$3, it effectively extracts states $\mathcal{T} = (N, E),$4, events or inputs $\mathcal{T} = (N, E),$5, a transition function $\mathcal{T} = (N, E),$6, an initial state $\mathcal{T} = (N, E),$7, and optionally final or accepting states $\mathcal{T} = (N, E),$8 (Wael et al., 15 Jul 2025). The distinctive feature is that these components are first encoded in a human-readable and machine-parseable rule-book, which is later mappable into an FSM graph.

Each protocol command receives a three-component rule-book entry. Chapter 1, “Command Purpose {paper_content} Outlines,” describes the functional role of the command, how it affects system state, and temporal constraints on legal execution. Chapter 2, “Valid Direct Preceding Commands/Methods,” specifies which commands or states must precede the command and whether execution changes system state. Chapter 3, “Valid Direct Subsequent Commands/Methods,” lists legal subsequent commands, the state after executing the current command, and whether the subsequent command changes state (Wael et al., 15 Jul 2025).

The PASS example in FTP illustrates the representation. PASS is described as sending the password and completing the user’s identification process; it transitions the system to a state where account information may be required and must immediately follow USER. Its subsequent legal commands include RETR and TYPE, both under the condition that the user must be logged in. From this, the paper derives a state such as “After PASS, account information may be required / user logged in,” together with a transition pattern USER $\mathcal{T} = (N, E),$9 PASS $P(T) = \bigcup_{i=1}^{k} P(S_i),$0 a state in which RETR and TYPE are legal (Wael et al., 15 Jul 2025).

A recurrent misconception is that protocol states are explicitly listed in RFCs and merely need to be copied out. The paper states the opposite: states are not directly listed in RFCs and instead emerge implicitly from command-purpose descriptions and precondition or postcondition text. Statements such as “User must be logged in” or “It must immediately follow the USER command” are treated as evidence for state labels, which can later be canonicalized programmatically or by a human (Wael et al., 15 Jul 2025). Another misconception is that FlowFSM includes a dedicated validator agent; the paper explicitly notes that it does not present an explicit validator agent that programmatically enforces consistency, though later prompts can be designed or extended to detect contradictions.

4. Evaluation, accuracy, and cybersecurity use cases

The empirical evaluation uses FTP and RTSP, chosen to cover different structures, interaction complexities, and document styles. The LLMs used are llama3.3-70b-versatile, deepseek-r1-distill-llama-70b, and llama3-70b-8192, motivated by strong reasoning capability and large context windows (Wael et al., 15 Jul 2025). Evaluation is performed on state transitions, with all transitions manually checked against the RFCs and standard references.

The paper defines $P(T) = \bigcup_{i=1}^{k} P(S_i),$1 as the number of correctly extracted transitions, $P(T) = \bigcup_{i=1}^{k} P(S_i),$2 as the number of incorrect or hallucinated transitions, and $P(T) = \bigcup_{i=1}^{k} P(S_i),$3 as the number of valid transitions missed. The reported results are: FTP with $P(T) = \bigcup_{i=1}^{k} P(S_i),$4, $P(T) = \bigcup_{i=1}^{k} P(S_i),$5, $P(T) = \bigcup_{i=1}^{k} P(S_i),$6, precision $P(T) = \bigcup_{i=1}^{k} P(S_i),$7, recall $P(T) = \bigcup_{i=1}^{k} P(S_i),$8, and F1-score $P(T) = \bigcup_{i=1}^{k} P(S_i),$9; RTSP with $S_i$0, $S_i$1, $S_i$2, precision $S_i$3, recall $S_i$4, and F1-score $S_i$5 (Wael et al., 15 Jul 2025).

The interpretation given in the paper is that both protocols achieve precision above $S_i$6, recall above $S_i$7, and F1 around $S_i$8–$S_i$9, indicating reliable extraction with relatively few hallucinated edges and good coverage. Performance on RTSP is described as close to FTP, with a precision difference of approximately $\forall m \in N, (n, m) \notin E.$0 and an F1 difference of approximately $\forall m \in N, (n, m) \notin E.$1, which the authors treat as evidence that FlowFSM generalizes to different protocol styles. The recall being slightly higher than precision is interpreted as a recall–precision tradeoff that leans toward capturing more potential transitions, which is considered useful in security contexts where missing a valid transition could hide a vulnerability (Wael et al., 15 Jul 2025).

The extracted FSMs and rule-books are proposed for protocol verification and conformance checking, model-based testing and fuzzing, vulnerability discovery and attack synthesis, reverse engineering and documentation, and security analysis for complex protocols. The paper explicitly notes plans to integrate FlowFSM into protocol fuzzing frameworks and mentions comparison with protocol-analysis systems such as ProtocolGPT, AFLNet, RFCNLP, and Hermes (Wael et al., 15 Jul 2025).

5. FSM-driven streaming inference as a second usage

A distinct 2026 industrial paper uses the term in another sense: an FSM-driven streaming inference pipeline for counting excavator workloads from surveillance video (Zhang et al., 2 Mar 2026). Here the pipeline is online rather than document-centric. The stages are frame stream, object detection with YOLOv9, event identification from detection results, FSM state update, and counting logic. The detector never directly decides that a workload occurred; instead, its outputs are converted into events $\forall m \in N, (n, m) \notin E.$2 through $\forall m \in N, (n, m) \notin E.$3, which are fed to an FSM with update rule

$\forall m \in N, (n, m) \notin E.$4

The finite-state model contains five business states: Digging, Carrying, Approaching, Possibly unloaded, and Unloaded. The event alphabet is $\forall m \in N, (n, m) \notin E.$5, where the events correspond to Vertical bucket found, Horizontal bucket found, Truck found, Bucket approaching truck, and Truck is away. Counting is triggered only when the FSM reaches the Unloaded state, after which the machine resets (Zhang et al., 2 Mar 2026).

This usage of FlowFSM is not about extracting an FSM from text; it is about using an explicitly designed FSM to filter invalid events, aggregate noisy predictions over time, and turn frame-level evidence into a state stream. On 12 videos with over 7,000 images and more than 300 excavator workloads, the FSM-driven method reports precision $\forall m \in N, (n, m) \notin E.$6, recall $\forall m \in N, (n, m) \notin E.$7, and F1 $\forall m \in N, (n, m) \notin E.$8, compared with heuristic rules at precision $\forall m \in N, (n, m) \notin E.$9, recall $A$0, and F1 $A$1 (Zhang et al., 2 Mar 2026). The paper also compares strict and loose heuristic settings and reports that the FSM achieves balanced high precision and good recall without overfitting to a particular threshold regime.

A plausible implication is that the name FlowFSM has broadened from a specific agentic protocol-extraction system to a more general architectural pattern in which machine-learned perception feeds an FSM-controlled flow. The two usages differ in input modality and task, but both make the FSM the principal mediator between raw evidence and downstream decisions (Wael et al., 15 Jul 2025).

6. Position within FSM, LLM, and systems research

FlowFSM belongs to a wider movement that makes finite-state structure explicit in LLM workflows. FASTRIC, for example, is a Prompt Specification Language that makes implicit FSMs explicit in natural-language prompts, guides designers to articulate seven FSM elements—Final States, Agents, States, Triggers, Roles, Initial State, and Constraints—and introduces procedural conformance as a verification metric for multi-turn interaction traces (Jin, 22 Dec 2025). Whereas FASTRIC specifies an FSM for execution, FlowFSM in the protocol-analysis sense extracts one from documentation.

Related work on role-playing uses Codified Finite-State Machines and Codified Probabilistic Finite-State Machines to codify textual character profiles into FSMs using LLM-based coding. In that setting, transitions are executable code and probabilistic state updates are used to model uncertainty and variability in open-ended semantic spaces (Peng et al., 5 Feb 2026). This places FlowFSM within a broader class of LLM-mediated systems that externalize latent state rather than relying exclusively on prompt context.

At the formal end of the spectrum, communicating finite-state machines are expressively equivalent to existential MSO logic with two first-order variables and the order relation, providing a logical characterization of finite-state processes connected by message flows (Bollig et al., 2017). At the implementation end, “Vector Symbolic Finite State Machines in Attractor Neural Networks” provides construction rules such that an attractor network may implement an arbitrary finite state machine with high-dimensional random vectors as states and stimuli (Cotteret et al., 2022). In distributed systems, fused state machines show that fault tolerance for deterministic finite state machines can be achieved with $A$2 additional backup machines rather than $A$3 additional backup machines under replication (Balasubramanian et al., 2013). These works do not use the FlowFSM name as a product label, but they define the theoretical, neural, and systems contexts in which FlowFSM-style architectures operate.

7. Limitations and prospective development

The main limitations identified for FlowFSM in protocol extraction are computational and runtime cost, dependence on LLM behavior and prompt design, and incomplete FSM coverage despite good transition coverage (Wael et al., 15 Jul 2025). The workflow uses large 70B-parameter models with multiple chained prompts over long RFCs, which is expensive and may not scale trivially to very large or many protocols. State labels are textual and may require post-processing to build a canonical state set.

The paper’s future directions are to extend evaluation to more diverse protocol families, optimize multi-agent collaboration and scalability in CrewAI, and integrate the extracted FSMs directly with fuzzing frameworks. It also mentions possible smarter chunking, caching, or retrieval-augmented generation, and implies that explicit validation agents or combinations with symbolic reasoning could be natural extensions (Wael et al., 15 Jul 2025). In the industrial streaming-inference usage, limitations are detector quality, FSM rigidity, scalability to more complex workflows, and camera dependence, with possible future directions including learning FSM structure from data, hybrid rule-learning approaches, and hierarchical FSMs or statecharts (Zhang et al., 2 Mar 2026).

Taken together, these limitations indicate that FlowFSM is best understood not as a closed formalism but as a workflow pattern. In its primary arXiv formulation, it is a carefully engineered, agent-based, prompt-chained workflow for extracting protocol FSMs from natural-language standards; in its industrial usage, it is an FSM-driven streaming inference pipeline. In both cases, the central idea is the same: finite-state structure is used to turn ambiguous, noisy, or weakly structured inputs into explicit, inspectable, and operational stateful behavior (Wael et al., 15 Jul 2025).