PlanProjU: A BPMN-to-HDDL HTN Planning Approach for University Project Execution

Abstract

This study aims to automate the generation of execution plans for university projects by transforming BPMN-based process models into hierarchical planning representations that can be executed by HTN planners. Effective implementation of university extension projects requires explicit management of objectives, dependencies, and operational constraints, yet this process is often carried out manually and without formal planning support. To address this problem, the paper proposes PlanProjU, a web-based platform that captures project knowledge through BPMN and translates it into HDDL domain and problem files for execution with SHOP2 and PyHOP. The system was evaluated through real university project cases and a comparative analysis of alternative generated plans. The results show that BPMN-based project knowledge can be operationalized into executable hierarchical planning structures and that different planners may produce distinct plan alternatives depending on project characteristics. The originality of the study lies in the design of a traceable BPMN-to-HDDL workflow for university project planning, implemented in an integrated platform that connects business process modeling with HTN automated planning the originality of the study lies in the design of a traceable BPMN-to-HDDL workflow for university project planning, implemented in an integrated platform that connects business process modeling with HTN automated planning in a domain that has received limited attention in prior research. In this sense, the proposal serves both as an innovative research contribution and as a practical alternative for structuring implementation decisions in institutional settings.

1. Introduction

The design and execution of university projects are commonly carried out following the Project Management Professional (PMP) methodology [1]. However, in the context of official university outreach programs, the PMP methodology is often not fully implemented due to technical and structural limitations in higher education institutions. This gap indicates that having a generic project management methodology is insufficient; instead, there is a pressing need for detailed planning across all project phases.

From an AI perspective, the field of AI planning also known as automated planning provides a well-established computational framework to automate the entire planning process through the generation of executable plans, thereby streamlining the planning process and enhancing efficiency [2,3].

Recent progress in project planning has been driven by significant advances in decision-making, resource allocation, risk analysis, cost-benefit evaluation, and financial assessment techniques [4]. These traditional approaches have consistently proven effective in numerous contexts, yet they remain inherently limited in their ability to facilitate real-time monitoring and the explicit consideration of uncertainty factors that are particularly relevant in university environments. Over the past several decades, research has extensively explored diverse methodologies, mathematical models, and algorithms aimed at enhancing project planning efficiency [5,6]

A contemporary trend emerging alongside the rise of Generative AI is the integration of large language models (LLMs) into project planning. For instance, Herroelen et al. [7] proposed a deep-learning-based task planning system embedded in an LLM to emulate human expert reasoning in task scheduling, demonstrating the ability of LLMs to enhance project planning capabilities. Similarly, Weglarz et al. [8] applied knowledge engineering to design a reasoning framework that, when integrated with an LLM, supports engineering project planning under the SCRUM methodology, further highlighting the benefits of LLMs in project planning. However, despite these advances, most applications remain confined to robotics and software engineering, revealing a significant research gap in the application of LLMs to broader project management domains, underscoring the need for further exploration and development in this area.

The integration of large language models (LLMs) into automated planning has been explored in recent attempts, as surveyed by Zhou et al. (2020) [9]. However, this approach is hindered by fundamental challenges, including hallucinations, which compromise the reliability of reasoning when transitioning from an initial to a goal state. This limitation is further emphasized by the fact that these challenges undermine the effectiveness of LLM-based project planning methods, highlighting the need for alternative approaches. Automated planning techniques, which generate plans using embedded constraints and heuristics, given a domain description and initial/goal states, offer a viable alternative [10,11].

One promising subfield is hierarchical task network (HTN) planning, which decomposes complex tasks into sequences of primitive, executable actions [12,13]. While primitive actions are explicitly defined by preconditions and effects, compound tasks lack such explicit semantics in the most widely used formalism, HDDL the domain description language employed in the International Planning Competition (IPC) in 2020 and 2023 [14,15].

A key challenge in HTN planning is the manual creation of domain models, which demands expert-level knowledge. This process can be supported by structured representations of real-world knowledge, such as the Business Process Model and Notation (BPMN). Rooted in the principles of Frederick Taylor’s scientific management [16], BPMN assumes the existence of an underlying fixed business process (BP) that can be automated and executed by a process management scheduling (PMS) system.

The process of implementing a repeatable business process involves a structured approach that includes three key steps. First, it requires identifying a repeatable business process (BP) a structured abstraction of a real workflow. This step is crucial as it lays the foundation for the subsequent steps. The second step involves formalizing the identified BP into a process model that captures the task execution flows toward a business objective. This process model is often created using the explicit control flow in the Business Process Model and Notation (BPMN), a widely accepted standard for modeling business processes. The use of BPMN enables a clear and unambiguous representation of the process, facilitating effective communication and understanding among stakeholders. The third and final step involves automating the routing of the process via a PMS. The PMS assigns tasks to the appropriate participants, whether human or software agents, ensuring that the process is executed efficiently and effectively. This automation enables a seamless transition from an initial to a goal state, thereby justifying the representation of project management as a BPMN-modeled process.

BPMN offers two distinct advantages for modeling university projects: (1) it provides a graphical, hierarchical representation of cause–effect dependencies, and (2) its XML serialization can be parsed to identify state transitions in each project component. These transitions encode conditional operations for decision flows, yielding sequential and parallel task executions with their respective constraints [17].

Once the BPMN diagram is parsed, two HDDL files are generated: the domain file containing the HTN action model and the problem file defining the initial and goal states of specific university projects. The SHOP2 planner introduced in the 2002 IPC and originally implemented in LISP [18] was then applied. Unlike its predecessor, SHOP2 supports partially ordered subtasks, improving efficiency when operating over simple knowledge bases.

PyHOP is a simple HTN scheduler written in Python, compatible with versions 2.7 through 3.2, and contains fewer than 150 lines of code. Its scheduling algorithm is based on that of SHOP [19], but it avoids the need for a specific scheduling language by having the task network and its methods written in Python, using alternative syntax to logic for defining variables, actions, and methods. PyHOP’s development stemmed from the observation that application developers often wrote their own scheduling systems instead of learning specialized AI scheduling languages [20]. PyHOP was created with the hope of providing an HTN scheduler that would be understandable to people without AI experience. The author of PyHOP did not make much of an effort to promote it, but its ease of understanding and use has made it useful for rapid prototyping, leading to its use in various projects and publications.

Prior work combining automated planning and BPMN for process automation has demonstrated the effectiveness of this approach. Schuschel’s work (2006) [21] is a notable example, as it utilizes classical planning to automate process definitions for adaptive workflows, showcasing the ability to adapt to changing circumstances. Similarly, Nau (1999) [22] successfully integrated knowledge models into temporal classical planners for telecommunications network installation, highlighting the effectiveness of this approach in complex domains. Furthermore, Nau (2013) [23] has addressed the challenges of human knowledge representation by utilizing inductive logic programming to discover action operators in classical planning, underscoring the need for improved knowledge representation in automated planning systems.

However, these contributions are limited to temporal and numeric classical planning without addressing HTN planning, which is a significant gap given the complexity of modern project management. This study addresses three critical gaps: (i) the scarcity of automated execution systems for university projects; (ii) the absence of HTN-based project automation to produce context-adaptive plans for dynamic project management conditions, which can result in inflexible and ineffective planning; and (iii) the lack of project planning systems prioritizing automatic plan generation for university project execution, which can hinder the ability to respond to changing project requirements.

Despite the progress of BPMN-based process modeling and automated planning research, an important gap remains at their intersection in the context of university project execution. Prior studies have explored planning from workflow models, service orchestration, and process automation, but they do not clearly address how BPMN representations of university projects can be transformed into traceable hierarchical planning artifacts that support comparative execution through multiple HTN planners within a user-oriented platform. As a result, university project implementation still lacks a formal mechanism for connecting process modeling, executable plan generation, and comparative planning support in a unified environment.

The study pursues the following research objectives. First, to design a traceable transformation workflow that converts BPMN-based university project models into HDDL representations suitable for hierarchical planning. Second, to implement this workflow in an integrated platform, PlanProjU, capable of generating alternative execution plans through different HTN planners. Third, to evaluate the feasibility and comparative behavior of the resulting planning artifact in real university project cases.

To guide the study, the following research questions were defined:

RQ1. Can BPMN-based university project models be systematically transformed into executable HDDL representations for HTN planning?

RQ2. Does PlanProjU enable the generation and comparison of alternative execution plans for university projects through different HTN planners?

RQ3. How does planner behavior vary across university project cases with different BPMN structural characteristics?

These questions connect the identified research gaps with the objectives of the study and provide the analytical basis for the design and evaluation of the proposed artifact.

Given the design-oriented nature of the study, the research is not framed through formal statistical hypotheses, but through evaluation-oriented propositions.

P1. A BPMN-to-HDDL transformation workflow can operationalize university project knowledge into executable hierarchical planning representations.

P2. An integrated artifact that combines BPMN modeling, transformation, and HTN planner execution can support comparative generation of alternative plans for university project implementation.

P3. Differences in BPMN structural characteristics can influence the comparative behavior of HTN planners in terms of plan cost and number of steps.

In addition, the contribution of this work is not limited to the formulation of an HTN-based planning approach; it also includes the implementation of a modular software artifact that integrates BPMN parsing, HDDL generation, planner execution, and comparative plan analysis within a unified platform. This design gives the proposal practical relevance for university extension offices, were the ability to compare alternative execution plans can support more consistent scheduling decisions and improve the management of inter-task dependencies. The novelty of this study lies in combining BPMN-based project knowledge capture with a traceable HDDL transformation workflow and comparative HTN planner execution in a university project-planning setting, rather than treating process modeling and automated planning as isolated components.

Beyond its application to university project execution, this work is also relevant from an interdisciplinary research perspective. By linking BPMN-based process modeling with HTN planning, the study contributes to the dialogue between business process management and automated planning, showing how structured workflow representations can be operationalized for executable project planning.

