Source-linked AI summary

BPMN Assistant: An LLM-Based Approach to Business Process Modeling

Josip Tomo Licardo, Nikola Tankovic, Darko Etinger

arXiv:2509.24592v2cs.AIcs.SE

TL;DR

BPMN’s complexity makes creation and modification challenging, while iterative editing remains relatively unexplored. BPMN Assistant uses a JSON intermediate representation for atomic edits; it matched or outperformed XML editing across tested models and reduced latency by approximately 43%.

  • Problem

    BPMN’s complexity challenges users, and modification and maintenance of existing diagrams remain largely unexplored.

    Source: §1 · pp. 1–2
  • Method

    BPMN Assistant represents BPMN models in JSON and treats editing as incremental transformation through constrained, atomic operations.

    Source: §1 · p. 2
  • Results

    The JSON approach outperformed or matched XML across tested models in editing, with editing latency reduced by approximately 43%.

    Source: §7 · p. 17
  • Takeaways & Limitations

    The structured approach enabled DeepSeek V3 to achieve a viable 50% editing success rate compared with 8% using standard XML prompting.

    Source: §7 · p. 17

    The evaluation does not establish whether generated models correctly integrate business logic because semantic evaluation was not conducted.

    Source: §6 · p. 16

Abstract

from arXiv · show

This paper presents BPMN Assistant, a tool that leverages Large Language Models for natural language-based creation and editing of BPMN diagrams. While direct XML generation is common, it is verbose, slow, and prone to syntax errors during complex modifications. We introduce a specialized JSON-based intermediate representation designed to facilitate atomic editing operations through function calling. We evaluate our approach against direct XML manipulation using a suite of state-of-the-art models, including GPT-5.1, Claude 4.5 Sonnet, and DeepSeek V3. Results demonstrate that the JSON-based approach significantly outperforms direct XML in editing tasks, achieving higher or equivalent success rates across all evaluated models. Furthermore, despite requiring more input context, our approach reduces generation latency by approximately 43% and output token count by over 75%, offering a more reliable and responsive solution for interactive process modeling.

1 Introduction

BPMN’s complexity, the gap between business language and formal models, and frequent process changes make effective modeling and maintenance difficult. BPMN Assistant frames editing as incremental transformation and proposes a structured JSON representation for controlled modifications.

1 Introduction

  • BPMN’s complexity and the expertise required to create, interpret, and edit diagrams can impede adoption, increase reliance on experts, and delay decisions.The paper notes that many users lack formal BPMN training.Source: §1 · p. 1
  • Communication gaps between IT and business stakeholders, alongside process knowledge dispersed across experts and informal documents, hinder requirements alignment and formalization.The cited review reports misunderstandings and implementation delays despite alignment initiatives.Source: §1 · pp. 1–2
  • Earlier text-to-process methods relied largely on ad-hoc rules and struggled with complex sentence structures, domain terminology, ambiguity, and varied language.Prior NLP work also faced challenges with semantic ambiguity and contextual understanding.Source: §1 · pp. 1–2
  • Frequent process changes and persistent quality issues in industry BPMN models underscore the difficulty of keeping formal documentation aligned with operations.An analysis of 585 industry models found quality issues involving splits and joins, message flows, and model decomposition.Source: §1 · p. 2

1.2 Contribution

  • BPMN Assistant treats diagrams as mutable structures and proposes a JSON intermediate representation for atomic logical edits rather than regenerating entire XML models.The contribution also reports improvements in editing success, latency, and output-token costs.Source: §1 · p. 2, §1.2 · p. 3

1.1 Research Objectives

  • The study asks whether JSON improves reliability and editing success over XML, whether function-based editing helps open-weights models, and how context affects latency and efficiency.These are the paper’s three research questions.Source: §1.1 · pp. 2–3

2 Related Work

Prior work spans process extraction, LLM-based interactive modeling, and automated generation, with varied methods and evaluation measures. BPMN Assistant focuses on fine-grained editing reliability and efficiency, complementing work centered on model quality and human-centered outcomes.

