Formal Verification of Business Constraints in Workflow-Based Applications

Abstract

Workflows coordinate a series of computing tasks to create a sophisticated workflow logic. Ensuring the correctness of a workflow specification is essential for automating business processes. Errors in the specification should be identified and resolved as early as possible, during the design phase. In this paper, we propose a verification approach for workflow specifications utilizing model checking techniques. We introduce a method for verifying the correctness properties of workflow processes by utilizing our database-embedded Alternating-time Temporal Logic (ATL) model checker. First, the workflow specification is translated into a concurrent game structure (CGS). Next, the desired property is expressed as an ATL formula. Finally, the ATL model checker is executed to verify whether the correctness properties hold for the model. To support users in the formalization of business constraints, the proposed solution implements an assistant based on generative AI. The experimental results show that employing the chain-of-thought prompting method significantly enhances the reasoning process performance when using the GPT-4o model.

1. Introduction

In today’s dynamic economic environment, success is defined by the ability to respond quickly, adapt flexibly, and drive innovation in a diverse and ever-evolving market. The growing emphasis on efficiency in companies necessitates continuous improvement of their organizational processes. This has resulted in the need to formally represent these processes, commonly known as workflows, and has led to the development of various workflow languages and workflow engines [1]. Workflow-based applications enable organizations to standardize, automate, and optimize their processes, leading to enhanced productivity and a more organized work environment. The architecture of workflow-based systems benefits from distinguishing between a set of computing tasks and the workflow that coordinates them [2].

Typically, in addition to a “start” state and an “end” state, a workflow consists of two types of components: tasks, where the main computing functions are executed, and control stages, which include elements like “choice”, “fork”, “join”, and “wait” [2].

Most workflow engines employ graphical notations to model business processes or outline the procedural logic of software [3]. The main goal of using a graphical language is to provide a readily understandable notation for all its users [4]. However, the absence of precise semantics for the modeling entities hinders rigorous analysis and reasoning of the resulting models. The lack of standard semantics can lead to system crashes or failure to meet desired properties.

Business processes are ubiquitous, ranging from simple approval workflows to more complex, cross-organizational processes, particularly in the context of digital process automation (DPA). DPA aims to automate or partially automate tasks within various business practices that usually involve human interaction [5]. Low-code platforms are often used to enhance DPA efforts, enabling users to build and automate workflows using visual interfaces and drag-and-drop functionality. Low-code platforms are highly beneficial for accelerating DPA and simplifying the integration of different systems, allowing businesses to quickly adapt to changing needs by modifying or extending processes without extensive redevelopment. To demonstrate the applicability of our approach, we applied it to a continuously evolving DPA solution that is fully integrated into the Oracle APEX low-code platform and is based on APEX workflows (AWs).

AWs are not based on Business Process Modeling Notation (BPMN) 2.0 but offers a simple and intuitive solution to implement process automation.

The run-time behavior of a process should be analyzed prior to execution to ensure its formal verification, demonstrating whether the process model meets critical criteria and preventing improper functioning that could result in costly financial damages [6]. In this paper, we address the issue of verifying AW models using a model-checking-based approach.

Model checking is a technique in computer science used to verify and analyze the properties of finite-state systems, including concurrent and distributed systems. Model checking entails creating a model of the system, specifying the desired properties as formulas in temporal logic, and then using specific algorithms to assess whether the model satisfies these properties.

Verifying a business process involves checking whether it operates as intended and aligns with its designed behavior [7]. Therefore, for business processes modeled by AW, formal semantics for AW models will be provided based on the concurrent game structure (CGS), enabling the formal verification of correctness properties. The properties are expressed as ATL formulas, and for their verification, we will use our ATL model checker, which is embedded within the Oracle database.

The rest of this paper is organized as follows. Section 2 presents related work on formal verification of business processes, presenting the main tools for their modeling, analysis, and verification. Section 3 presents the formal model for APEX workflows and provides background material related to Alternating-time Temporal Logic (ATL). Details are also provided regarding the conversion of business process descriptions into CGSs, along with a description of the proposed method for verifying workflow models using the ATL model checker. A case study is presented in Section 4. Section 5 discusses the implementation aspects of an intelligent assistant designed to support business users in formalizing correctness properties. Finally, Section 6 provides the conclusions and directions for future development.

2. Related Work

The verification issue of workflow specifications has been explored in various contexts. The paper [8] explores methods for formally verifying e-services and workflow systems using automata-based techniques, to ensure that workflows and service compositions adhere to specified requirements, thus helping identify potential errors in their execution and design.

In [9], Davulcu et al. employed concurrent transactional logic to model workflow systems, focusing on the verification of safety properties under specific conditions.

Schroeder et al. [10] discusses a translation of business processes described in the Process Interchange Format into the Calculus of Communicating Systems. This demonstrates how to verify properties such as deadlocks, livelocks, and safety and liveness properties, using examples from work distribution scenarios in Correspondence Handling Centers.