In this sense, the study contributes both methodologically and practically: methodologically, by introducing a BPMN-to-HDDL transformation and comparative HTN planning workflow; and practically, by offering a usable alternative for formalizing and supporting the implementation of university projects.

By applying HTN planning in these diverse domains, researchers can identify commonalities and develop more generalizable solutions, ultimately contributing to the advancement of the field. Overall, the integration of AI planning with organizational management represents a crucial step toward bridging the gap between theoretical AI research and practical projects. This integration has the potential to provide a more comprehensive understanding of how AI can be effectively used in other real-world contexts.

The remainder of this paper is organized in a logical and coherent manner, allowing for a clear progression of ideas. Specifically, the structure is as follows: Section 2 provides a comprehensive review of the relevant literature, establishing a foundation for the work presented in this paper. Section 3 outlines the methodology employed in developing PlanProjU, providing a detailed understanding of the approach taken. Section 4 presents the experiments. Section 5 presents the results of this development, allowing for an evaluation of the effectiveness of the methodology. Section 6 engages in a thorough discussion of the findings, highlighting key insights and implications. Finally, Section 7 presents the conclusions and future work.

2. Related Work and Definitions

This section highlights the significance of research that has investigated the integration of automated planning for BPMN process modeling with other applications designed for constructing HTN planning domains and problems. A total of 27 studies were identified and analyzed to characterize the current state of BPMN-related planning research and to position the contribution of PlanProjU within this literature.

Although the reviewed studies demonstrate important advances in process-aware planning, workflow automation, and model-based execution support, they also exhibit recurring limitations. Some focus on generic process automation without addressing university project management as a specific domain. Others use workflow representations for planning but do not provide hierarchical task formulations or traceable transformation mechanisms. In several cases, the proposed approaches are methodologically strong at the formal level but lack integrated user-facing artifacts or comparative planner execution. For this reason, a structured comparison of strengths and weaknesses is necessary to clarify the gap addressed by PlanProjU.

As shown in

Table 1. Summary of strengths and weaknesses of representative studies identified in literature.

Study	Main Focus	Main Strength	Main Weakness	Relation to PlanProjU
Schuschel (2004) [24]	Planning for business process synthesis and repair	Planning can improve flexibility and enable process repair in changing environments	Does not focus on university project planning or hierarchical planning representations	Provides conceptual support for planning-based process adaptation, but not for BPMN-to-HDDL transformation
Moreno (2007) [25]	Intelligent assistant for process execution support	Demonstrates planning-based support for compensation procedures and activity re-execution	Focuses on execution assistance rather than traceable transformation of BPMN models into HTN artifacts	Related to adaptive execution, but not to hierarchical model compilation
Da Silva et al. (2017) [26]	Planning integrated with process execution and refinement	Highlights the relevance of plan patching and repair for process flexibility	Does not provide a BPMN-to-HTN transformation workflow or a planner-comparison platform	Supports the value of planning for process refinement, but not the specific artifact proposed here
Reijers (2016) [27]	Web service composition with domain-independent planning	Planning can generate compositions at the knowledge level	Mostly oriented to web services rather than institutional project workflows; limited emphasis on BPMN traceability	Relevant as planning background, but outside the university project domain
Marella (2019) [28] and La Rosa et al. (2017) [29]	Customized planning for service orchestration	Shows the versatility of planning techniques for orchestration from planning-like descriptions	Relies on service-oriented composition rather than BPMN-driven hierarchical project planning	Demonstrates orchestration potential, but not BPMN-to-HDDL transformation
McDermott (2002) [30]	Symbolic search in complex process modeling scenarios	Highlights the need to partition action models in complex planning scenarios	Does not address hierarchical BPMN-based project planning or user-oriented planning artifacts	Relevant for complexity considerations, but not for the transformation pipeline proposed here
Sheshagiri (2003) [31]	HDDL development framework	Addresses the practical difficulty of building HDDL models and frameworks for hierarchical planning	Focuses on development support rather than BPMN-based semantic extraction in a specific application domain	Strongly related on the representation side, but does not target BPMN-based university project planning
Peer (2005) [32]	AI planning for process control flows	Provides a useful perspective on AI planning for process-oriented control flows	Does not address implementable university project instantiation or traceable transformation from BPMN	Serves as theoretical background, but lacks the artifact-oriented and domain-specific contribution of PlanProjU
Klusch (2006) [33]	Knowledge-representation frameworks for planning support	Helps experts construct action models and planning structures	Does not explicitly ground organizational objects, resources, and project semantics in BPMN-based process models	Related to model construction, but not to BPMN-driven HTN compilation
Petrick (2004) [34]	Automatic action-model generation from expert knowledge	Contributes to automated generation of planning knowledge	Does not encode organizational knowledge through BPMN-like process representations	Relevant to knowledge acquisition, but not to traceable BPMN-to-HDDL translation
Hoffman (2010) [35]	Promotion of AI planning use across domains through development frameworks	Emphasizes the need to lower the barrier for action-model construction	Does not extend its framework to HTN planning in the way required for this application domain	Highlights a real modeling gap that PlanProjU addresses through BPMN-based HTN generation
Sheila McIlraith (2002) [36]	Model-checking and planning for stateful services	Recognize the importance of behavioral descriptions and non-atomic services	Use temporal logic/model-checking formulations rather than HTN planning	Useful as alternative planning paradigms, but methodologically different from PlanProjU

, prior studies provide valuable foundations in process modeling, workflow execution, and planning-based automation. However, the literature still lacks an integrated approach that combines BPMN-based project modeling, traceable transformation into HDDL, comparative HTN planner execution, and a user-oriented platform specifically designed for university project planning. This gap motivates the development of PlanProjU.

2.1. BPMN and Planning-Based Process Automation

For several decades, the AI community has been actively involved in business process management research, with a significant body of work examining the role of automated planning technologies in process management systems. These systems are designed to manage complex business processes while maintaining robustness, reactivity, and adaptability in response to environmental and tasking changes. One of the initial works addressing this research challenge is reference Reijers (2016) [27], which outlines how planning techniques from the planning community can be utilized to synthesize new business processes and repair previously defined processes that are no longer suitable for a given situation. This highlights the potential of planning techniques to improve business processes’ flexibility and responsiveness. Marella (2019) [28] further investigates the use of an intelligent assistant based on planning techniques, which may suggest compensation procedures or re-execution of activities if anticipated failures occur during process execution. This demonstrates the ability to plan techniques to mitigate potential failures and ensure the smooth operation of business processes. La Rosa et al. (2017) [29] describe how planning can be integrated with process execution and plan refinement and investigate plans patching and plan repair as means to enhance flexibility and responsiveness. This integration of planning with process execution is crucial for ensuring that business processes remain adaptable and responsive to changing circumstances.

2.2. BPMN-to-Planning Approaches in the Literature

The application of planning techniques is also relevant in the field of web service composition, were complex challenges are addressed using planning. Notably, a limited number of studies employ domain-independent planners to generate compositions of atomic web services, demonstrating the effectiveness of planning in this area. Research in [28,29,30,31] has explored the use of planning technologies to achieve service composition at the knowledge level, as seen [34], highlighting the potential of planning to address complex web service composition challenges. Furthermore, studies such as Hoffman [35] have utilized customized planners, including the FF planner, to construct service orchestrations from atomic IT entities described in a planning-like manner, showcasing the versatility of planning techniques in web service composition.

Additionally, combined situation calculus with planning techniques to perform service composition, providing a comprehensive approach to addressing web service composition challenges [34,35], has combined situation calculus with planning techniques to perform service composition, providing a comprehensive approach to addressing web service composition challenges. In contrast to works that view services as atomic planning operators, a significant body of research [37,38] has considered services as stateful entities, characterized by a well-defined behavioral description derived from BPEL specifications. In these studies, the requirements of the desired composite service are expressed in a temporal logic-like language, and planning techniques based on model-checking are employed for service composition, underscoring the importance of considering the stateful nature of services in planning-based web service composition. Similarly, recent advances in symbolic search such as the work of Bertoli (2006) [39] indicate that complex scenarios such as process modeling require the partitioning of action models. On the other hand, the development of research in process modeling has been developed mainly from the classical AP approach and not from HTN, due to the limitation of a development framework in HDDL. Given this difficulty Berchner (2025) [40] has developed a framework for HDDL like the development frameworks in PDDL to improve the construction of action and problem models in alternative contexts such as process modeling.

2.3. Research Gap and Contribution of PlanProjU

Existing BPMN-to-planning studies provide useful foundations, but they do not clearly integrate BPMN-based project modeling, traceable transformation into hierarchical planning representations, multi-planner execution, and user-oriented support for university project planning within a single artifact. In addition, previous studies do not clearly combine four aspects in a unified artifact: (i) BPMN-based project modeling, (ii) traceable transformation into hierarchical planning representations, (iii) execution with multiple HTN planners, and (iv) support for non-expert institutional users through an integrated web platform.

To make the positioning of PlanProjU more explicit,

Table 2. Feature-based comparison between PlanProjU and representative related approaches.

Approach/Study	BPMN-Based Input	Automated Transformation to Planning Model	Hierarchical Planning Support	Traceable Transformation	Multiple Planner Execution	User-Facing Platform	University Project Domain
Reijers (2016) [27]	Partial/process-oriented	No explicit BPMN-to-HDDL workflow	No explicit HTN focus	No	No	No	No
Marella (2019) [28]	Process-oriented support	Partial	No explicit HTN focus	No	No	Partial	No
La Rosa et al. (2017) [29]	Process execution context	No explicit transformation workflow	No	No	No	No	No
Service composition approaches [30,31,34]	No direct BPMN emphasis	Yes, but service-oriented	Mostly non-HTN	No	No	No	No
HDDL development frameworks [41,42]	No	Partial, planning-model oriented	Yes	No BPMN traceability	No	Partial/developer-oriented	No
Generic process/planning approaches [43]	Partial	Partial	Limited/indirect	No	No	No	No
PlanProjU (this study)	Yes	Yes	Yes	Yes	Yes (SHOP2, PyHOP)	Yes	Yes

