BPMN Assistant: LLM-Powered BPMN Modeling

• BPMN Assistant is an LLM-based tool that transforms natural language process descriptions into BPMN diagrams using a specialized JSON intermediate representation.
• It integrates natural language processing with structured BPMN generation and editing workflows, enhancing usability for non-experts.
• Empirical evaluations show the JSON approach reduces failures and latency compared to XML, enabling more reliable iterative process modifications.

Searching arXiv for papers on BPMN Assistant and closely related BPMN-assistant tooling. BPMN Assistant is an LLM-based system for creating and editing Business Process Model and Notation diagrams from natural language. In its primary formulation, it accepts process descriptions or modification requests in plain language, converts them into a specialized JSON representation of BPMN, transforms that representation into BPMN XML, enriches the XML with diagram layout information, and renders the result in a browser-based modeling interface (Licardo et al., 29 Sep 2025). The system is motivated by a persistent gap between informal business-process knowledge and formal BPMN models: BPMN is expressive, but its notation, XML serialization, and maintenance workflows remain difficult for non-experts, even though BPMN itself was designed as a common notation bridging business analysts and technical developers (Licardo et al., 29 Sep 2025, 0904.3633).

1. Position within BPMN modeling

BPMN Assistant addresses three recurrent conditions in business-process management. First, BPMN is difficult for non-experts. Second, process knowledge is often expressed in natural language rather than in formal notation. Third, process maintenance is difficult even when a BPMN model already exists. The system is therefore oriented not only toward initial process generation, but also toward iterative modification of existing models through natural-language instructions (Licardo et al., 29 Sep 2025).

This design problem sits within a broader BPMN setting in which diagrams represent events, activities, gateways, sequence flows, message flows, pools, lanes, and artifacts, and in which BPMN serves both business-facing and implementation-facing roles (0904.3633). A BPMN assistant is therefore not merely a text generator. It must mediate between informal descriptions, executable structure, and diagrammatic conventions. In BPMN Assistant, that mediation is concentrated in a structured intermediate representation rather than in direct manipulation of BPMN XML (Licardo et al., 29 Sep 2025).

A common misconception is that natural-language BPMN authoring reduces the modeling problem to prompt writing. The evidence does not support that view. The system’s central contribution is not only the use of an LLM, but the introduction of a specialized JSON-based representation that constrains process structure and supports deterministic post-processing into BPMN XML (Licardo et al., 29 Sep 2025).

2. System architecture and intermediate representation

The architecture has three primary components. The backend is implemented with FastAPI and acts as the orchestration layer. It receives frontend requests, performs intent recognition, constructs prompts for the LLM, handles JSON generation and editing, converts JSON to BPMN XML, validates outputs, retries or reports invalid JSON, sends BPMN XML to a layout service, and returns the enriched BPMN to the frontend. The layout server is implemented in Node.js/Express using bpmn-auto-layout, and its role is to add Diagram Interchange information such as graphical coordinates. The frontend is a Vue.js web interface with a chat panel and a BPMN canvas rendered with bpmn.io / bpmn-js (Licardo et al., 29 Sep 2025).

The system’s main technical idea is the specialized JSON representation. Instead of asking the LLM to emit or modify BPMN XML directly, the assistant uses a top-level process array whose elements are executed in order unless gateways specify branching. Supported task types are task, userTask, and serviceTask; supported events are startEvent and endEvent; supported gateways are exclusiveGateway and parallelGateway (Licardo et al., 29 Sep 2025).

The JSON form encodes gateways semantically rather than syntactically. An exclusive gateway includes has_join and branches, each branch carrying a condition, a path, and an optional next target. A parallel gateway contains an array of branch-local sequences. An important design detail is that, for parallel gateways, synchronization is automatically handled by the system, so the user or LLM does not need to define the converging element explicitly (Licardo et al., 29 Sep 2025).

This representation is intentionally narrower than BPMN 2.0 as a whole. The supported subset is limited to tasks, user tasks, service tasks, exclusive gateways, parallel gateways, start events, and end events. Richer BPMN constructs, and collaboration diagrams with pools and lanes in full generality, are outside the current scope (Licardo et al., 29 Sep 2025).

3. Generation and editing workflow

For generation, the workflow is a linear request sequence. A user submits a natural-language process description; the backend recognizes it as an operational BPMN generation request; the LLM is prompted to produce BPMN in the specialized JSON format; the JSON is validated; it is transformed into BPMN XML; the XML is sent to the layout server; and the layout-enriched BPMN is rendered in the frontend (Licardo et al., 29 Sep 2025). The paper does not publish the full prompt templates, but it states that the backend constructs prompts instructing the LLM to generate BPMN diagrams, initially in JSON form (Licardo et al., 29 Sep 2025).

For editing, the user begins from an existing model, either generated in-session or uploaded as BPMN, and issues a natural-language instruction such as deletion, movement, update, or redirection. The backend and LLM operate over the structured BPMN representation, the LLM determines the relevant edit operations, the backend applies and validates them, the updated JSON is transformed into BPMN XML, the layout server enriches it, and the frontend renders the updated diagram (Licardo et al., 29 Sep 2025).