In a study by Corradini et al. [11], a framework for verifying business process models created using BPMN is presented. Specifically, the framework uses Labeled Transition Systems (LTSs) to represent the behavior of BPMN models and Computational Tree Logic (CTL) for checking properties like soundness, allowing the verification of behavioral properties through model checking techniques.

There were several approaches for formalizing workflows (specified in BPMN) by coding in various formalisms such as YAWL [12,13,14], Petri Nets [15,16,17,18,19], and ECATNets [20,21].

Wong and Gibbons [22] address the lack of formal semantics in the Business Process Model and Notation (BPMN), which is designed to facilitate the connection between business process design and implementation. The authors propose formal semantics for a subset of BPMN using Communicating Sequential Processes (CSPs), which allows for a more rigorous analysis and comparison of BPMN diagrams. The paper includes a simple example of a business process to illustrate the proposed semantics.

Corradini et al. [23] describe an Eclipse-based tool designed to facilitate the formal verification of Business Process Model and Notation (BPMN) processes through implementation of a mapping from BPMN to the CSP formal language. The Eclipse plug-in is used in [24,25], where the authors highlight its application in the field of e-government to improve the provision of services to citizens.

The approach of Mangi et al. [26] involves mapping business process models to finite-state machines, specifically Kripke structures. In a paper by Regis et al. [1], the Labeled Transition System Analyzer is used to encode workflow models as LTSs, and the declarative properties of workflows are formally expressed in Fluent Linear Temporal Logic.

The approach of Lam [27] involves converting BPMN models into the New Symbolic Model Verifier (NuSMV) language to conduct model checking analysis. This transformation facilitates the verification of properties within BPMN processes by leveraging the capabilities of NuSMV for formal verification [28] and requires encoding properties of a model using Computation Tree Logic (CTL) formulas.

In a study by Mendoza [29], a BPMN model is converted into a set of Timed Automata (TA), enabling its verification through Clocked Computation Tree Logic (CCTL). This methodology allows for the analysis of time-dependent behaviors in BPMN processes, facilitating a more rigorous evaluation of their properties. Such transformations leverage the expressiveness of TA and the verification capabilities offered by CCTL, making them suitable for ensuring correctness in time-sensitive business processes. In [30], Watahiki et al. introduced a method that involves mapping an extended BPMN model onto TA, which are then verified using the UPPAAL model checker. The acronym UPPAAL originates from the collaboration between two universities: Uppsala University in Sweden and Aalborg University in Denmark, where the tool was jointly developed.

Nguyen Thanh et al. [31] presents a toolchain designed to formally verify business processes and business rules, assisting users in creating models, verifying them, and reporting results in a user-friendly format, using Colored Petri Nets (CPNs) and model checking techniques. BPMN models of business processes are translated to CPNs and are validated for correctness, adherence to constraints, and logical soundness. The toolchain helps to automatically detect inconsistencies and errors early in the design phase, improving the reliability of business process models.

In [32], Bistarelli et al. introduces a prototype tool designed to discover and classify business processes from event logs by leveraging ontology-based frameworks. The tool utilizes a reference ontology to dynamically classify processes at varying levels of abstraction, enabling detailed analysis of organizational workflows. By doing so, it helps identify strengths and weaknesses in processes, enhancing competitive performance.

The paper [33] by Hlaoui et al. explores techniques to ensure that the semantic integrity of BPMN models is preserved during refinement processes. The authors propose an automatic verification framework that employs formal methods to detect semantic inconsistencies in evolving workflows. The approach is validated through case studies, demonstrating its effectiveness in maintaining the correctness of business process models during iterative improvements.

Lopes and Guerreiro [34] introduced FlowTGE, a framework designed to automate the functional testing of executable BPMN process models. The tool focuses on generating and executing test cases to validate the correctness and functionality of BPMN workflows. It integrates with process execution engines, ensuring that business processes meet their specified requirements efficiently. The approach enhances reliability in automated process testing by bridging the gap between design models and runtime environments.

Some frameworks tend to inefficiently convert business process models into input languages for model checkers, leading to significant overhead in the resulting state space. This inefficiency can arise from complex translation processes that increase the number of states and transitions in the model, making the verification task more resource-intensive and time-consuming. Such overhead can hinder the overall effectiveness of model checking, as larger state spaces are more difficult to analyze and may result in longer verification times [35].

We propose a lightweight algorithm for parsing workflows into CGSs. One advantage of our framework, compared to other encoding-based approaches, is its enhanced effectiveness in verifying AW models. The direct semantics of our framework facilitate formal reasoning about model properties, closely aligning with the representation of AW diagrams. This proximity to the original diagrams allows for a more intuitive verification process, making it easier for practitioners to understand and assess the properties of their models. By eliminating the need for complex encodings, our approach streamlines the verification workflow, leading to more efficient and accurate assessments.

3. Materials and Methods

3.1. A Formal Model for APEX Workflows