compares the proposed artifact with representative related approaches using a set of criteria derived from the objectives of this study. These criteria focus on whether prior work supports BPMN-based modeling, automated transformation into planning representations, hierarchical planning, traceability, comparative planner execution, user-facing interaction, and applicability to project planning.

As shown in Table 2, prior studies provide valuable foundations in process-aware planning, workflow automation, and planning-model construction, but they do not combine all the features integrated in PlanProjU. In particular, the combination of BPMN-based project capture, traceable transformation into HDDL, comparative execution with multiple HTN planners, and support for university project planning within a user-facing platform distinguishes the present proposal from the related work reviewed.

The contribution of this study is therefore not limited to software integration. First, it introduces a BPMN-to-HDDL transformation workflow tailored to university project planning, in which process structure is translated into hierarchical planning representations that preserve task ordering, decomposition logic, and supported branching dependencies. Second, it provides traceability between modeled BPMN elements and the resulting planning structures, enabling users to inspect how project knowledge is operationalized into executable planning artifacts. Third, it implements this workflow in a web-based system, PlanProjU, that supports the generation and comparison of alternative plans using two HTN planners, SHOP2 and PyHOP.

From a scientific perspective, the novelty of the work lies in the integration of hierarchical planning with BPMN-based university project models through an explicit transformation pipeline and comparative execution environment. This distinguishes the proposal from prior BPMN-to-planning approaches that either operate in different domains, rely on non-hierarchical planning formulations, or do not expose a traceable and user-oriented planning workflow.

In this sense, the contribution of PlanProjU is relevant not only for the automation of university project execution, but also for research on the integration of business process modeling and hierarchical planning, particularly in domains were institutional workflows must be transformed into executable planning knowledge. For this reason, PlanProjU is positioned not merely as an implementation platform, but as a BPMN-to-HDDL transformation and comparative HTN planning framework tailored to university project execution.

2.4. Technical Foundations and Planner Selection Rationale

HTN planning was selected because university project execution is naturally hierarchical, requiring decomposition of institutional initiatives into subprojects, tasks, and operational decisions. HDDL provides a standardized representation for hierarchical planning domains and problems, improving formal clarity and interoperability. SHOP2 and PyHOP were selected as complementary HTN planners because they enable comparative generation of alternative plans from the same BPMN-derived planning structures while differing in implementation style and operational behavior.

An HTN planning instance can be written as $P=\langle L,C, A,M,s_0,t_{nI},g,\delta \rangle$. Here, L, A, $s_0$, $g$ and $\delta$ have their usual meanings from classical planning (set of literals, set of primitive actions, initial state, goal condition, and cost/metric, respectively). The set C contains abstract task symbols (high-level activities) and is disjointed from the primitive task names, i.e., $C\cap A=\varnothing$. Tasks are arranged into task networks $tn=\langle T,\prec , \alpha \rangle$, were T is a (possibly empty) set of task identifiers, and $\alpha :T\to A\cup C$ labels each identifier with either a primitive or an abstract task—allowing the same task name to occur multiple times in the network. The precedence relation $\prec \subseteq TxT$ is a strict partial order over identifiers (irreflexible, transitive, and therefore asymmetric). The component $M$ denotes the set of methods that decompose abstract tasks into subnetworks, and $t_{nI}$ is the initial task network.

Two task networks $tn=\langle T,\prec , \alpha \rangle$ and ${tn}^{\prime }=\langle T^{\prime },{\prec }^{\prime }, {\alpha }^{\prime }\rangle$ are isomorphic when they differ only by a renaming of task identifiers. Formally, there exist a bijection $\sigma :T\to T^{\prime }$ such that for all $t,t^{\prime }\in T:\left(t,t^{\prime }\right)\in \prec \iff \left(\sigma \left(t\right),\sigma \left(t^{\prime }\right)\right)\in {\prec }^{\prime }$ and $\alpha \left(t\right)={\alpha }^{\prime }\left(\sigma \right(t\left)\right)$.

In HTN planning, decompositions are specified by methods. A method couples an abstract task symbol $c\in C$ with a subtask network, written $m=\langle c,u\rangle$, were $u=\langle U,{\prec }_U,{\alpha }_U\rangle$. Consider a task network ${tn}_1=\langle T_1,{\prec }_1,{\alpha }_1\rangle$ and an identifier $t\in T_1$ such that ${\alpha }_1\left(T\right)=c$. The method $m$ can be applied by replacing t with a fresh copy of the subtask network into a task network ${tn}_2=\langle T_2,{\prec }_2,{\alpha }_2\rangle$. Formally, there must exist an isomorphic renaming θ of u that produces $\widehat{u}=\langle \widehat{U},{\prec }_{\widehat{U}},{\alpha }_{\widehat{U}}\rangle$ with fresh identifiers $(T_1\cap \widehat{U}=\varnothing )$ and $u\cong \widehat{u}$. There is a task network ${tn}^{\prime }=\langle T^{\prime },{\prec }^{\prime }, {\alpha }^{\prime }\rangle$ with ${tn}^{\prime }\cong tn$ and $T_1\cap T^{\prime }=\varnothing$. The task network ${tn}_2$ is defined as follows:

$${tn}_2=\left(\right(T_1\backslash \left\{t\right\})\cup T^{\prime },{\prec }^{\prime }\cup {\prec }_D,({\alpha }_1\backslash \left\{t\to c\right\}\cup {\alpha }^{\prime }\left)\right),$$

(1)

$$\begin{array}{c}{\prec }_D=\left\{\left(t_1,t_2\right)\left|\right(t_1,t)\in { \prec }_1,t_2\in T^{\prime }\right\}\hfill \\ \cup \left\{\left(t_1,t_2\right)\left|\right(t,t_2)\in { \prec }_1,t_1\in T^{\prime }\right\}\hfill \\ \cup \left\{\left(t_1,t_2\right)|\left(t_1,t_2\right)\in { \prec }_1,t_1\ne t\wedge t_2\ne t\right\}\hfill \end{array}$$

(2)

$M$ is the set of decomposition methods. We will write ${tn}_{t,m}\to {tn}^{\prime }$ to denote that $tn$ can be decomposed into a task network ${tn}^{\prime }$ by applying the method $m$ to the task $t$, and $tn\to \ast {tn}^{\prime }$ if it is possible to decompose $tn$ into ${tn}^{\prime }$ using a sequence of methods.

The decomposition begins either with a single initial task or with a task network (that may include more than one task). A definition using a single initial task is sometimes beneficial to keep proof simple. Using an initial task network makes it possible to interpret every search node in the search space as a new planning problem [44]. However, both definitions are equivalent: Given an initial task network ${tn}_I$, it can be compiled away by introducing a new task $c_I$ (that is the new initial task) and a method $m$ that decomposes the new task into the original task network $m=(c_I,{tn}_I)$.

A task network $tn=(T, \prec ,\alpha )$ is a solution to a given HTN planning problem $P=(L,C,A,M,s_0, {tn}_I,g,\delta )$ if and only if the following solution criteria hold:

• ${tn}_I\to \ast tn$, i.e., It can be reached by decomposing the initial task network.
• $\forall t\in T:\alpha \left(t\right)\in A$, i.e., all task names are primitive.
• There is a sequence $\langle t_1,t_2\dots .t_n\rangle$ of the task in $T$ that is in line with $\prec$, i.e., $\forall i<j:(t_j,t_i)\notin \prec$, and the application of $\langle \propto \left(t_1\right)\propto \left(t_2\right)\dots ..\propto \left(t_n\right)\rangle$ in $s_0$ results in goal state.

The last solution criterion requires an HTN solution to result in a goal state. This is quite unusual, since most hierarchical formalisms lack a (state-based) goal definition though some have one, e.g., these introduced by Bercher (2017) [45,46].

HTN planning was selected because university project execution is naturally hierarchical. Institutional initiatives are typically decomposed into subprojects, activities, dependencies, and operational decisions that can be represented more naturally through task refinement than through flat action sequences. This makes HTN planning particularly appropriate for modeling project implementation workflows in which high-level project goals are operationalized through progressively refined activities.

HDDL was adopted as the planning representation language because it provides a formal and standardized way to express hierarchical planning domains and problems. In the context of this study, HDDL is appropriate because it allows the hierarchical structure extracted from BPMN models to be encoded in terms of tasks, methods, and planning problems with clear formal semantics. This improves the reproducibility of the generated planning artifacts and facilitates interoperability between the transformation module and HTN planning environments [47].

Two HTN planners were selected for comparative execution: SHOP2 and PyHOP. SHOP2 was chosen because it is a mature and well-established HTN planner that supports explicit domain knowledge and ordered task decomposition. PyHOP was selected because it provides a lightweight and flexible HTN environment that is easier to integrate and experiment with programmatically. Their joint use makes it possible to compare how different HTN implementations behave when executed over the same BPMN-derived planning representations.

The selection of SHOP2 and PyHOP was guided by five criteria: (i) compatibility with hierarchical task decomposition, (ii) practical availability for implementation, (iii) maturity and prior use in HTN research, (iv) complementary implementation styles, and (v) feasibility of integration into the PlanProjU transformation and execution workflow. Therefore, the choice of these planners was methodological and pragmatic rather than arbitrary.

2.4.1. SHOP2

SHOP2 was first demonstrated in 2002 at the “International Planning Competition” [48]. It was originally written in Lisp, a functional programming language like SHOP. One of SHOP2’s key properties is that it maintains the same order of planning tasks as they will be executed, which enables it to generate plans quickly [21]. However, SHOP2 differs from SHOP in one significant way: it allows subtasks to be partially ordered, while still preserving performance. This modification also enables the use of simpler knowledge bases. Furthermore, SHOP2 can interleave subtasks from different tasks using the Planning Operator Transfer and Decomposition (POTD) method [1], thereby avoiding the need for global planning instructions.