Editing is organized around five explicit functions:

Function	Parameters	Description
delete_element	element_id	Removes a specified element
redirect_branch	branch_condition, next_id	Redirects a gateway branch to a new target
add_element	element, before_id*, after_id*	Adds a new element at a specified position
move_element	element_id, before_id*, after_id*	Moves an existing element
update_element	new_element	Updates properties of an existing element

The assistant interprets editing instructions through a structured sequence: analyze the natural-language request, identify affected BPMN elements, select one or more editing functions, generate function calls with parameters, and validate process integrity (Licardo et al., 29 Sep 2025). The backend preserves continuity through reconnection logic on deletion, integration logic on insertion, and gateway-preserving branch edits. This suggests a semantic graph-editing model rather than textual patching of XML.

The distinction between generation and editing is central. BPMN Assistant is not only a text-to-diagram system; it is also a conversational model-maintenance system. That emphasis on editing reliability explains why the JSON representation matters more strongly in editing than in generation (Licardo et al., 29 Sep 2025).

4. Empirical profile and representation trade-offs

The evaluation compares the proposed JSON-based representation against direct XML generation and editing across eight models: GPT-4o mini, GPT-4o, o3-mini, Claude 3.5 Sonnet, Gemini 2.0 Flash, Llama 3.3 70B Instruct, Qwen 2.5 72B Instruct, and Deepseek V3. Generation is evaluated on 60 BPMN generation tasks using Graph Edit Distance, Relative Graph Edit Distance, and a derived similarity score. Editing is evaluated on 40 diverse editing tasks using a binary success metric requiring both syntactic validity and correct application of the requested modification (Licardo et al., 29 Sep 2025).

The generation results show that JSON and XML are close in structural quality, but not in robustness. Average similarity is 0.70 for JSON vs. 0.69 for XML, with 2 JSON failures vs. 12 XML failures. Mean generation latency is 14.41 s for JSON and 24.07 s for XML; average output length is 849.29 tokens for JSON and 1834.55 for XML (Licardo et al., 29 Sep 2025). This indicates that the JSON representation does not dramatically improve generation similarity, but it does reduce failure frequency and output length.

Editing is where the representation change is most consequential. JSON beats XML for every model on editing success. Illustrative model-level comparisons include GPT-4o mini: 0.45 vs. 0.05, GPT-4o: 0.55 vs. 0.30, o3-mini: 0.65 vs. 0.53, Claude 3.5 Sonnet: 0.68 vs. 0.65, and Deepseek V3: 0.50 vs. 0.08 (Licardo et al., 29 Sep 2025). Average editing latency is 21.46 s for JSON and 46.98 s for XML. Average output length is 364.14 tokens for JSON and 2,665.32 for XML, although JSON requires much more prompt context on the input side: 19,567.70 tokens on average versus 5,102.74 for XML (Licardo et al., 29 Sep 2025).

Two models are identified as the strongest overall performers: Claude 3.5 Sonnet and o3-mini. Claude 3.5 Sonnet achieves generation similarity 0.72 for both JSON and XML, and editing success 0.68 JSON / 0.65 XML. o3-mini achieves generation similarity 0.72 JSON / 0.69 XML and editing success 0.65 JSON / 0.53 XML (Licardo et al., 29 Sep 2025).

These results support a specific trade-off. JSON incurs larger input prompts, but it reduces malformed outputs, shortens responses, lowers latency, and substantially improves editability. A second misconception follows from this evidence: JSON is not introduced because it yields radically better structural similarity during generation. It is introduced because direct XML handling is fragile, verbose, and operationally brittle for model modification (Licardo et al., 29 Sep 2025).

The evaluation is also limited in ways that materially affect interpretation. The supported BPMN subset is narrow; there is no semantic evaluation such as Petri-net-based reasoning or process-mining validation; edit correctness partly relies on manual review; and layout generation is constrained by bpmn-auto-layout, especially for multi-pool and multi-lane diagrams (Licardo et al., 29 Sep 2025).

5. Adjacent assistant functions in current research

Related work shows that BPMN Assistant belongs to a larger technical family of BPMN-support systems. One major branch concerns interactive verification. BPMN Analyzer 2.0 is a BPMN-specific, explicit-state model checker integrated into a modeling environment. It performs breadth-first state-space exploration, checks soundness and safeness on the fly, detects deadlocks, livelocks, starvation, dead activities, and lack of synchronization, and localizes findings directly in the diagram. It also provides interactive token-based witness traces and pattern-based quick fixes. The operative target for “instantaneous” analysis is 500 ms or less, and on eight realistic models the reported runtime is 1–10 ms; however, runtime grows exponentially with high parallelism and exceeds the threshold around 17 parallel branches of length 1, where it reaches 790 ms (Kräuter et al., 2024).