2.1 Process Extraction and Prompting Strategies

  • Process-extraction research ranges from mapping rules to universal LLM prompting, while prompt engineering offers an approach for BPM tasks with limited data.Reported examples include 91.92% accuracy for one rule-based prototype and up to an 8% F1-score gain for an LLM strategy over traditional machine learning.Source: §2.1 · p. 3

2.2 Interactive Modeling Tools

  • Interactive tools include ProMoAI’s constrained-code workflow and BPMN-Chatbot’s text or voice interface, but the latter’s evaluation did not isolate iterative-edit robustness.BPMN-Chatbot reported up to 94% lower token usage and 95% correctness; its iterative feedback loop was not evaluated beyond a preliminary acceptance test.Source: §2.2 · pp. 3–4
  • BPMNGen evaluated semantic alignment, cognitive load, acceptability, and comprehension, finding expert intervention beneficial for highly complex scenarios.Its results indicate LLM-generated models can reach expert-level semantic quality for simple and moderately complex processes.Source: §2.2 · p. 4
  • BPMN Assistant instead targets structural correctness, editing reliability, latency, and token efficiency, complementing BPMNGen’s human-centered quality evaluation.The paper positions incremental manipulation and validation as engineering concerns distinct from model comprehensibility.Source: §2.2 · p. 4

2.3 Automated Generation and Evaluation Frameworks

  • Bellan et al. [29] found substantial variation across ten process-extraction methods, with no single approach superior across evaluation metrics; Nivon et al. built BPMN processes by converting an abstract syntax tree (AST).A Java-based implementation using fine-tuned GPT-3.5 achieved 78.5% accuracy for valid BPMN processes across 200 descriptions.Source: §2.3 · p. 4

3 System Architecture

BPMN Assistant separates process semantics, editing logic, and BPMN serialization across a backend, layout server, and frontend. Its flow turns natural-language requests into structured JSON, then BPMN XML for visualization.

3 System Architecture

  • The architecture separates process semantics, editing logic, and BPMN serialization across a Python backend, layout server, and Vue.js frontend.Figure 1 presents both the component architecture and the request sequence.Source: §3 · p. 4, Figure 1 · p. 5

3.1 Backend

  • The Python backend distinguishes conversational from modeling requests, converts JSON models to BPMN XML, and accepts uploads within its supported BPMN subset.It integrates LLMs from multiple providers, whose capabilities are summarized in Table 2.Source: §3.1 · p. 6, Table 2 · p. 6

3.2 BPMN Layout Server

  • The layout server adds graphical coordinates to BPMN XML, but the current library limits its processing of multi-pool or multi-lane diagrams.It exchanges data with the backend through REST APIs.Source: §3.2 · p. 7

3.3 Frontend

  • The dual-panel frontend pairs natural-language chat and model selection with a BPMN canvas for viewing and interacting with generated or modified diagrams.Users receive progress messages and can download completed diagrams.Source: §3.3 · p. 7, Figure 2 · p. 7

3.4 Data Flow

  • A request passes from the frontend to backend intent recognition, then through LLM-generated JSON, BPMN XML conversion, layout enrichment, and frontend visualization.The layout server calculates element coordinates before the enriched XML returns to the frontend.Source: §3.4 · p. 8

3.5 JSON Representation of BPMN Diagrams

  • The hierarchical JSON representation abstracts BPMN XML syntax while representing sequential flow and gateway branching for LLM reasoning.Parallel branches are arrays of paths with implicit synchronization when the parent flow continues; has_join signals a merge, and next supports loop-backs to existing elements.Source: §3.5 · pp. 8–9

3.6 Process Editing Functions

  • Specialized editing functions let the LLM select operations for requested changes, decompose complex edits into atomic steps, and preserve process integrity.For example, deleting an element reconnects surrounding elements to maintain continuity.Source: §3.6 · pp. 9–10