To start the planner SHOP2 it is required to define: $\mathrm{s}:\mathrm{i}\mathrm{n}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{a}\mathrm{l} \mathrm{s}\mathrm{t}\mathrm{a}\mathrm{t}\mathrm{e}, \mathrm{T}:\mathrm{p}\mathrm{a}\mathrm{r}\mathrm{t}\mathrm{i}\mathrm{a}\mathrm{l}\mathrm{l}\mathrm{y} \mathrm{o}\mathrm{r}\mathrm{d}\mathrm{e}\mathrm{r}\mathrm{e}\mathrm{d} \mathrm{s}\mathrm{e}\mathrm{t} \mathrm{o}\mathrm{f} \mathrm{s}\mathrm{u}\mathrm{b} \mathrm{t}\mathrm{a}\mathrm{s}\mathrm{k}\mathrm{s} \mathrm{a}\mathrm{n}\mathrm{d} \mathrm{D}:\mathrm{d}\mathrm{o}\mathrm{m}\mathrm{a}\mathrm{i}\mathrm{n} \mathrm{o}\mathrm{r} \mathrm{a}\mathrm{c}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n} \mathrm{m}\mathrm{o}\mathrm{d}\mathrm{e}\mathrm{l}$ Starting with a: run SHOP2($S,t,D$). The Pseudo-code example from [1]:

$$\begin{array}{c}M\leftarrow m,\theta \\ if M=0 then return failure\\ non-deterministically choose a pair \left(m,\theta \right)\in M\\ modifiy T by removing t, adding sub\left(m\right)\\ if sub\left(m\right) !=0 then\\ T_0\leftarrow t\in sub\left(m\right)\\ else T_0\leftarrow t\in T\end{array}$$

2.4.2. HDDL

The Hierarchical Domain Definition Language (HDDL) is an extension of the Planning Domain Definition Language (PDDL) that incorporates hierarchical task networks (HTN). Introduced by Nau and Holler [48], HDDL offers a standardized language for hierarchical planning systems, accompanied by comprehensive documentation and a range of domains and problems. Many of these resources are sourced from the hierarchical task network tracks of the International Planning Competitions (IPC-HTN), specifically from the 2023 IPC-HTN tracks. HDDL’s design enables users to define or modify problem-solving approaches by adjusting the hierarchical task networks to suit their specific needs.

Definition of planning action model or Domain: A planning domain $D$ is tuple $(L,T_p,T_c,M)$ it define: $L$ is the underlying predicate logic, $T_p \mathrm{a}\mathrm{n}\mathrm{d} T_c$ are finite sets of primitive and compound tasks, $M$ is a finite set of decomposition methos with compound tasks from $T_c$ and tasks networks over the set $T_p\cup T_c$.

Definition of planning problem: A planning problem $P$ is a tuple $(D,s_I,t{n}_I,g)$, it defines: $s_I\in S$ is the initial state, a ground conjunction of positive literals over the predicates assuming the closed word assumption. $t{n}_I$ is the initial task network that may not necessarily be grounded. $g$ is the goal description, being a first-order formula over the predicates (not necessarily ground).

2.4.3. PyHOP

PyHOP is a simple HTN scheduler written in Python, compatible with versions 2.7 through 3.2, and contains fewer than 150 lines of code. Its scheduling algorithm is based on that of SHOP, but it avoids the need for a specific scheduling language by having the task network and its methods written in Python, using alternative syntax to logic for defining variables, actions, and methods. PyHOP’s development stemmed from the observation that application developers often wrote their own scheduling systems instead of learning specialized AI scheduling languages. PyHOP was created with the hope of providing an HTN scheduler that would be understandable to people without AI experience. The author of PyHOP did not make much of an effort to promote it, but its ease of understanding and use has made it useful for rapid prototyping, leading to its use in various projects and publications.

Table 3. Criteria used for selecting HDDL, SHOP2, and PyHOP.

Component	Selection Criterion	Justification in This Study
HTN planning	Hierarchical suitability	University projects are decomposed into subprojects and activities
HDDL	Formal and standardized representation	Encodes tasks, methods, and hierarchical planning problems clearly
SHOP2	Maturity and ordered decomposition	Suitable for explicit hierarchical execution and comparative analysis
PyHOP	Lightweight integration and flexibility	Facilitates programmable experimentation and platform integration

show the component, selection criteria and justification use in HTN planning.

HTN planning is particularly suitable for this work because university project execution is naturally hierarchical: institutional initiatives are decomposed into subprojects, activities, and operational decisions that can be represented as task refinements rather than as flat action sequences. HDDL was selected because it provides a standardized formal language for expressing hierarchical planning domains and problems, improving interoperability and reproducibility. SHOP2 and PyHOP were selected as complementary HTN planners because they allow comparative execution over the same generated planning structures while differing in implementation style and operational behavior. This enables the study to examine not only whether BPMN-derived hierarchical plans can be generated, but also how planner choice affects the resulting alternatives.

3. Methodology

This research employs the Design Science Research (DSR) approach as a systematic methodology for the construction and evaluation of an artifact intended to solve a relevant real-world problem. In this study, DSR provides the framework for designing PlanProjU, implementing the BPMN-to-HDDL transformation workflow, and evaluating the resulting planning artifact [49]. The article seeks to develop implementation plans for university projects using automated planning, a method validated through case studies [50]. This section describes the DSR procedure adopted to construct and evaluate the PlanProjU artifact. It explains the methodological stages followed for problem analysis, artifact design, implementation, and evaluation. The resulting planning system will enable the identification of project implementation plans in universities and facilitate the creation of a general project planning environment applicable across various contexts. The next Figure 1 shows the DSR methodology.

Figure 1, the research process in design sciences is a structured and systematic approach that involves several stages to ensure the development of a well-informed and effective solution to a relevant problem. The process commences with the identification of a relevant problem in stage 1, which is essential for formulating a structured research question in stage 2. Understanding the problem and its context, including causes and functionalities of the artifact, is crucial in this stage as it provides a solid foundation for the subsequent stages.

A systematic literature review in stage 3 involves consulting various technical databases, such as Scopus, WoS, IEEE, Google Scholar, Science Direct, and ArXiv, to justify the importance of developing the artifact and solving the problem. This stage is critical as it enables researchers to identify existing knowledge gaps and areas for improvement, thereby informing the development of the artifact. In stage 4, identifying artifacts that address similar problems allows researchers to apply best practices, while configuring the problem class defines the scope of their contributions.

This stage is essential as it enables researchers to build upon existing knowledge and develop a solution that is tailored to the specific problem at hand. The proposal of artifacts in stage 5 is related to solving a specific problem, and the researcher considers the feasibility and reality of the proposed artifacts. This stage is critical as it enables researchers to develop a solution that is practical and effective. In stage 6, the design of the selected artifact involves considering the entire context in which it operates and satisfactory solutions to the study problem.

It is essential to describe all procedures for the construction and evaluation of the artifact in this stage as it provides a clear understanding of the research methodology. The construction of the artifact is carried out in stage 7, while stage 8 involves evaluating the behavior of the artifact to provide a satisfactory solution to the problem. This stage is critical as it enables researchers to assess the effectiveness of their solution and identify areas for improvement. Stage 9 involves clarifying the learning achieved, explaining the factors that contributed to the success of the research and the elements that failed.

This stage is essential as it enables researchers to reflect on their experience and identify areas for improvement. The conclusions in stage 10 present the results of the research, the decisions made during its implementation, and the limitations of the research that may give rise to future studies. This stage is critical as it enables researchers to communicate their findings and contribute to the advancement of knowledge in the field. Stage 11 allows for the generalization of knowledge to similar situations by other organizations, while stage 12 involves communicating the results, contributing to a significant advancement of knowledge through publications in journals, seminars, conferences, and other platforms. This stage is essential as it enables researchers to disseminate their findings and contribute to the broader academic community.

3.1. Design Artefact: Mapping to a Graph Model BPMN

In this step, stage 5 of the DSR methodology is presented, given that the previous stages have been thoroughly developed and validated. The foundation established in the preceding stages provides a robust framework for the subsequent stages, ensuring a cohesive and systematic approach to the research. In this stage, Algorithm 1 is introduced, specifically designed for parsing the BPMN diagram. This diagram was previously developed by a process design expert for university outreach projects as a case study, providing a real-world context for the research.

This graph-based intermediate representation is not only an implementation detail of the artifact, but also a methodological step that supports the semantic extraction process. It provides the structural basis for identifying activity dependencies, decomposition boundaries, and branching relations before these are operationalized in HDDL. In this sense, the graph model acts as the bridge between BPMN process semantics and hierarchical planning representation.

3.2. Algorithm Parser or Translate BPMN to HDDL

The translation implemented in PlanProjU is designed to provide a traceable operational correspondence between supported BPMN constructs and hierarchical planning representations in HDDL. In the current version, the transformation explicitly handles core workflow elements such as tasks, sequence dependencies, gateways, and project decomposition structures. Rather than claiming full semantic completeness over the entire BPMN standard, the present work focuses on a supported subset of BPMN constructs relevant to university project planning.

HDDL is particularly appropriate in this workflow because the BPMN models processed by PlanProjU describe project structures that are not merely sequential, but hierarchical and decomposable. The transformation therefore requires a representation capable of encoding compound tasks, refinement methods, and executable problem instances. HDDL provides this capability in a standardized form, which makes it suitable for representing the hierarchical semantics extracted from BPMN project models in a way that can be executed by HTN planners and inspected systematically within the platform.

Within this scope, the translation provides three practical guarantees. First, it preserves the structural ordering of supported activities and precedence relations encoded in the BPMN model. Second, it preserves decomposition logic by representing project and subproject structure through hierarchical task formulations in HDDL. Third, it enables traceability between BPMN elements and generated planning entities, which allows users and developers to inspect how process-level knowledge is transformed into executable planning representations. Formal proof of correctness and completeness over arbitrary BPMN models is outside the scope of the present article and is identified as a direction for future work. The

Table 4. BPMN-to-HDDL mapping used in PlanProjU.