Oracle APEX 24.1 is a low-code platform designed for building robust, scalable, and secure applications, ready for deployment in any environment (cloud and on-premises) [36]. An APEX workflow (AW) provides business process automation capabilities for APEX developers; it is created using a visual workflow designer and comprises the graphical components shown in Figure 1.

In the following, we present a formal model for a workflow depicted using an AW diagram composed by flow objects and connecting objects, which are shown in Figure 1.

Flow objects are the primary graphical components used to define the behavior of a workflow. They are categorized into three types: tasks (Human Task, Execute Code, Invoke API, Send E-Mail, and Send Push Notification), switches, and events (Start, Wait, and End). The execution flow is described by connecting objects, which are of three types:

• Uncontrolled flow: this refers to a flow that is not influenced by any conditions and does not pass through a switch.
• Conditional flow: this flow is associated with a condition expression linked to a switch, which is evaluated at runtime to determine whether the flow will be executed.
• Timeout flow: this flow will be used only if a timeout occurs in the execution of the task to which it is connected.

A formal model for a workflow can be defined as follows: AW = (F, C, ∏, π, e_start, E_end, c_π, δ_AW), where:

• F = T ∪ S ∪ E is the set of flow objects, composed by tasks (T), switches (S), and events (E).
• C = C_U ∪ C_C ∪ C_T denotes the set of connecting objects, composed by uncontrolled flows (C_U), conditional flows (C_C), and timeout flows (C_T).
• ∏ denotes the finite set of names of flow objects (F) and connecting objects (C).
• π: F ∪ C → ∏ ∪ {none, timeout} is called the labeling function, defined as follows: for each workflow object o ∈ F ∪ C, π (o) ∈ ∏ is the name of the object o. For a more concise writing of business constraints, we will replace the descriptive name of a flow object with its static ID (from the workflow definition). Uncontrolled flows and timeout flows will be assigned the names none and timeout, respectively.
• e_start is an element of the set of events E, denoting the start event.
• E_end ⊆ E is the set of end events.
• The function c_π: C → ∏ ∪ {none, timeout} assigns to each connecting object from C its condition expression. For simplicity, we will define c_π as restriction of π to C:

c_π = ${\pi }_{|C}$: C → ∏ ∪ {none, timeout}, where