3.7 Validation and Soundness

  • A Python validation layer checks identifiers, connectivity, gateway hierarchies, and start-event counts before XML conversion, returning violations to the LLM for correction.Each process must contain exactly one start event.Source: §3.7 · p. 10

4 Evaluation

The evaluation compares JSON-based BPMN representation with direct XML generation and editing using graph-similarity measures, a 60-task generation dataset, and 40 editing requests. JSON achieved higher editing success across models, while generation similarity was similar and JSON generation and editing used less time and output text.

4 Evaluation

  • The evaluation targets structural and syntactic similarity, not semantic evaluation, simulated execution performance, or comprehensive usability.GED and RGED are used as proxies for structural fidelity and logical correctness, but do not capture readability, layout simplicity, or cognitive load.Source: §4 · p. 10, §4.2 · p. 11

4.1 Dataset Composition

  • The dataset contains 60 process descriptions across 20 business domains, covering sequential tasks, XOR decisions, and AND concurrency.Descriptions were generated with a fixed prompt template using gpt-4.1 and constrained to 7–8 activities; annotators created and reviewed ground-truth diagrams.Source: §4.1 · p. 10

4.2 Graph Edit Distance (GED) and Relative Graph Edit Distance (RGED)

  • GED measures minimum graph-edit operations to transform one BPMN diagram into another; semantic label normalization prevents surface wording differences from affecting logical-flow scoring.RGED normalizes GED by graph complexity to make the metric independent of diagram size; its similarity score ranges from 1.0 for semantically identical structure to 0.0 for total dissimilarity.Source: §4.2 · p. 11
  • The GED cost configuration distinguishes minor syntactic errors from major structural hallucinations, with a partial penalty for matching labels assigned to different node types.The substitution cost is 0.0 for matching labels and types, 0.5 for matching labels but different types, and 1.0 otherwise; insertions and deletions cost 1.0.Source: §4.2 · p. 11

4.3 Comparison with Baseline XML Editing

  • The XML baseline directly prompts models for valid BPMN 2.0 XML, while the comparison evaluates representative modification tasks using RGED and derived similarity.The baseline serves as a proxy for conversational refinement workflows that regenerate a structured representation from the current model state.Source: §4.3 · pp. 11–12

4.4 Generation Accuracy

  • JSON averaged a 0.72 similarity score versus 0.70 for direct XML generation, with fewer total failures across models.The paper characterizes the similarity difference as minimal, with both approaches performing similarly in structural accuracy.Source: Table 5 · p. 12, §4.4 · p. 12

4.5 Editing Capabilities

  • Models consistently achieved higher editing success with JSON than direct XML manipulation, including DeepSeek V3 at 50% with JSON versus 8% with XML.The comparison used 40 manually curated modification requests and binary success/fail assessment.Source: §4.5 · p. 13
  • Editing with JSON reduced latency by nearly 43% (20.35s vs 35.63s) and output tokens by over 75% (607 vs 2,630), despite higher input context.Average input tokens were 22,071 for JSON and 5,149 for XML.Source: §4.5 · p. 13

5 Discussion

The discussion argues that structured LLM interaction makes BPMN manipulation more reliable and controllable, while examining editing performance, efficiency trade-offs, and differences from prior approaches.

5 Discussion

  • The discussion presents structured representations as supporting more reliable and controllable BPMN model manipulation.This is described as empirical validation of the work’s initial conceptual assumption.Source: §5 · p. 13

5.1 The Efficacy of Structured Representations (RQ1)

  • 0.73 with JSON vs 0.70 with XML for GPT-5.1 shows only a marginal generation difference.The discussion says modern LLMs can manage XML syntax when generating simple models from scratch.Source: §5.1 · p. 15
  • JSON editing achieved consistently higher success rates across models than direct XML editing.Table 7 covers 40 diverse editing tasks; Figure 5 compares editing success rates.Source: Table 7 · p. 14, §5.1 · p. 15, Figure 5 · p. 15