BPMN Construct	HDDL Representation	Meaning Preserved
Task/activity	Primitive or compound task	Executable project action
Sequence flow	Ordering constraint/task precondition	Precedence relation
Subprocess/Project block	Compound task/method	Hierarchical decomposition
Gateway (supported types)	Alternative or ordered decomposition logic	Branching structure
Actor/resource assignment	Task parameter/cost annotation/predicate	Execution context

show the BPMN-to-HDDL mapping.

Cost Model and Rule-Based Mapping from BPMN to Planning Actions

To make the evaluation metric explicit, PlanProjU defines the cost of a generated plan as the additive sum of the costs assigned to its executable actions:

$$Cost\left(\pi \right)={\sum }_{a\in \pi }w\left(a\right)$$

(3)

where π denotes the generated plan and a represents each executable action contained in the plan. Under this formulation, total plan cost is equivalent to the number of executable actions included in the generated plan.

This formulation was adopted to provide a simple, transparent, and reproducible comparison criterion across alternative plans generated from the same BPMN-derived project model. Therefore, in the current version of PlanProjU, the cost metric should be interpreted as a structural plan-comparison measure rather than as a detailed economic model of project execution. Future work may extend this formulation by introducing differentiated weights based on activity type, resource usage, execution time, or institutional cost data.

Table 5. Rule-based mapping from BPMN activities to planning-action costs.

BPMN Construct/Activity Category	Planning Representation	Cost Rule	Interpretation
Start event/end event	control-flow marker	0	Structural element, not an executable action
Exclusive/parallel gateway	decomposition or routing logic	0	Used to encode branching or synchronization, not directly costed
Standard operational task	Primitive action	1	Basic executable project activity
Coordination/scheduling activity	Primitive action	1	Activities involving planning, coordination, or agenda definition
Review/approval activity	Primitive action	1	Validation or decision-related actions
Resource assignment activity	Primitive action	1	Allocation of staff, tools, or institutional resources
Budget/payment/additional-cost activity	Primitive action	1	Actions with explicit financial or administrative impact
Compound project/subproject block	compound task/method	Derived from subtasks	Cost emerges from the decomposition into executable activities

below shows the BPMN elements represented as HTN domain elements.

3.3. Artifact: PlanProjU

The PlanProjU system, designed within the framework of the DSR methodology, offers a structured and reusable approach to university project planning. By taking BPMN diagrams as input, the system translates project knowledge into HDDL domain and problem representations that can be executed by alternative HTN planners. Beyond the generation of valid plans, the artifact is intended as a decision-support platform that allows project managers to compare planner outputs under a common process specification, thereby improving consistency in implementation scheduling and dependency management. Figure 2 presents the architecture of this modular platform.

Figure 2 summarizes the layered software architecture of PlanProjU and highlights the end-to-end workflow that transforms BPMN-based university project models into executable HTN planning artifacts. The architecture is organized into four main layers: the presentation layer, the application layer, the processing layer, and the planning layer. At the presentation layer, users interact with the platform through a web-based interface that supports project registration, BPMN upload, plan visualization, and result inspection. The application layer exposes the core services through a REST API implemented with FastAPI, while authentication and authorization are handled through JWT-based access control and role-based permissions. The processing layer is responsible for BPMN parsing, semantic extraction, graph construction, and transformation into HDDL domain and problem files. Finally, the planning layer executes the generated representations with HTN planners and returns the resulting plans and comparative metrics to the user interface. This layered design supports modularity, traceability, and extensibility within the platform. The project management component orchestrates CRUD operations, file uploads, and metadata handling, delegating persistence responsibilities to the data layer, were PostgreSQL supports transactional storage (ACID) and JSONB structures, Redis provides coaching for hot data and TTL-based performance optimization, and file storage maintains BPMN files and associated documentation. Finally, the processing layer operationalizes the core research contribution: a BPMN parser performs XML processing, structural validation, and model feature extraction, feeding a planning engine that executes planning requests using alternative algorithms (SHOP2 and PyHOP) to produce comparable plan variants.

This pipeline illustrates an architecture designed for modularity and extensibility allowing independent evolution of the BPMN parsing subsystem, the planning back end, and the user-facing interface while also enabling systematic comparison of planning outcomes using consistent inputs and integrated execution within a single platform. This modular separation is especially relevant for institutional adoption, since it allows the planning workflow, BPMN interpretation process, and comparative evaluation of alternative plans to be reused and extended without redesigning the full system. Figure 3 shows the component of PlanProjU.

Figure 3 provides a component-level view of the PlanProjU platform and details how the main modules interact during project modeling and plan generation. The architecture includes the user interface, project management services, BPMN processing modules, authentication services, and the planning engine responsible for generating alternative HTN-based plans. This view complements the layered architecture shown in Figure 2 by highlighting the specific software components involved in BPMN interpretation, HDDL generation, planner execution, and result visualization. The figure shows that PlanProjU is not only a front-end application for entering project information, but an integrated artifact that connects knowledge capture, formal transformation, and comparative plan analysis within a single platform.

These interactions are mediated by backend services organized around JWT-based authentication (token generation, session management, security layer), project management (CRUD operations, file/metadata handling), a planning service that acts as an orchestrator (algorithm selection and asynchronous execution), and an administration module for user/system configuration and analytics.

Within the processing engine, the BPMN parser performs XML parsing, schema validation, and structural extraction, producing the planning-ready representation that is then executed by two alternative planners SHOP2 (hierarchical HTN, depth-first search, cost optimization) and a PyHOP-based engine (state-based HTN execution). Plan outputs and runtime metrics are consolidated by a dedicated Metrics Analyzer that supports quality assessment, performance statistics, and comparative evaluation, and the resulting data is fed back to the frontend for visualization and decision support. This component is central to the practical contribution of PlanProjU, as it enables users to inspect alternative execution plans generated from the same BPMN model and to use comparative evidence when selecting an implementation strategy. Overall, architecture evidences a modular design that makes the planning subsystem, metric evaluation, and UI-layer comparison tightly integrated but independently evolve an important property for replicable experimentation and iterative enhancement in a research-grade planning platform. Figure 4 shows the usage layers.

Figure 4 illustrates the internal workflow used by PlanProjU to parse BPMN models and transform them into planning representations. The figure shows how the uploaded BPMN/XML file is processed to identify relevant structural elements, construct an intermediate graph representation, and extract the dependencies required for hierarchical planning. These elements are then used to generate the corresponding HDDL domain and problem files, which are later executed by the selected HTN planner. This transformation workflow is central to the contribution of the paper because it operationalizes project knowledge encoded in BPMN into executable planning artifacts while preserving the supported structural relations of the original process model. The workflow is complemented by Export Results, enabling multi-format reporting (PDF/Excel/JSON) and customizable report generation, which supports traceability and offline review. In parallel, the platform exposes governance-oriented functions Configure Parameters (algorithm settings, advanced adjustments, and fine-tuning) and Manage Users (CRUD operations, roles/permissions, and access control) which are primarily aligned with the administrator’s responsibilities but may be visible depending on privilege assignment. Overall, the diagram demonstrates a clear separation of concerns between operational execution and system administration, while ensuring that the full planning lifecycle from BPMN ingestion to plan evaluation and reporting is supported under a coherent role-based access control (RBAC) scheme. An additional SHOP2-only export was also generated for the UTP case under a different parameter configuration. Since this auxiliary run was not paired with an equivalent PyHOP execution under the same conditions, it was not included in the main comparative analysis and is treated as supplementary evidence only.

4. Experiments

This section evaluates PlanProjU as a design science artifact through a comparative case-based analysis of HTN plan generation from BPMN-derived university project models. The evaluation focused on two objectives: (i) to verify that BPMN-based project specifications can be transformed into executable planning representations and produce valid alternative plans, and (ii) to compare the behavior of SHOP2 and PyHOP under the same project inputs.

The study compares SHOP2 and PyHOP as two complementary HTN planning environments selected for their practical implementability, differing operational styles, and compatibility with the BPMN-to-HDDL workflow implemented in PlanProjU.

4.1. Evaluation Objectives and Design

The experimental evaluation was designed to assess both the feasibility of the BPMN-to-planning pipeline and the comparative behavior of the planners integrated into PlanProjU. Specifically, the study examined whether the system could consistently generate alternative plans from university project models and whether the resulting plans differed in terms of cost, number of steps, and execution time depending on the planner used.

Rather than relying only on qualitative inspection, the evaluation summarizes the generated plans using descriptive statistics over the exported plan variants for each planner and case. This makes it possible to compare the planners using a common set of metrics and to characterize the observed variability of the generated plans [51].

4.2. Case Studies

Three case studies were analyzed using outputs generated by PlanProjU. The first case corresponds to a UTP project related to environmental governance and territorial intervention. The second case corresponds to a university extension workflow labeled U Caldas proyection 1. The third case corresponds to the Extension FADMON process. In all three cases, the system identified one main subproject and generated alternative plans with both PyHOP and SHOP2.

The UTP case contained 16 activities. Its BPMN model included 16 tasks, 2 parallel gateways, 21 sequence flows, 1 start event, and 1 end event, with a maximum observed branching degree of 3 and no loop constructs.

The U Caldas proyection 1 case contained 20 activities. Its BPMN model included 20 tasks, 11 exclusive gateways, 42 sequence flows, 1 start event, and 3 end events, with a maximum branching degree of 4 and no observed loops.

The Extension FADMON process case contained 6 activities. Its BPMN model included 6 tasks, 1 exclusive gateway, 9 sequence flows, 1 start event, and 1 end event, with a maximum branching degree of 2 and no observed loops.

Table 6. Structural characteristics of the evaluated BPMN cases.

Case	Activities	Tasks	Exclusive Gateways	Parallel Gateways	Sequence Flows	Start Events	End Events	Max Branching Degree	Observed Loops
UTP	16	16	0	2	21	1	1	3	No
U Caldas proyection 1	20	20	11	0	42	1	3	4	No
Extension FADMON process	6	6	1	0	9	1	1	2	No