A second branch concerns diagram ingestion when native .bpmn files are unavailable. “Structured Extraction from Business Process Diagrams Using Vision-LLMs” defines an image-to-JSON pipeline using a Vision-LLM and optional OCR enrichment, formalized as $f_\theta : (I, P, T) \mapsto R$, followed by JSON parsing and label enrichment (Deka et al., 27 Nov 2025). The method recovers useful structured inventories from images, but graph reconstruction remains difficult. In strict evaluation, GPT-4.1-mini reaches F1 = 0.817 on name-only extraction and F1 = 0.715 on name+type, whereas the best strict relation+type result is GPT-4.1 at 0.475 (Deka et al., 27 Nov 2025). This suggests that image-based assistants are already useful for indexing, retrieval, and draft reconstruction, but not yet reliable substitutes for execution-grade BPMN XML.

A third branch concerns collaboration-aware generation from text. “Beyond Control-Flow: Integrating the Resource Perspective into Multi-Collaborative Process Modeling from Text” introduces a resource-aware pipeline that produces BPMN 2.0 collaboration diagrams from natural-language descriptions. It uses a compact intermediate language in which every visible activity has mandatory organizational assignments, formalized by $\Lambda$ mapping visible transitions to a pool-lane context, and rewrites cross-organization dependencies into message-based interactions (Antonov et al., 23 May 2026). On ten business processes with nine LLMs, adding the resource perspective does not significantly degrade control-flow quality; all reported $p$-values are greater than 0.05 (Antonov et al., 23 May 2026). This suggests a direct path for extending BPMN Assistant beyond single-process control flow into pool- and lane-aware collaboration modeling.

A fourth branch concerns semantic enrichment. “A framework to semantify BPMN models using DEMO business transaction pattern” argues that many BPMN models encode only the happy flow and omit decline, rejection, and revocation semantics. It provides a BPMN pattern covering happy flow, declinations, rejections, and revocations without adding new BPMN constructs, and reports on two industrial proof-of-concepts that uncovered large amounts of implicit behavior. In the first proof-of-concept, 25 out of 56 situations were implemented, of which 6 out of 56 were explicit and 19 out of 56 were implicit; in the second, 24 out of 56 were implemented, with 7 out of 56 explicit and 17 out of 56 implicit (Guerreiro et al., 2020). This line of work indicates that an assistant concerned only with syntactic generation may still produce semantically incomplete process models.

A fifth branch concerns implementation binding. “Towards ontology based BPMN Implementation” proposes a framework that starts from BPMN design XML, extracts task descriptions, uses POS tagging and JAPE rules to extract verbs and noun phrases, performs ontology-based semantic matching, and selects or composes web services. Its QoS selection formula is given as $Qos = a - n$, where $a$ is availability and $n$ is total number of calls, although the paper’s own discussion indicates that average response time is also used in tie-breaking (Chhun et al., 2018). The proposal is not an end-to-end BPMN authoring assistant, but it identifies a still-relevant subproblem: semantic binding of tasks to executable services.

6. Limits, misconceptions, and future directions

Several misconceptions about BPMN assistants recur in the literature. One is that natural-language modeling implies unrestricted BPMN coverage. The evidence instead shows that current assistants generally operate over restricted subsets. BPMN Assistant supports only tasks, user tasks, service tasks, exclusive gateways, parallel gateways, start events, and end events (Licardo et al., 29 Sep 2025). Resource-aware collaboration generation likewise targets a limited BPMN collaboration subset, with message events materializing cross-pool dependencies (Antonov et al., 23 May 2026).

A second misconception is that validation and explainability are secondary features. Current research points in the opposite direction. The strongest BPMN-assistance architectures combine generation or editing with immediate verification, localized diagnostics, witness traces, and fix suggestions. This triad—generation or modification, executable explanation, and repair—appears repeatedly in the BPMN Analyzer work and suggests that future assistants will be judged not only by what they can draft, but also by what they can justify and correct (Kräuter et al., 2024).

A third misconception is that semantically rich BPMN can be derived from surface syntax alone. Semantification research shows that many process models omit essential interaction outcomes, while ontology-based implementation work shows that even well-formed task structures still require semantic grounding to become executable (Guerreiro et al., 2020, Chhun et al., 2018). A plausible implication is that BPMN assistants will increasingly need layered semantics: structural control flow, organizational assignment, decision logic, interaction semantics, and implementation binding.

The forward-looking agenda is therefore already visible. Core directions proposed in the BPMN Assistant paper include expanding supported BPMN elements, incorporating semantic evaluation such as Petri-net-based analysis, conducting usability and HCI studies, optimizing for specific LLMs, and improving prompt engineering (Licardo et al., 29 Sep 2025). Adjacent work adds further trajectories: richer fix ranking and broader BPMN-element support in live verification (Kräuter et al., 2024), conversion of BPMN images into executable XML in multimodal extraction (Deka et al., 27 Nov 2025), and integration of the resource perspective into natural-language collaboration modeling (Antonov et al., 23 May 2026). Taken together, these strands indicate that BPMN Assistant is best understood not as a single prompt-driven generator, but as an emerging class of structured BPMN systems in which natural-language interaction, intermediate representations, deterministic compilation, validation, semantic enrichment, and execution-oriented tooling are progressively converging.