AI-Augmented Business Process Management Systems (ABPMS) extend existing process-aware information systems through the integration of advanced AI capabilities. A core aspect of ABPMSFriasmed Autonomy, denoting the capability of the system to autonomously and independently choose how to progress process executions within the givenProcess Frame, which consists of (potentially conflicting) procedural and declarative process specifications. Moreover, an ABPMS should support the completion of partial process executions, even if they conflict with the Process Frame. In this paper, we demonstrate FrAIm, a What-If Analysis tool that leverages automata theory and automated planning to explore the behavior induced by framed autonomy.
The rise of increasingly complex and capable AI systems facilitates the improvement of traditional software systems through the integration of advanced AI models. In the case of Business Process Management Systems (BPMS), this evolution has led to the definition of a new class of AI-augmented Business Process Management Systems (ABPMS), which are equipped with advanced reasoning capabilities that enable them to autonomously operate within their specified operating domains. Dumas et al. describe the components of ABPMS in their research manifest1o][. The key distinctions of ABPMS are: i) enhancement of the traditional lifecycle phases (model, execute), and ii) addition of novel tasks made possible by AI capabilities (adapt, explain, improve). These tasks are executed within the context of a Process Frame, which represents a generalized notion of a process model. A Process Frame may consist of (arbitrarily many and potentially conflicting) procedural and declarative process specifications, which, in combination, define the overall behavior of the underlying process.
Initializing an ABPMS with a Process Frame is a prerequisite for it to act independently of human
actors. However, its autonomous behavior is only valid as long as it operates within the boundaries
specified by the Process Frame.1 This key feature is referred to aFsramed Autonomy [
In this paper, we introduce FrAIm, a What-If Analysis tool for exploring the behavior induced by framed autonomy in the presence of (potentially conflicting) process specifications within the Process
CEUR
ceur-ws.org
Frame, combined with existing partial process executions that may have violated the Process Frame. More concretely, FrAIm builds on automata-theoretic techniques to compute cost-optimal plans for completing a process execution based on an input Process Frame and a user-defined trace prefix. As such, FrAIm represents an important step toward achieving Framed Autonomy via automated planning.
In the following, Section2 provides a brief background on automated planning, Secti3ondescribes the FrAIm tool’s functionality, Section4 evaluates FrAIm’s performance, and Sectio5nconcludes the paper.
Automated Planning is a branch of Artificial Intelligence that aims to solve complex problems in a
domain-agnostic way. State-of-the-art planners have demonstrated success across a variety of problems
with difering levels of complexity, including successful applications in BPM task3s, 4[
The Planning Domain Definition Language (PDDL) [
In the context of FrAIm, the planning problem is defined by the given Process Frame (expressed as procedural and declarative process models), while the domain consists of actions that allow the planner to navigate the state space of the process. This includes actions for detecting violations and recovering after a violation has occurred. The details of the underlying formal approach are beyond the scope of this paper and can be found in8[].
FrAIm is a Java-based application that combines the strengths of Automated Planning and Hybrid Process Representations to enable interactive exploration of the behavior induced by the ABPMS Process Frame in the presence of diferent partial process executions. The source code of FrAIm is publicly available onli2neT. he tool, along with sample data and a description of how to install the Fast Downward Planning System9[], can be downloadedhere.3 A video demonstration of how to use the tool is providedhere.4
When launched, the user is expected to provide three inputis): procedural models in the form of Petri nets,ii) Declare specifications for the declarative process rules, aniidi) optionally, a prefix trace. The Process Frame is calculated as the union of tDheclare specification and the Petri net, with the implicit goal of reaching the final marking of the net while satisfying all constraints.
It is important to note that these models do not necessarily need to be consistent, as potential violations can be accounted for in the plan (by incurring a cost). The consistency of the Process Frame can be verified in FrAIm by providing an empty prefix and clicking “Run Planner” to generate a trace within the given Process Frame. If the Process Frame is internally consistent, the returned plan will have cost 0; if the trace cost is greater than 0, the Process Frame is not consistent.
The process models are visualized, and the trace (including the given prefix and, if generated, its continuation) can be replayed on the currently selected models using the timeline controls at the bottom of the screen or by clicking on the events on the left-hand side. The visualization of both the selected Petri net andDeclare model is updated during the replay, according to the last processed event of the trace (cf. Figure1). For the Petri net, the visualization tracks transitions that have fired (blue), caused violations (red), are enabled (white), or are not enabled (grey).DFeocrlare, the visualization follows 2https://github.com/giacomo1096/FramedAutonomyTooland https://github.com/pwittlinger/framedinterface 3https://scientificnet-my.sharepoint.com/:u:/g/personal/pwittlinger_unibz_it/EdDfpSBb2UVDta0TLhl6DsYBV_ enMfG3rIWa0yo-qDXbbQ?e=X1c38t 4https://youtu.be/Ty2JsRhHewM the constraint coloring of1[0], with red denoting permanent violations, yellow temporary violations, green temporary satisfactions, and blue permanent satisfacti5ons.
By default, FrAIm will recover from any violations of the Process Frame by resetting the violated element (and incurring a cos6t).However, the user can also choose to discard permanently violated constraints by deselecting the “Recover After Violation” option.
By clicking the “Run Planner” button, FrAIm converts the provided inputs into a planning problem (PDDL format) and passes it to the Fast Downward planner to generate a trace continuation that reaches the final marking of the Petri net while satisfying alDleclare constraints with minimal overall cost. The FrAIm tool then guides the user through the solution step-by-step, highlighting all fired/violated transitions and constraint states after each executed activity. The user can also replay the same trace on any other model by selecting it in the interface, thereby facilitating comparative analysis across multiple models.
Key features of FrAIm include(:i) Declare Visualizer, highlighting satisfied and violated constraints; (ii) Petri net Visualizer, showing the current marking, executed transitions, and violati(oiini)sI;nteractive Trace Builder, allowing users to build the prefix by clicking on the corresponding action inDtehcelare or Petri net visualizer.
These elements can be seen in Figur1e. On the left-hand side, the user can find the currently uploaded process models, a help button, and a button to run the planner. The currently selected models are visualized in the middle of the screenD(eclare model above, Petri net below). More information on the color scheme is available via the two “Help” buttons. The visualizations also allow users to build the trace prefix by clicking on activity names. The right-hand side of the tool displays the trace (consisting of the prefix and, after planning, its continuation). The bottom of the screen contains the trace replay controls. The user can step through the trace one event at a time, jump to a specific event (via the timeline or event list), and replay the trace as an animation.
As additional examples of the FrAIm tool in action, Figu2redepicts two instances of the Process Frame composed of Petri net 1 and the Declare model with seven constraints taken from Tabl1e. Figure 2a has been run with prefix <ActivityC, ActivityA, ActivityE, ActivityC, ActivityB, ActivityF>; Figure2b has been run with an empty prefix. In both cases, the “Recover After Violation” option has 5All temporary satisfactions and violations become permanent at trace termination. 6In the current version of FrAIm, every violation incurs a cost of 3, as specified by the cost model utilized. Alternative cost models (e.g. number of violations) are to be supported in future versions. been ticked. As a result, both plans satisfy aDlleclare constraints and the Petri net. However, we can observe that the Process Frame is not consistent, as an empty prefix leads to a plan with a cost higher than 0. Also, the prefix used in Figure2a contains violations with respect to the Process Frame, as indicated by the associated higher cost.
(a) Plan for a violating prefix trace with cost 39 (b) Plan for an empty prefix with cost 12
We tested the tool in [
In this paper, we presented the core functionality of our planning-based What-If Analysis tool, FrAIm. FrAIm leverages Automated Planning to provide detailed guidance on completing partial process executions within the boundaries of a given Process Frame. The tool ofers insights into the costs of continuing user-defined partial executions by analyzing the interplay between procedural and declarative constraints. By simulating how diferent prefixes evolve under these constraints, FrAIm helps users understand the trade-ofs and implications of various execution paths, particularly regarding violations and recovery costs. The integrated Trace Builder facilitates testing and comparing ABPMS behavior based on diferent prefixes.
The version described in this paper marks the initial release of the tool. Future versions will ofer richer interaction capabilities, including an enhanced Trace Builder for seamless construction and modification of prefixes. Users will also be able to define custom costs for constraint violations, enabling more fine-grained analysis. We also plan to support additional types of constraints, incorporating the data perspective (through data-aware models lMikPe-Declare and Data Petri Nets), as well as temporal aspects (such as throughput time) and resource perspectives, further broadening the tool’s applicability. Moreover, we aim to handle more heterogeneous goals, not only minimizing constraint violations but also optimizing throughput time, outcome quality, and resource costs, while supporting trade-ofs among these competing objectives.
The work of A. Alman and F. M. Maggi was partially funded by the NextGenerationEU FAIR PE0000013 project MAIPM (CUP C63C22000770006). The work of A. Marrella and G. Acitelli was supported by the project FOND-AIBPM, the PRIN 2022 project MOTOWN, and the PNRR MUR project PE0000013-FAIR.
The author(s) have not employed any Generative AI tools.