shows the structural characteristics of de evaluated BPMN cases.

4.3. Execution Protocol

For each case, PlanProjU generated three plan variants with PyHOP and three plan variants with SHOP2, resulting in six plans per case and eighteen plans in total across the three case studies. The same project specification was used as the basis for planner execution within each case, allowing direct comparison of the outputs produced by both planners.

Because the available evidence corresponds to exported plan variants rather than stochastic repeated trials in a benchmark environment, the reported statistics should be interpreted as descriptive summaries of planner outputs for each case. The comparison therefore emphasizes observed differences in plan cost, number of steps, and output stability across the generated alternatives.

4.4. Metrics and Statistical Treatment

The primary plan-level metrics used in the evaluation were: (i) total plan cost, (ii) total number of steps, and (iii) execution time in seconds. At the case level, the study also reports structural descriptors of the input models, including number of subprojects and number of activities, and, were the BPMN model was available, number of tasks, gateways, sequence flows, end events, and branching degree.

For each case-planner combination, the analysis reports the number of generated plan variants, mean value, standard deviation, minimum value, and maximum value for cost and number of steps. Execution time is also reported descriptively; however, due to the very small values recorded in the exported files, time differences should be interpreted cautiously.

The cost metric reported in the evaluation follows the unit-cost model described in Section Cost Model and Rule-Based Mapping from BPMN to Planning Actions. Under this formulation, each executable planning action has cost 1, while events and gateways have cost 0. Therefore, total plan cost corresponds to the number of executable actions included in the generated plan.

Because the current implementation adopts unit costs for executable actions, total plan cost is closely related to plan length. For this reason, both metrics are reported for completeness, but they should be interpreted as complementary views of the same structural property in the current version of the system.

To preserve methodological consistency, the revised manuscript restricts the quantitative comparison to metrics that can be directly verified from the exported planning evidence. The current evaluation focuses on structural comparison metrics that can be computed directly from the generated planning outputs. In particular, plan cost and plan length are used to compare alternative plans in terms of action composition and execution compactness. These metrics do not fully capture all relevant dimensions of project-plan quality, such as resource utilization, responsiveness to risk, or execution flexibility, which remain outside the scope of the present evaluation.

4.5. Scope and Current Limitations

The present evaluation supports the feasibility of the PlanProjU pipeline and provides an initial comparative characterization of SHOP2 and PyHOP on real university project cases. However, the current evidence remains bounded in scope. The study includes three case studies, each with one main subproject, and does not yet constitute a large-scale benchmark across systematically varied BPMN families.

Accordingly, the results should be interpreted as a structured case-based validation of the artifact rather than as a definitive scalability benchmark. A broader evaluation with additional BPMN models and full planner logs would enable future analysis of depth, plan size, scalability, and sensitivity to more complex workflow patterns such as loops, exceptions, and dense parallel resource dependencies.

4.6. User-Oriented Evaluation

To complement the system-centered evaluation, a user-oriented assessment was conducted through a structured questionnaire completed by five participants who interacted with the platform. The respondent profile included three university extension managers, one researcher, and one additional participant. The instrument included closed items related to BPMN-based project representation, ease of use, adequacy of generated plans, visibility of planning problems and generated plans, registration difficulty, and perceived value for university extension.

The collected responses were analyzed descriptively using frequencies for dichotomous items and mean values for Likert-type items. This evaluation was intended to provide preliminary evidence of perceived usability and practical relevance from potential institutional users. However, because the instrument was brief and was not designed as a standardized SUS, TAM, or UTAUT questionnaire, the resulting evidence should be interpreted as descriptive user-oriented feedback rather than as a full formal usability benchmark.

5. Results

The research demonstrates a platform that combines an HTN planning environment with the capture of base knowledge for any university project represented in the BPMN standard. In the reported comparisons, total plan cost should be interpreted under the unit-cost formulation adopted in PlanProjU. Since each executable action contributes one unit to the total cost, the metric reflects the total number of executable actions selected in the generated plan. For this reason, cost is used here as a transparent structural comparison measure rather than as a direct estimate of financial expenditure.

Table 7. Aggregated planner performance across generated plan variants.

Case	Planner	Runs	Mean Cost	SD Cost	Min Cost	Max Cost	Mean Steps	SD Steps	Min Steps	Max Steps
UTP	PyHOP	3	167.67	97.83	78	272	16.67	6.03	11	23
UTP	SHOP2	3	15.33	7.51	11	24	4.00	1.00	3	5
U Caldas proyection 1	PyHOP	3	22.67	2.89	21	26	10.00	0.00	10	10
U Caldas proyection 1	SHOP2	3	20.00	2.65	18	23	5.67	1.53	4	7
Extension FADMON process	PyHOP	3	10.33	0.58	10	11	6.00	0.00	6	6
Extension FADMON process	SHOP2	3	13.67	1.15	13	15	5.00	1.73	3	6

shows aggregated planner performance.

Table 7 summarizes the aggregated planner results across the three evaluated cases. In the UTP case, SHOP2 generated substantially lower-cost and shorter plans than PyHOP, with mean cost decreasing from 167.67 to 15.33 and mean number of steps from 16.67 to 4.00. In the U Caldas proyection 1 case, SHOP2 again produced both lower mean cost and fewer steps than PyHOP. In contrast, in the Extension FADMON process case, PyHOP achieved lower mean cost, whereas SHOP2 generated slightly shorter plans on average. These results indicate that planner performance is case-dependent and that no single planner should be presented as universally superior across all project structures.

The user-oriented assessment yielded encouraging descriptive results. Among the five respondents, 80% indicated that it is possible to represent an extension project as a BPMN process in PlanProjU, and 60% reported that the platform was easy to use. On the Likert-type items, the mean score for the adequate reflection of project activities in the generated plans was 3.8/5, the visibility of planning problems and generated plans reached 4.0/5, and the perceived value of PlanProjU for university extension was 3.8/5. These findings suggest a positive initial perception of the platform, although onboarding and registration did not receive uniformly favorable responses.

Table 8. Descriptive results of the user-oriented assessment.

Item	Sample	Result
BPMN representation possible	N = 5	80% positive
Platform easy to use	N = 5	60% positive
Activities adequately reflected in generated plans	N = 5	Mean = 3.8/5
Registration/user creation was complicated	N = 5	Mixed responses
Planning problems and generated plans are visible	N = 5	Mean = 4.0/5
PlanProjU adds value to university extension	N = 5	Mean = 3.8/5

shows the use of the PlanProjU System.

A more favorable pattern was observed within the subgroup of university extension managers (N = 3). In this subgroup, 100% indicated that extension projects can be represented in BPMN within PlanProjU and that the platform was easy to use. The mean scores for adequacy of generated plans, visibility of planning outputs, and perceived value for extension were 4.33/5, 4.67/5, and 4.33/5, respectively.

This platform produces plans that help project managers choose the best approach for implementing a project at a university. Project formulators or those responsible for executing university projects can obtain implementation plans for different university contexts through the system, which is user-centered. Rather than requiring a planning expert to model actions and problems, the platform accepts a BPMN diagram in .xml format. The platform generates alternative project implementation plans from BPMN input and supports their comparison through structural metrics such as plan cost and number of steps. In the current version, cost follows a unit-cost formulation and should therefore be interpreted as a structural comparison metric rather than as a direct estimate of financial expenditure. This allows project managers to inspect alternative execution strategies and support implementation decisions within the university context.

The research demonstrates how the PlanProjU system integrates an HTN planning environment with a BPMN knowledge source specifically for university projects. It generates a variety of plans based on different metrics, thereby supporting project implementation within the university context. Project developers can automate implementation or execution by generating plans, while the system remains focused on the user’s needs. The platform was explored in institutional settings involving participants from public universities in Colombia. For the UNAL-Audifarma project, the following BPMN was generated on the bpmn.io platform, as shown in Figure 5.

Figure 5 represents a BPMN model of the Audifarma-UNAL Train-the-Trainer extension project, structured by pools/lanes that define responsibilities (requestor, course coordination/management, and teaching/delivery role). The flow begins with the course request and the preparation/submission of the proposal, followed by a review and decision activity supported by a dedicated gateway, which branches the process toward approval or closure due to rejection. In case of approval, the model incorporates planning activities such as defining dates and resource allocation, as well as a gateway that specifies logistical and/or cost conditions, articulated with the rule that additional costs are assumed by the company. Then, the delivery of the course (3 h per session and 5 sessions) is connected to the attendance record, which acts as compliance control: a final gateway applies the certification policy, were a certificate is only issued if the participant attends at least 80% of the classes; Otherwise, it leads to the event of non-certification. Overall, the diagram demonstrates a process with explicit decision points, cost traceability, and a verification mechanism (attendance) that ensures consistency between the provision of the training service and the institutional certification criteria.

The interaction with each official took approximately 1 to 1.5 h, given the interruptions during the platform demonstration meeting. Each official was given a tour to navigate the platform and informed that a question mark in the upper right corner contained a guide developed within the platform to help them build the BPMN. During the interactions, some officials felt it necessary to view the file in BPMN or XML format. They were informed that this visualization was not available on the PlanProjU platform, as it focuses on HTN-type artificial intelligence planning and not on generating diagram visualizations under the BPMN standard. However, it is made clear to them that with the bpmn.io tool they can load the generated bpmn or xml file to visualize and modify the diagram, and that the integration of a visualization module into the platform’s architecture is considered as future research work. Figure 6 shows the plans generated in PlanProjU.

Figure 6 illustrates the output of PlanProjU for the Audifarma—UNAL Trainer Training case study is shown. The platform generates six plans, with three variants for each planner: SHOP2 and PyHOP. It presents, in summary form, the best plan from each algorithm along with an overall recommendation based on the lowest cost criterion. This organization is relevant for validation because it transforms the result of the BPMN 2.0 process into a set of comparable alternatives based on cost and step length metrics. This allows the end user or public official to evaluate not only a single plan but also the stability of the solution against different search/heuristic variants. It indicates that there are 4 fewer steps to obtain the best plan.