$$c_{\pi }(c)=\left\{\begin{array}{l}none\hspace{0.33em}if\hspace{0.33em}c\in C_U\\ timeout\hspace{0.33em}if\hspace{0.33em}c\in C_T\\ \pi (c)\hspace{0.33em}if\hspace{0.33em}c\in C_C\end{array}\right.$$

The transition function δ_AW(f_o, c_o) associates to each flow object f_o ∈ F and each outgoing connecting object c_o ∈ C, the flow object from F connected to f_o by c_o.

3.2. Alternating-Time Temporal Logic

Alur et al. [37] introduced Alternating-time Temporal Logic (ATL), a temporal logic built on a computational model known as concurrent game structures (CGSs), which is well suited for describing compositions of open systems.

A CGS is defined as a tuple S = <Λ,Q,Γ,γ,M,d,δ> with the following components:

• Λ = {1, …, k} is a nonempty, finite set representing all the agents involved in the system.
• Q is the finite set of states.
• Γ represents the finite set of propositions used to label the states of the model.
• γ: Q → 2^Γ is called the labeling function, defined as follows: for every q∈Q, γ(q) is the set of propositions that are true at state q.
• M denotes the nonempty finite set of moves available in the system.
• The function d:Λ×Q→2^M associates each agent a∈Λ and each state q∈Q with the set of available moves for agent a at state q. In the following, we will use the notation d(a,q) = d_a(q). For ∀q∈Q, a tuple <j₁, …, j_k> such that j_a∈d_a(q) for ∀ a∈Λ represents a move vector at q.
• The transition function δ(q, <j₁,…,j_k>) associates each state q∈Q and each move vector <j₁,…,j_k> at q with the new state to which the system transitions if every player a∈Λ selects the move j_a.

A computation of S is an infinite sequence of states λ = q₀, q₁, … such that q_i+1 is the successor of q_i, for all i ≥ 0. A computation that begins at state q is referred to as a q-computation.

Given a concurrent game structure S and a set of agents A ⊆ Λ, an ATL formula is defined by the following syntax:

f ::= p | ¬ φ | φ₁∨φ₂ | <<A>> ⚪ φ | <<A>> □ φ | <<A>> ◊ φ | <<A>> φ₁ U φ₂

where p∈Γ and ¬ φ, φ₁, φ₂ are well-formed ATL formulas.

A strategy for the player a∈Λ determines for every finite prefix λ of a computation a move for the player a in the last state of λ.

For a game structure S, we write q⊨ϕ to indicate that the formula ϕ is satisfied in the state q of the structure S. For each state q of S, the satisfaction relation ⊨ is defined inductively as follows:

• For p∈ Γ, q⊨ p ⇔ p∈ γ(q).
• q⊨¬ϕ ⇔ q⊭ ϕ.
• q⊨ ϕ₁∨ϕ₂ ⇔ q⊨ ϕ₁ or q⊨ ϕ₂.
• q⊨ <<A>> ⚪ φ ⇔ there exists a strategy for each player in A, such that for each q-computation λ following these strategies, the formula ϕ is satisfied in the successor of q within computation λ (i.e., λ[1] ⊨ ϕ).
• q⊨ <<A>> □ φ ⇔ there exists a strategy for each player in A, such that for each q-computation λ following these strategies, the formula ϕ is satisfied in all states of computation λ (i.e., λ[i] ⊨ ϕ, ∀ i ≥ 0).
• q⊨ <<A>> ◊ φ ⇔ there exists a strategy for each player in A, such that for each q-computation λ following these strategies, the formula ϕ is satisfied in at least one state of computation λ (i.e., ∃ i ≥ 0 such that λ[i] ⊨ ϕ).
• q⊨ <<A>> φ₁ U φ₂ ⇔ there exists a strategy for each player in A, such that for each q-computation λ following these strategies, there exists a position i ≥ 0 such that λ[i] ⊨ ϕ₂, and for all positions 0 ≤ j < i, it follows that λ[j] ⊨ ϕ₁.

ATL path quantifiers define “cooperation modalities” in the form of ⟨⟨A⟩⟩φ, where A represents a set of agents. The ATL formula ⟨⟨A⟩⟩φ expresses that the agents in A can cooperate to guarantee that φ holds, regardless of the actions of other agents (equivalently, A has a winning strategy for φ) [38].

Further details on ATL syntax and semantics can be found in the paper [39], which also describes the implementation of our ATL model checker.

3.3. Formal Verification of APEX Workflows

For a formal workflow model defined in Section 3.1, the equivalent concurrent game structure S = <Λ,Q,Γ,γ,M,d,δ> is defined as follows:

• The system contains one agent, i.e., Λ = {1}.
• The set of states is Q = F.
• The finite set of propositions is defined by Γ = ${\pi }_{|F}(F)$.

• The labeling function γ: Q → 2^Γ is defined through the formula:

$$\gamma (q)={\pi }_{|F}(q)$$

• The nonempty finite set of moves M includes all condition expressions, i.e.,

$$M={\displaystyle \underset{c\in C}{\cup }\hspace{0.17em}{c}_{\pi }(c)}$$

• The alternative moves function d: Λ×Q→2^M is defined by expression $d(1,q)=\underset{c\in C_q}{\cup }{c}_{\pi }(c)\hspace{1em}q\in Q$, where $C_q$ represents the set of connecting objects outgoing from q.
• The transition function δ is defined as follows:

$$\delta (q,<j>)={\delta }_{AW}(q,j)\hspace{1em}\forall q\in Q\hspace{0.17em}\hspace{0.33em}and\hspace{1em}\forall j\in \underset{c\in C_q}{\cup }{c}_{\pi }(c)$$

Verifying that a workflow is correctly designed is crucial to ensuring that it functions as intended, achieves the desired outcomes, and meets the operational requirements of the business. However, verification of a workflow specification is not an easy task for business experts [40]. The primary challenges involve converting the business process description into a format suitable for verification and defining the correctness properties.

In this paper, we present a tool for workflow verification using model checking, a formal verification technique that systematically explores the state space of a system to verify whether it satisfies certain specified properties.

To apply this technique using the ATL model checker, our tool encodes workflow models as CGSs, following the mapping described at the beginning of this section. The encoding will enable us to employ the ATL model checker for verifying correctness properties of business processes specified by workflow diagrams. Our tool allows the user to express properties over a workflow model declaratively, using ATL formulas, and verify these properties in an automated way.

Figure 2 provides a high-level overview of the proposed method.

The process starts with a workflow model created using the APEX Diagram Builder.

The proper definition of the correctness properties is crucial for business experts, as they allow them to verify the following:

(a)

Whether the business processes function as described.

(b)

Whether the described behavior accurately reflects the intended process behavior.

In the most likely scenario, the correctness properties will be informally specified by business users, and the coding of these properties as ATL formulas will be delegated to specialists familiar with ATL concepts. Another possible option is the use of an AI assistant to help business users in constructing ATL formulas, as described in Section 5.

Our approach addresses the primary challenge in verifying business processes—translating them into a formalization that can be automatically verified—by automatically encoding the workflow into a CGS structure. This is achieved using data from the internal tables WWV_FLOW_WORKFLOWS, WWV_FLOW_WORKFLOW_ACTIVITIES, and WWV_FLOW_WORKFLOW_TRANSITIONS.

The verification of correctness properties is performed using the ATL model checker, employing a solution fully integrated within the database. Storing the ATL model in the database significantly enhances the scalability of the ATL model checker tool. Also, our ATL model is implemented as a Java application that runs in the Oracle Database JVM (Java Virtual Machine), which is located within the database. The embedding of the ATL model checker in the database is carried out through the commands shown in

Table 1. Embedding the ATL model checker in the database.

Loading libraries

loadjava -thin -user userName/password@//localhost:1521/freepdb1 -verbose .\antlrworks-1.4.jar .\javax.json.jar .\json.jar

Loading the ATL model checker classes

loadjava -thin -user userName/password@//localhost:1521/freepdb1 -verbose .\ATLLexer.java .\ATLParser.java .\ATLJson.java .\ATLChecker.java

The PL/SQL wrapper to invoke the ATL model checker

CREATE OR REPLACE FUNCTION ATL_CHECKER (model IN CLOB, length IN NUMBER, response IN OUT CLOB) RETURN VARCHAR2 AS LANGUAGE JAVA NAME ‘ATLChecker.checkModel(oracle.sql.CLOB, int, oracle.sql.CLOB[]) return java.lang.String’;

. Further details can be found in [41].

Embedding the ATL model checker into the Oracle database allows seamless integration, enabling efficient verification of ATL models directly within the database environment, without the need to implement a Web service, as in [11]. This enhances performance by reducing data transfer and leveraging the database’s processing power. This approach allows native interaction with APEX applications, because the model checker is invoked through a classic stored procedure call.

The model checker invocation procedure is presented in Figure 3 (the error/exception handling code has been removed, for simplicity).

The source code of the ATL model checker can be downloaded from https://github.com/workflow-atl/ATL (accessed on 22 October 2024).

4. Case Study

In the following, we will employ the formal verification method to analyze the workflows designed to model the business process outlined in Section 4.1.

The correctness of a workflow specification will be verified against business constraints (correctness properties) formally expressed through ATL formulas. Section 4.2 focuses on specifying a business constraint through an ATL formula.

The translation of the workflow definition into an ATL model (CGS) is performed automatically. Details regarding this translation can be found at https://github.com/workflow-atl/ATL/tree/main/workflow (accessed on 22 October 2024).

In Section 4.3, our tool developed in Oracle APEX will be used to determine whether the business constraint is satisfied within the ATL models generated from the workflow specifications.

To illustrate the states of the model where the ATL formula is satisfied, we utilized ATL Designer [39], whose interface allows highlighting these states.

4.1. Analysis and Modeling of Business Logic

We will demonstrate the use of the tool through a simple hypothetical workflow model. The model is adapted from [42] and illustrates the process of scheduling and managing doctor consultations. The business process has been broken down into the following individual steps [42].

The process begins when the patient initiates an appointment with the doctor. A member of the hospital staff logs in to the application, fills in the patient’s details, and submits an appointment request on the patient’s behalf. Next, the doctor’s availability for the requested appointment date/time is checked automatically (via the database API). If the doctor is unavailable, the patient receives a “No appointment” email, and the appointment request is closed. If the doctor is available, an “Approval Task” is raised for the doctor to confirm the appointment request. The process continues with the designated doctor logging in to the application to review the appointment request. If the doctor rejects, a “No appointment” email is sent to the patient, and the appointment request is closed. If the doctor approves, the appointment details are entered into the system with the status “Confirmed”. If the patient has had a previous appointment in the last 7 days, it is considered a follow-up visit, and an invoice with zero payment request is raised for confirmation by the patient (no payment will be required if it is a follow-up consultation). If it is a new visit, an invoice with fees and payment request is raised for confirmation by the patient. In both cases, an email is sent notifying the patient of the appointment confirmation and payment confirmation request. The process continues with the patient logging in to the application to confirm the payment. If the patient does not confirm payment within a certain period (30 min), a “No appointment” email is sent to him/her, and the appointment request is closed. If the patient confirms payment, the appointment status is updated to “Paid” in the records system. Next, it waits for the appointment to be completed, after which a feedback request is sent to the patient. If the patient does not submit the feedback within a specified period (24 h), the appointment request is closed. If the patient submits feedback, a “Thank You” email is sent, and the appointment request is subsequently closed.

Figure 4 shows the workflow proposed in [42] for modeling the business process informally described above. The respective diagram was created using APEX visual workflow designer.

4.2. Formal Verification of Workflow Model

The business process models should be verified to ensure they meet the desired properties. The main goal of our approach is to verify the correctness of the logic within a workflow specification, such as ensuring compliance with specific business constraints.

To verify the specification of a workflow, it is essential to first define the correctness properties to be checked, referred to as “verification goals” [43].

We will consider the following business constraint, highlighted in Section 4.1 in italics: in any scenario, before requesting payment confirmation from the patient, he must be notified by email of the issuance of the invoice. In other words, the workflow should not reach the Payment Confirmation task without first executing Send Invoice Email To Patient.

Without a prior notification, it is very likely that the patient will not confirm the payment within the specified interval, and thus the appointment will be canceled.

In our approach, we need to encode the business constraints as an ATL formula, linking the business semantics to the symbols used in the logical expression of the correctness property. To keep it concise, as mentioned in Section 3.1, we will use the static IDs used in defining the workflow. Thus, SendInvoiceEmail will be used instead of Send Invoice Email To Patient and Payment instead of Payment Confirmation, respectively.

The formula

<<A>> ¬SendInvoiceEmail U Payment

(1)

means that coalition A has a strategy to ensure that SendInvoiceEmail does not occur until Payment happens.

Thus, we have e_start ⊨ <<A>> ¬SendInvoiceEmail U Payment if and only if there exists a strategy such that for each e_start-computation λ following that strategy, there exists a position i ≥ 0 such that λ[i] ⊨ Payment, and for all positions 0 ≤ j < i, it follows that λ[j] ⊨ ¬SendInvoiceEmail.

Therefore, the business constraint verification procedure consists of two steps:

• Step 1:

• Determine the set of states of the ATL model in which Formula (1) is satisfied.

• Step 2:

• If e_start belongs to this set, it means that there is at least one execution scenario in which the Payment state is reached without first going through the SendInvoiceEmail state. In this case, the business constraint is not satisfied.
• If e_start does not belong to this set, the workflow design is correct in relation to this propriety of correctness.

Therefore, the correctness property to be checked is as follows:

e_start ⊭ <<A>> ¬SendInvoiceEmail U Payment

(2)

4.3. Results

Our tool implements the workflow described in Figure 2 for the formal verification of models describing business processes. It allows users to select a workflow model and provides a graphical interface to easily specify and verify the properties of that model. Figure 5 shows the result of the verification of the correctness property (2) for the original workflow shown in Figure 4. It is observed that the correctness property does not hold for the model (the text related to this scenario is displayed in red).

As can be seen in Figure 5, the analyzed workflow is partially displayed in the application window, but the user can view the entire diagram through zooming/scrolling operations.

Figure 6a shows the result of verifying Formula (1) in ATL Designer [39] (within the ATL model generated for the analyzed workflow), the states in which the formula is satisfied being marked with a dark background.

An execution scenario can be seen where the patient is asked to confirm the payment without having been notified in advance about the invoice issuance, which violates the business constraint for which the correctness property (2) was formulated. This scenario is represented by the sequence of states in which the ATL Formula (1) is satisfied. These states define a path that begins from the Start state and ends in the Payment state, without passing through the SendInvoiceEmail state.

According to the workflow model verification process outlined in Figure 2, a review of the workflow design is necessary. Figure 7 presents the updated version of the workflow, for which the correctness property holds. It can be seen that the connecting object between the Update Fees and Payment Confirmation flow objects in the initial workflow shown in Figure 4 has been replaced in the revised version of the workflow shown in Figure 7 with the connecting object between Update Fees and Send Invoice Email To Patient.

The actual behavior of the business process aligns with the specified business constraint: from the starting event, no execution path leads to the payment confirmation task if the invoice notification email has not been sent in advance.

This result can be confirmed in ATL Designer: as shown in Figure 6b, the only state where Formula (1) is satisfied is the Payment state.

In Figure 6, ATL Designer uses the numbering of arcs to associate each arc (connecting object) $c$ with its corresponding move vector $<m>$, where $m=c_{\pi }(c)$ represents the condition expression corresponding to $c$.

To increase the readability of the model, the state corresponding to the start event e_start was labeled Start.

For the model in Figure 6a, which corresponds to the original workflow, the business constraint (2) is not met because Formula (1) is satisfied in the Start state.

In the revised workflow, represented by the model shown in Figure 6b, the business constraint is fulfilled because Formula (1) is not satisfied in the Start state.

Figure 8 presents the verification results for correctness property (2) applied to the revised workflow shown in Figure 7. The results indicate that the correctness property holds for the model, as confirmed by the output message displayed in green. While the workflow is only partially visible in the verification tool’s window, the user can easily navigate the entire diagram.

5. Business User Support Through Generative AI

Verifying a workflow specification can be challenging for business experts who are unfamiliar with ATL concepts. In this section, we explore the extension of the formal workflow verification tool’s functionality by integrating an intelligent assistant. This assistant would handle the task of translating business constraints and correctness properties, informally provided by business users, into formal ATL formulas.

5.1. Standard Prompting

Large pretrained language models (PLMs) have demonstrated remarkable performance across a range of natural language processing tasks, including arithmetic reasoning, commonsense reasoning, and symbolic reasoning [44,45]. Despite these excellent results, PLM models can encounter difficulties in the case of complex reasoning. This behavior was also reported in the case of our implementation, when the standard prompting was used.

The following describes experiments conducted with the GPT-4o model, accessed via the OpenAI API.

Figure 9 shows the answer provided by the intelligent assistant agent to the following question:

“Which is the Alternating-time Temporal Logic (ATL) formula which means that there is an execution path from the beginning that reaches the PaymentConfirmation state without first reaching the SendInvoiceEmailToPatient state?”

The formula proposed by the AI assistant is as follows:

<<A>>◊ (Payment ˄ ¬ (<<A>>◊ SendInvoiceEmail))

(3)

Figure 10a shows the states in which formula ¬ (<<A>>◊ SendInvoiceEmail) is satisfied. Thus, the only state in which formula Payment ˄ ¬ (<<A>>◊ SendInvoiceEmail) is satisfied is the Payment state.

Therefore, Formula (3) is equivalent to the following:

<<A>>◊ Payment

(4)

The states in which Formula (4) is satisfied are marked in Figure 10b. It can be seen that the business constraint is not correctly modeled by the ATL formula proposed by the AI assistant, since this formula is satisfied in the SendInvoiceEmail state.

5.2. Chain-of-Thought Prompting

In [44,45], a simple method is presented for improving the reasoning ability of large language models. In these works, the ability of language models to perform few-shot prompting for reasoning tasks is investigated, using prompts structured as triples: input, chain of thought, and output. A chain of thought (CoT) refers to a series of intermediate natural language reasoning steps that guide the model toward the final output. The authors refer to this method as chain-of-thought prompting, and it has been shown that sufficiently large language models can produce reasoning chains when demonstrations of chain-of-thought reasoning are included in the exemplars for few-shot prompting.

The experimental results presented in [44,45] demonstrated that CoT prompting does not enhance performance in small models and only leads to performance improvements when applied to models with over 100 billion parameters.

In this paper, we used GPT-4o, the latest iteration of the GPT series of language models developed by OpenAI. GPT-4o has over 200 billion parameters and allows customization for specific applications through fine-tuning [46].

A CoT offers an interpretable view into the model’s reasoning process, revealing how it may have arrived at a particular answer and creating opportunities to identify and correct errors in the reasoning path. CoTs improve reasoning and problem-solving performance, breaking down the reasoning process into a series of intermediate steps or thoughts, rather than directly producing an answer. By encouraging the model to explicitly “think” step by step, this approach helps the model to better understand and process the information and to tackle complex tasks that require reasoning.

CoTs are particularly effective in tasks like logical reasoning or answering questions that require making inferences based on multiple pieces of information. Thus, we proposed the evaluation of CoT prompting results for reasoning in the domain of ATL temporal logic semantics.

There are three ways to approach the chain-of-thought prompting technique:

• Basic request: “Can you answer this question using chain-of-thought reasoning?”
• Step-by-step explanation: “Can you explain your thought process step by step for this question?”
• Detailed reasoning: “Please explain your approach using chain-of-thought prompting.”

Figure 11 shows that the GPT-4o model, using CoT prompting, successfully encodes the given business constraint into an ATL formula.

We test chain-of-thought prompting for a related problem of encoding correctness properties in ATL formulas: simplifying ATL formulas into more concise equivalent forms.

Table 2. The answers provided by the intelligent assistant agent, using standard prompting and CoT prompting, respectively.

Standard prompting

Comparison: The first formula adds the additional condition that coalition A has the power to eventually force the payment (i.e., ⟨⟨A⟩⟩◊ Payment). The second formula only ensures that ¬SendInvoiceEmail holds until payment occurs, without saying whether coalition A can force payment. Conclusion: The two formulas are not equivalent. The first formula is stronger because it requires coalition A to have a strategy to eventually bring about the payment, whereas the second formula only ensures that no invoice email is sent until payment occurs, without requiring that A can force payment.

Chain-of-thought prompting

Let us break down the equivalence of the formulas step by step using chain-of-thought reasoning: We are comparing two ATL (Alternating Temporal Logic) formulas: Formula 1: ⟨⟨A⟩⟩ ((⟨A⟩◊ Payment)∧(¬SendInvoiceEmail)) U Payment 2. Formula 2: ⟨⟨A⟩⟩ ¬SendInvoiceEmail U Payment Step 1: Understand Formula 1 Formula 1 is as follows: ⟨⟨A⟩⟩ ((⟨A⟩◊ Payment)∧(¬SendInvoiceEmail)) U Payment ⟨⟨A⟩⟩◊Payment: This means that under assumption A, Payment will eventually happen in the future. (⟨⟨A⟩⟩◊ Payment)∧(¬SendInvoiceEmail): This means that Payment will eventually happen, and SendInvoiceEmail must not occur up until Payment happens. U Payment: This states that the formula holds until Payment happens. Step 2: Understand Formula 2 Formula 2 is as follows: ⟨⟨A⟩⟩ ¬SendInvoiceEmail U Payment This formula simply states that there exists an execution path where SendInvoiceEmail does not happen until Payment happens. Step 3: Compare the Two Formulas In Formula 1, the additional ⟨⟨A⟩⟩◊ Payment condition ensures that Payment will eventually occur. However, this is somewhat redundant because the “until” operator U already implies that the right-hand side of the formula (in this case, Payment) must eventually happen for the formula to hold. This means that Formula 1 is adding an extra condition, but this condition does not change the meaning of the formula. Formula 2 already implies that Payment must happen eventually, as the U operator ensures that the first condition (¬ SendInvoiceEmail) holds until Payment occurs. Therefore, the ⟨⟨A⟩⟩◊ Payment part of Formula 1 does not change the outcome. Step 4: Conclusion The two formulas are equivalent because the additional condition in Formula 1 does not affect the overall meaning. The U operator in both formulas already implies that Payment will eventually occur, and SendInvoiceEmail must not happen before that. Therefore, ⟨⟨A⟩⟩ ((⟨A⟩◊ Payment)∧(¬SendInvoiceEmail)) U Payment is equivalent to ⟨⟨A⟩⟩ ¬SendInvoiceEmail U Payment

presents the answers provided by the intelligent assistant agent to the following question, using standard prompting and CoT prompting, respectively:

“The ATL formula <<A>> ((<<A>>◊ Payment)  ∧ (¬ SendInvoiceEmail)) U Payment is equivalent with formula <<A>> ¬ SendInvoiceEmail U Payment?”

It can be seen that with the standard prompting, the formulated conclusion is incorrect. Using CoT reasoning, the GPT-4o model demonstrated that the two analyzed formulas are equivalent.

Our tests confirm the exceptional results achieved through CoT prompting by large language models [44,45]. As a result, we set the AI assistant to use CoT prompting with detailed reasoning by initializing it with the system prompt option (to avoid activating the CoT prompting on every query).

6. Conclusions

By making business processes transparent and accessible, workflow modeling empowers non-IT users to actively participate in process management, fostering efficiency and innovation across the organization.

A workflow model is based on intuitive symbols and diagrams that make processes easy to understand, even for individuals without technical expertise.

Visual models bridge the communication gap between IT professionals and non-IT users, ensuring everyone has a shared understanding of the business process. Non-IT stakeholders can contribute to the design, review, and optimization of processes without needing technical skills.

Even if non-IT users do not implement automation, understanding how processes are structured allows them to identify areas where automation can be beneficial. They can work with IT teams to prioritize automation projects and communicate business needs effectively.

Formal verification of workflow models is crucial because it ensures that the models are logically sound, error-free, and capable of meeting business goals. Formal verification ensures that workflows follow proper execution paths and that every process execution leads to an intended result, fostering confidence in the workflow’s reliability and assuring stakeholders that business processes are robust, efficient, and ready for implementation.

Catching and fixing errors in the design phase is far less expensive than addressing them after implementation and prevents the deployment of flawed workflows that could result in business losses or operational delays.

Thus, it can be said that formal verification of workflow models is an investment in the quality and resilience of business processes. It not only reduces the risk of failures but also enhances efficiency, compliance, and confidence in process design and execution.

Our study is aimed at both IT specialists involved in implementing business process automation and business users responsible for designing business processes. It also focuses on how these users can leverage components powered by generative AI to define and formally verify business constraints.

APEX is a low-code platform which provides business process automation capabilities within an integrated system that includes the following components: workflow designer, management, and runtime engine. By modeling business processes through workflows, the aim is to automate or partially automate tasks typically requiring human interaction within various business practices.

Verifying a workflow specification for hidden flaws and errors can be a challenging task. Testing and simulation can help build confidence in the implementation of a software system, but they do not guarantee that all important contingencies will be explored, nor can they prove that all bugs have been detected [40]. Model checking, on the other hand, is a mature technology that provides a formal approach for the effective and efficient verification of business process models.

In our approach, the verification process is handled by the ATL model checker, through a translation of an APEX workflow specification to a CGS.

Thus, users will be able to declaratively express the correctness properties of the verified workflows, using ATL formulas. The model checker can evaluate the entire state space against these criteria, providing output that either identifies potential violations of business constraints or confirms that the model is robust with respect to the verified property.

The main focus of this paper is to present a solution that addresses the key challenges in verifying business processes, namely the translation of a workflow model into a formal representation that can be automatically verified, and the specification of correctness properties. Thus, the proposed APEX extension consists of three components:

• An ATL model checker, encapsulated in the database for native calling (as a stored procedure).
• A parser to automatically translate the workflow model into an equivalent CGS.
• An AI assistant based on the GPT-4o model, designed to utilize chain-of-thought reasoning, to provide support in translating informal business constraints into ATL formulas.

A case study was conducted to illustrate the specifics of our implementation and to offer a clear explanation and demonstration of the efficiency and effectiveness of a model checker in the verification of business processes.

A limitation of our solution is that it is tailored specifically for APEX workflows. However, the most complex component (the ATL model checker) can be accessed as a Web service or included in Java applications [39] and therefore can be easily integrated into custom projects.

As a future extension of the tool, we are working on incorporating feedback from the model checker in the event of business constraint violations.

We are exploring the possibility of displaying a graphical representation of the sequence of events or tasks that leads to a property violation directly within the workflow diagram.