5.2 Democratizing Process Modeling (RQ2)

  • DeepSeek V3’s editing success rose from 8% with XML to 50% with JSON function calling.Claude 4.5 Sonnet achieved 85% with XML editing.Source: §5.2 · p. 15

5.3 Efficiency and Latency Trade-offs (RQ3)

  • The JSON workflow requires about 4× more input tokens but reduced total latency by 43% (20.35s vs 35.63s) and output tokens by 75%.The discussion attributes the trade-off to moving complexity into input context and restricting output to concise function calls.Source: Figure 4 · p. 14, §5.3 · p. 16

5.4 Comparison with Existing Approaches

  • Unlike BPMN-Chatbot and ProMoAI, BPMN Assistant uses atomic function calls for targeted updates rather than conversational regeneration of the full process.The comparison characterizes the dedicated intermediate layer as avoiding the overhead or instability of regenerating the entire state for minor edits.Source: §5.4 · p. 16

6 Limitations and Future Work

The paper identifies limits in supported BPMN constructs, evaluation scope, model dependence, and validation with users and ambiguous inputs.

6 Limitations and Future Work

  • Collaboration diagrams with pools and lanes and data objects are unsupported, restricting multi-participant modeling scenarios.The paper says this omission does not affect its primary focus on executable process orchestration.Source: §6 · p. 16
  • Without semantic evaluation, the results remain experimental; correct integration of business logic into generated models is not guaranteed.The authors identify this as relevant to practical applicability in real-world scenarios.Source: §6 · p. 16
  • Performance depends heavily on the underlying LLM, with significant variation across evaluated models.The paper reports particularly strong results for Claude 4.5 Sonnet and GPT-5.1.Source: §6 · p. 16
  • Usability for non-technical users remains unvalidated and would require comprehensive HCI studies.The paper frames lower barriers through natural-language interaction as an aim requiring validation.Source: §6 · p. 16
  • The approach relies on clear, unambiguous natural-language input, which may be difficult in multilingual or context-specific scenarios.Language and terminology nuances may introduce ambiguity in those settings.Source: §6 · p. 16
  • The study excludes semantic evaluation, conformance checking, simulation-based performance analysis, and comprehensive usability evaluation.Future work could add these evaluations, expand supported BPMN elements, and optimize the system for specific LLMs.Source: §6 · pp. 16–17

7 Conclusion

The conclusion reports that JSON-based editing improves reliability and efficiency over direct XML, especially for iterative modifications, while identifying usability studies and schema improvements as future work.

7 Conclusion

  • BPMN Assistant uses LLMs and a simplified JSON structure to connect natural-language descriptions with formal BPMN representations.The evaluation included GPT-5.1, Claude 4.5 Sonnet, and DeepSeek V3.Source: §7 · p. 17
  • JSON matched or outperformed direct XML across tested models in editing, with DeepSeek V3 reaching 50% success versus 8% with XML.The conclusion says XML remains feasible for simple models from scratch but is often insufficient for iterative modification.Source: §7 · p. 17
  • Editing latency fell by approximately 43% and output token usage by over 75%.The conclusion links these efficiency gains to practical adoption in interactive, real-time environments.Source: §7 · p. 17
  • Future work will study usability with non-technical business users and improve schema handling of cyclic dependencies and ambiguous language.The paper also plans to optimize robustness for highly ambiguous natural-language descriptions.Source: §7 · p. 17

A Appendix: Process Example

The appendix illustrates JSON representations for cyclic flows and event-driven workflows using natural-language process examples.

Example 1: Cyclic Flow (Loops)

  • A failed exam-score branch returns to the first task through the next attribute, illustrating a non-hierarchical loop.The example’s process description has the student retake the exam after scoring 50% or less.Source: Example 1: Cyclic Flow (Loops) · p. 21

Example 2: Event-Driven Workflow

  • The event-driven example represents a midnight timer start, order processing, a five-minute wait, a notification, and a confirmation wait.It demonstrates Timer and Message event definitions in an executable workflow.Source: Example 2: Event-Driven Workflow · p. 22
Loading 2509.24592v2…