Analyzing the National University of Colombia block reveals a clear trade-off between economic efficiency and plan length: SHOP2 is selected as the best in its family with a cost of 6 and 7 steps, while PyHOP v3 has a cost of 7 with 4 steps. Consequently, the platform recommends SHOP2 because it is one unit cheaper, even though the plan is longer. This behavior suggests that, for this project, the search process penalizes certain decisions more significantly than simply reducing the number of activities. In terms of interpretation, PyHOP seems to produce plans with fewer steps but a higher overall cost; SHOP2, on the other hand, achieves preferable solutions, which is consistent with scenarios were breaking down activities further allows for choosing less expensive alternatives.

Finally, when comparing the three panels Requesting Company, National University, and Professor it is clear that the platform maintains the same decision logic and explicitly highlights the sensitivity of the result: for example, in the Requesting Company panel, the recommendation favors SHOP2 due to a marked cost difference of 1 vs. 5, while in the Professor panel, the advantage of SHOP2 also remains (5 vs. 7), although with shorter plans of 4–5 steps. This cross-cutting consistency reinforces the usefulness of PlanProjU as a decision support tool, since the user, as an extension office staff member, can justify the selection of the recommended plan based on quantifiable differences. Furthermore, they can examine alternatives (v1–v3) when cost is not the only relevant criterion. Taken together, the figures demonstrate that the validation process is not limited to generating plans but also enables a reproducible comparative analysis between the plans generated by the planners.

Table 9. Plan found for project to UNAL-Audifarma with PyHOP.

Plan 1	Plan 2	Plan 3
client_need_management3	client_need_management3	client_need_management3
proposal_presentation3	proposal_presentation3	proposal_presentation3
technical_and_financial_analysis_of_the_proposal3	approval_by_the_faculty_council3	verify_proposal_presentation2
request_for_approval_from_the_research_and_extension_committee6	campus_council_approval_if_applicable_	technical_and_financial_analysis_of_the_proposal6
approval_by_the_faculty_council6		request_for_approval_from_the_research_and_extension_committee6
campus_council_approval_if_applicable_		verify_request_for_approval_from_the_research_and_extension_committee4
		approval_by_the_faculty_council9
		campus_council_approval_if_applicable_

and

Table 10. Plan found for project to UNAL-Audifarma with SHOP2.

Plan 1	Plan 2	Plan 3
execute_request_for_approval_from_the_research_and_extension_committee34	execute_technical_and_financial_analysis_of_the_proposal38	execute_proposal_presentation33
execute_technical_and_financial_analysis_of_the_proposal40	execute_approval_by_the_faculty_council46	execute_campus_council_approval_if_applicable29
execute_client_need_management40	execute_technical_and_financial_analysis_of_the_proposal38	execute_campus_council_approval_if_applicable45
execute_campus_council_approval_if_applicable	execute_approval_by_the_faculty_council45	execute_client_need_management
	execute_proposal_presentation39
	execute_request_for_approval_from_the_research_and_extension_committee

show the generated plans from PyHOP and SHOP2.

Figure 7 shows the metrics for the plans generated for the UNAL-AUDIFARMA extension project.

Figure 7 presents a comparative view of the plans generated by SHOP2 and PyHOP for the UNAL-Audifarma extension project using two evaluation criteria: total plan cost and number of steps. The upper panel shows that SHOP2 generated a lower-cost plan than PyHOP for this case, which indicates a more efficient solution under the cost model adopted by the platform. The lower panel shows that SHOP2 also produced a shorter plan in terms of number of steps, suggesting a more compact decomposition of the planning problem. Taking together, these results indicate that, for this project, SHOP2 achieved better performance than PyHOP according to both evaluated metrics. This case therefore illustrates the practical value of comparing alternative planners within PlanProjU rather than relying on a single execution strategy. For the Universidad de Caldas project, the following BPMN was generated on the bpmn.io platform, as shown in Figure 8.

Figure 8 presents the BPMN model used for the Universidad de Caldas case study. The diagram makes explicit the main activities, control-flow structure, and decision points that define the project workflow before transformation into the hierarchical planning representation. This BPMN model serves as the process-level input to PlanProjU and provides the structural basis for generating the corresponding HDDL domain and problem files. In this way, the figure illustrates how project knowledge is first formalized in BPMN before being converted into executable planning artifacts. Figure 9 shows the plans generated in PlanProjU.

Figure 9 presents the comparative plan outputs generated by SHOP2 and PyHOP within the PlanProjU environment for the Universidad de Caldas case. The figure highlights how both planners can produce alternative plans from the same BPMN-derived project representation while differing in cost, number of steps, and internal decomposition structure. This comparison illustrates one of the main functional advantages of the platform: instead of generating a single plan, PlanProjU enables the exploration of multiple executable alternatives under the same project model. Such comparative visibility is important in university project planning because it allows users to evaluate trade-offs before selecting an implementation strategy. It indicates that there are 49 fewer steps to obtain the best plan.

Such comparative visibility is important in university project planning because it allows users to evaluate trade-offs before selecting an implementation strategy. This supports the interface’s automatic recommendation in favor of SHOP2, as it is 49 units less expensive. The breakdown of the SHOP2 plan shows a concrete and traceable sequence of activities, suggesting that the plan prioritizes a minimal procedure to reach the target state with the lowest aggregate cost. Similarly, the presence of multiple variants per planner reveals a range of solutions with cost-length trade-offs: SHOP2 offers alternatives with simultaneous variations in cost and steps, while PyHOP maintains a constant length of 10 steps but with different costs (17 and 66), consistent with differences in search strategy and task decomposition. Overall, the figure supports the idea that the platform generates plans and allows users to select the best plan based on cost and step length metrics.

Table 11. Plan found for project to Universidad de Caldas with PyHOP.

Plan 1	Plan 2	Plan 3
collect_project_information3	collect_project_information3	collect_project_information3
fill_in_general_data__title__modality__coordinator__duration__dates__location_3	define_alignment_with_institutional_plans__PDI__PPU__faculty_department_plan_3	fill_in_general_data__title__modality__coordinator__duration__dates__location_3
write_description__problem_and_background_3	define_general_objective_and_specific_objectives3	verify_fill_in_general_data__title__modality__coordinator__duration__dates__location_2
define_alignment_with_institutional_plans__PDI__PPU__faculty_department_plan_6	define_continuing_education_portfolio_catalog__courses__diplomas__workshops_6	write_description__problem_and_background_6
define_general_objective_and_specific_objectives6	define_beneficiary_population_and_expected_quantity6	define_alignment_with_institutional_plans__PDI__PPU__faculty_department_plan_6
define_methodology__design__development__evaluation_and_offering_6	define_novelty_of_the_proposal6	verify_define_alignment_with_institutional_plans__PDI__PPU__faculty_department_plan_4
define_continuing_education_portfolio_catalog__courses__diplomas__workshops_9	define_expected_impact9	define_general_objective_and_specific_objectives9
define_beneficiary_population_and_expected_quantity9	define_expected_products9	define_methodology__design__development__evaluation_and_offering_9
define_novelty_of_the_proposal9	adjust_content_and_attachments_of_the_proposal9	verify_define_methodology__design__development__evaluation_and_offering_6
define_expected_impact12	submit_proposal_to_the_internal_call	define_continuing_education_portfolio_catalog__courses__diplomas__workshops_12
review_coherence_and_complete_the_proposal12	define_novelty_of_the_proposal6	define_beneficiary_population_and_expected_quantity12
adjust_content_and_attachments_of_the_proposal15		verify_define_beneficiary_population_and_expected_quantity8
submit_proposal_to_the_internal_call		define_novelty_of_the_proposal15
		define_expected_impact15
		verify_define_expected_impact10
		define_expected_products18
		review_coherence_and_complete_the_proposal18
		verify_review_coherence_and_complete_the_proposal12
		adjust_content_and_attachments_of_the_proposal21
		submit_proposal_to_the_internal_call

and

Table 12. Plan found for project to Universidad de Caldas with SHOP2.

Plan 1	Plan 2	Plan 3
execute_review_coherence_and_complete_the_proposal38	execute_write_problem_description_and_background45	execute_collect_project_information42
execute_define_beneficiary_population_and_expected_quantity30	execute_collect_project_information38	execute_define_expected_impact39
execute_fill_in_general_data_title_modality_coordinator_duration_dates_location	execute_define_general_objective_and_specific_objectives35	execute_fill_in_general_data_title_modality_coordinator_duration_dates_location
		execute_adjust_content_and_attachments_of_the_proposal33
		execute_define_expected_impact29
		execute_define_general_objective_and_specific_objectives

shows the generate plan of University of Caldas from PyHOP and SHOP2.

Figure 10 shows the metrics for the plans generated for the Universidad de Caldas extension project.

Figure 10 shows the comparative analysis between SHOP2 and PyHOP for the Universidad de Caldas extension project by reporting total plan cost and number of steps. In the upper panel, SHOP2 generated a lower-cost plan than PyHOP, indicating a more resource-efficient solution for the BPMN-derived planning problem considered in this case. In the lower panel, SHOP2 also produced a shorter plan, which suggests a more compact execution structure and fewer operator applications. The joint advantage of SHOP2 in both metrics indicates that planner choice can significantly affect the quality of the generated alternatives. This result supports the value of integrating multi-planner comparison into PlanProjU as part of its decision-support capability.

6. Discussion

This section interprets the results beyond their descriptive presentation and discusses their implications for university project planning. First, it examines the comparative behavior of the planners in relation to the structural characteristics of the evaluated BPMN cases. Second, it discusses the practical implications of the findings for university project managers. Finally, it outlines the main methodological limitations and validity threats that define the scope of the current study.

6.1. Interpretation of Planner Comparison

This subsection interprets the comparative planner results considering case structure and evaluation scope.

The comparative results indicate that planner behavior is case-dependent and should not be interpreted through a single universal dominance criterion. In the UTP case and in the U Caldas projection 1 case, SHOP2 produced lower mean cost and fewer mean steps than PyHOP, which suggests a stronger performance in workflows with greater structural richness and decomposition demands. In contrast, in the Extension FADMON process case, PyHOP achieved a lower mean cost, while SHOP2 still generated slightly shorter plans on average. This pattern indicates that the relative adequacy of each planner depends on both project structure and the optimization criterion prioritized by the user. The inclusion of structural BPMN descriptors in Table 6 also helps contextualize the planner comparison. The larger and more branched cases exhibited more pronounced differences between SHOP2 and PyHOP, suggesting that workflow structure plays a relevant role in planner behavior. Although the present dataset does not yet include planner-internal metrics such as node expansions, the current tables provide a clearer basis for relating plan outcomes to case complexity.

A second relevant finding is that the difference between planners becomes more visible as BPMN models include more activities, gateways, and branching alternatives. The UTP and U Caldas cases, which are structurally more complex than the Extension FADMON process, showed a clearer divergence between SHOP2 and PyHOP. This suggests that planner selection is not merely a technical implementation detail, but an analytical factor that can affect the resulting execution strategies. Therefore, comparative planner support should be understood as part of the contribution of PlanProjU rather than as an accessory platform function. The reported differences between planners should be interpreted within the scope of the metrics used in this study. Since the evaluation is based mainly on cost and number of steps, the results indicate differences in structural efficiency and decomposition behavior rather than a complete assessment of plan quality. Other relevant dimensions, such as resource allocation efficiency, adaptability to disruptions, and flexibility under changing execution conditions, were not directly measured in the present study.

The comparative results suggest that planner adequacy depends on project structure and optimization criterion. In the UTP and U Caldas proyection 1 case, SHOP2 produced both lower-cost and shorter plans, indicating a stronger performance in workflows with more structural branching and decomposition alternatives. However, in the smaller Extension FADMON process case, PyHOP yielded a lower mean cost, while SHOP2 maintained a slight advantage in compactness of the resulting plan. This pattern suggests that SHOP2 may be more advantageous in structurally richer project models, whereas PyHOP may remain competitive in simpler workflows when cost is prioritized overstep compactness.

6.2. Practical Implications for University Project Management

This subsection discusses the practical relevance of the findings for university project management.

From a practical perspective, the results suggest that PlanProjU can support university project managers by making project structure, dependencies, and execution alternatives more explicit. By using BPMN as the input language, the platform allows institutional knowledge to be captured in a familiar process-modeling format and subsequently transformed into executable planning artifacts. This creates a bridge between process design and plan generation that can help extension offices and academic units formalize project workflows that are otherwise handled in a largely manual and experience-dependent manner.

The user-oriented assessment also remains limited in scope. Although it provides useful descriptive evidence of perceived usefulness and interpretability, the sample size was small and the instrument was not based on standardized usability frameworks such as SUS, TAM, or UTAUT. For this reason, the human-centered findings should be interpreted as preliminary support for practical relevance rather than as a conclusive usability validation. Future work should address these limitations through broader datasets, standardized evaluation instruments, and more systematic stress-testing of BPMN-to-HDDL transformations under diverse workflow patterns.

6.3. Methodological Limitations and Validity Threats

This subsection outlines the main methodological limitations and validity threats of the current study.

The current cost formulation is intentionally simple and uses unit costs for executable actions. This improves transparency and reproducibility, but it also means that the reported cost metric should not be interpreted as a detailed economic representation of university project implementation. A richer cost model based on activity classes, resource demand, duration, or institutional budget data remains a direction for future work.

Another limitation of the present evaluation is that plan quality was assessed using a restricted set of structural metrics. Although cost and plan length are useful for transparent comparison of generated plans, they do not capture broader operational qualities such as resource utilization, flexibility, or responsiveness to uncertainty. These dimensions would require richer project annotations, resource-aware representations, and scenario-based evaluation protocols that were not available in the current version of the artifact.

Despite these encouraging findings, the present study has important methodological limitations that must be acknowledged. First, the evaluation is based on three case studies and eighteen generated plans in total, which supports a structured case-based validation but does not yet constitute a large-scale benchmark. Second, the comparison is limited to two HTN planners, SHOP2 and PyHOP, and therefore does not establish broader generalizability across other hierarchical or non-hierarchical planning approaches. Third, although structural BPMN descriptors were recovered for the evaluated cases, the study does not yet include a controlled synthetic benchmark designed to isolate the effects of loops, exceptions, or dense parallelism.

The user-oriented assessment provides preliminary descriptive evidence of perceived usefulness and interpretability, especially among university extension managers. Nevertheless, the sample size remains limited, and the instrument was not based on a standardized usability framework. Therefore, these findings should be interpreted as early support for practical relevance and adoption potential rather than as a definitive usability validation.

The current evaluation should be interpreted as a structured case-based validation rather than as a full benchmark study. Although the three cases differ in number of activities, gateways, and branching degree, the dataset remains limited, and no controlled synthetic family of BPMN models was used to isolate the effect of loops, exceptions, or dense parallelism. In addition, the exported evidence supports verified comparison of cost, number of steps, and basic structural descriptors, but does not yet retain full planner logs for deeper indicators such as plan depth or search-space exploration. Accordingly, the current results should be interpreted as evidence of comparative structural performance rather than as a comprehensive ranking of plan quality.

7. Conclusions and Future Work

This study contributes a traceable BPMN-to-HDDL workflow for hierarchical planning in the context of university project execution. Its main contribution is not merely the implementation of a web platform, but the design of a transformation pipeline that operationalizes BPMN project knowledge into hierarchical planning artifacts while enabling comparative plan generation with two HTN planners. The case-based evaluation shows that this approach is feasible in real university project settings and that planner behavior can differ depending on workflow structure and decision criteria. From an applied perspective, the study also contributes to a modular platform that can support university extension offices in comparing alternative implementation plans, improving consistency in scheduling decisions, and making project dependencies more explicit and traceable.

Fourth, it is the first work to apply HTN planning to university project management, wh from a scientific standpoint extends BPMN-to-planning research by focusing on university project management as a new application domain and by emphasizing hierarchical decomposition, transformation traceability, and planner comparison within a user-oriented artifact. At the same time, formal verification of the translation over the full BPMN standard remains outside the present scope and should be addressed in future work.

This allows the end user to approve or reject the generated plans based on whether they accurately represent the information of the evaluated project. The research focuses on automating the generation of plans for project execution or implementation in a university context, thus addressing the cost and bias issues that arise during formulation and implementation with the help of HTN planning. Studies like this drive innovation and scientific progress by integrating two areas of knowledge: project management and automated planning such as HTN.

The present results support the feasibility of BPMN-to-HDDL transformation and the comparative generation of alternative HTN-based plans for university projects. However, the current evaluation remains centered on structural metrics, particularly cost and plan length. Future work should extend this assessment by incorporating additional plan-quality dimensions such as resource utilization, flexibility under execution changes, and responsiveness to risk, thereby providing a broader and more realistic basis for evaluating project-plan quality.

The innovations highlighted in this study include several key distinctions: while existing tools leverage broad language models to refine domain construction in PDDL and HTN, they omit consideration of the HDDL formalism and limit their testing to well-known domains, such as logistics, robotics, transportation, and risk management, for plan generation. In contrast, PlanProjU incorporates HDDL formalism, analyzing a new domain such as university projects to generate multiple plans using SHOP2 and PyHOP planners, and offers an intuitive interface designed for non-technical users, including university project developers, thus opening new avenues for research in HTN planning and project management. Experimental validation with two universities and three different generated projects demonstrated that PlanProjU reduced the time required for project implementation.

Within the scope of this study, SHOP2 and PyHOP served as two complementary HTN planning environments that enabled comparative execution of BPMN-derived hierarchical planning representations, allowing the artifact to evaluate planner-dependent differences in generated plans.

This efficiency was due to the automation of 98% of the knowledge gathered for projects conceived by extension offices. The resulting plans were preliminary evidence of perceived usefulness by extension officers at the Colombian universities in the case studies. These quantitative findings demonstrate that PlanProjU not only automates the execution and implementation of university projects but also enables the deployment of HTN artificial intelligence planning in previously unexplored contexts, generating effective results in project planning.

In addition to the planner-based comparison, the user-oriented assessment with five participants provided preliminary descriptive evidence that the platform is perceived as useful for representing extension projects, inspecting generated plans, and supporting institutional interpretation of planning outputs. However, broader studies with larger samples and standardized usability instruments are still required.

For this reason, the work may be of interest not only to university project managers, but also to researchers in business process management, process modeling, and automated planning who are concerned with transforming structured process knowledge into executable planning representations.

Future research will aim to consolidate and broaden the methodological framework that merges Business Process Modeling and Notation (BPMN) with Hierarchical Task Network (HTN) planning to automate university outreach projects; although the present system successfully converts BPMN process structures into HDDL domains, additional effort is required to refine the semantic representation and contextual nuances of actors, resources, and control-flow dependencies, and by incorporating domain ontologies and knowledge graphs we can achieve a more accurate alignment between BPMN entities and HTN constructs, thereby enhancing the expressiveness of the resultant planning models.

Finally, the research agenda calls for integrating neuromyotonic learning methods to boost the system’s adaptability and predictive power; by blending machine-learning techniques with HTN symbolic reasoning the system can automatically learn action models, cost estimates, and decomposition patterns directly from project execution logs, and by leveraging large-language models and transformer-based architectures it can extract procedural knowledge from textual project documents. Overall, the revised results support the view that PlanProjU offers both an innovative methodological contribution at the intersection of BPMN modeling and HTN planning and a practical alternative for structuring university project implementation in real institutional contexts.

Taken together, these findings suggest that PlanProjU is relevant not only as a technical artifact, but also as a practical support mechanism for university project management and as a domain-specific contribution to the study of hierarchical automated planning in structured organizational workflows.