The Information Entropy Performance Indicator (IEPI): A Deterministic BPMN Analytics Artifact for Routing-Uncertainty Diagnostics and Viability Assessment

Abstract

Business Process Management (BPM) process models represent routing behaviour through control-flow constructs, yet BPMN 2.0 does not provide a native mechanism for quantifying uncertainty associated with routing decisions. This study presents the Information Entropy Performance Indicator (IEPI) as a deterministic BPMN analytics artifact for evaluating routing uncertainty under externally specified routing probabilities. The IEPI framework integrates construct-level routing diagnostics, viability assessment, diagnostic flagging, compositional uncertainty propagation, and process-level reporting within a unified analytical workflow. The IEPI engine accepts as input a BPMN 2.0 process representation, a routing-probability map, and analyst-specified viability thresholds. It computes (i) construct-level diagnostics based on normalized entropy and responsiveness, (ii) block-level uncertainty and responsiveness quantities using fixed composition rules for XOR, OR, and LOOP routing constructs, and (iii) a bounded process-level viability-band reporting index. The framework is evaluated using four analytically constructed BPMN authorisation workflows designed to exercise the complete routing-construct taxonomy supported by the artifact. Results demonstrate that construct-level classifications, propagated uncertainty quantities, and process-level IEPI values are well defined and reproducible under fixed inputs. Threshold sensitivity analysis shows that local viability classifications and aggregate reporting outputs vary deterministically with threshold settings and remain consistent with the underlying routing diagnostics. The findings highlight the distinction between uncertainty propagation and viability-band compliance. While propagated uncertainty quantities characterize the accumulation of routing uncertainty within a process structure, the IEPI score provides a reporting-oriented assessment of aggregate compliance with analyst-defined viability criteria. The proposed artifact offers a reproducible and extensible analytical framework for routing-uncertainty evaluation in BPMN-based process models.

1. Introduction

Business Process Management (BPM) provides methods for modelling and structuring organisational workflows [1,2]. During process execution, routing constructs define alternative paths that introduce variability through branching behaviour [3,4]. BPMN 2.0 represents these control-flow structures explicitly [5], but does not provide a quantitative mechanism for evaluating uncertainty at routing constructs [6].

Existing BPM performance indicators primarily focus on dimensions such as time, cost, quality, compliance, and resource utilisation [7]. While these measures provide valuable operational information, they generally evaluate process outcomes rather than the uncertainty associated with routing behaviour itself. Consequently, routing variability is often represented implicitly rather than quantified directly.

Information-theoretic measures provide a natural mechanism for evaluating uncertainty in discrete systems. Shannon entropy and related measures have been widely used for uncertainty quantification across multiple domains [4,8,9]. Within BPM research, entropy-based approaches have been applied to process uncertainty and behavioural variability [6], demonstrating that routing behaviour can be analyzed through information-theoretic constructs. However, integrated BPMN analytics frameworks that combine routing diagnostics, viability assessment, uncertainty propagation, and process-level reporting remain comparatively limited [10].

The Information Entropy Performance Indicator (IEPI) has previously been introduced as a conceptual framework linking entropy and responsiveness in stochastic systems [11]. The present study operationalizes this concept as a deterministic BPMN analytics artifact that transforms process structure and routing probabilities into construct-level diagnostics, block-level uncertainty summaries, and a bounded viability-band reporting index through fixed analytical rules.

The remainder of the paper develops the analytical formulation of the IEPI engine, describes its implementation and evaluation protocol, and reports results obtained from BPMN process models containing XOR, OR, and LOOP routing constructs. The study focuses on deterministic evaluation under explicitly specified routing probabilities and examines the resulting construct-level diagnostics, block-level uncertainty propagation, process-level reporting outputs, and threshold-sensitivity behaviour.

2. Related Work and Research Gap

2.1. BPM Performance Measurement and Process Analytics

BPM provides a systematic framework for modelling, analysing, monitoring, and improving organisational processes [2,12]. Contemporary BPM research has expanded beyond traditional process documentation towards digital transformation, organisational adaptability, process intelligence, and process innovation [13,14,15]. As organisations increasingly rely on process-driven operations, the need for quantitative methods capable of supporting process evaluation and decision-making has become more pronounced.

Performance assessment in BPM is traditionally conducted through key performance indicators (KPIs) that focus on dimensions such as time, cost, quality, compliance, and resource utilisation [7]. These indicators provide valuable operational insights and remain essential for operational and strategic process management. However, they primarily evaluate process outcomes rather than the structural characteristics of process models themselves. Consequently, routing behaviour and the uncertainty associated with alternative execution paths are often treated implicitly rather than being quantified directly. This creates an opportunity for complementary analytical mechanisms that focus on process-structure characteristics while remaining distinct from traditional performance indicators.

2.2. Complexity and Uncertainty in Process Models

A substantial body of BPM research has examined process model complexity and its implications for process analysis and understandability. Early studies introduced control-flow complexity metrics and structural measures designed to evaluate the characteristics of process models and their execution logic [16,17]. Subsequent work demonstrated that branching structures influence process comprehensibility, maintainability, and analytical tractability [18]. However, complexity measures primarily quantify structural properties and are not generally designed to evaluate routing uncertainty as a distinct analytical quantity derived from execution-path probabilities.

Process variability introduces an additional analytical challenge. Routing constructs such as XOR, OR, and LOOP gateways create multiple potential execution paths whose selection depends on contextual or operational conditions. While BPMN 2.0 provides a standard notation for representing such routing structures [5], it does not provide a native mechanism for quantifying the uncertainty associated with branching behaviour. As a result, two processes with similar structural characteristics may exhibit substantially different routing behaviour depending on their underlying routing distributions, highlighting the distinction between structural complexity and routing uncertainty.

2.3. Entropy-Based Approaches to Process Uncertainty

Information-theoretic measures provide a natural framework for quantifying uncertainty in discrete systems. Shannon entropy remains the foundational measure for evaluating uncertainty associated with probability distributions [8]. Subsequent work has extended entropy-based analysis across numerous domains, demonstrating its usefulness for uncertainty quantification, information measurement, and decision-support applications [9].

Within BPM research, entropy has previously been applied to process models as a means of characterising uncertainty and behavioural variability. In particular, Jung et al. [6] introduced an entropy-based uncertainty measure for process models, demonstrating that routing behaviour can be analysed through information-theoretic constructs. More recently, a systematic literature review of BPM and information entropy research identified growing interest in entropy-based process analysis while simultaneously highlighting methodological fragmentation and limited operational integration of entropy-based metrics into BPM frameworks [10].

While Jung et al. [6] demonstrated that entropy can be used to quantify uncertainty in process models, the objective of the present work differs in scope and emphasis. Rather than proposing a standalone uncertainty measure, the IEPI framework provides a deterministic BPMN analytics engine that combines construct-level routing diagnostics, viability assessment, diagnostic flagging, compositional uncertainty propagation, and process-level reporting within a unified computational framework. Consequently, the present study builds upon existing entropy-based BPM analysis by integrating routing diagnostics, viability assessment, diagnostic validation, compositional uncertainty propagation, and process-level reporting into an operational routing-uncertainty evaluation artifact rather than proposing a new entropy measure.

Although existing studies demonstrate the applicability of entropy-based measures to process analysis, most approaches focus on uncertainty estimation, complexity assessment, or conceptual discussions of process variability. To the best of the authors’ knowledge, comparatively few BPMN-oriented analytical frameworks integrate construct-level routing diagnostics, viability assessment, compositional uncertainty propagation, diagnostic validation mechanisms, and process-level reporting within a single computational workflow.

2.4. Research Gap and Contribution

The preceding discussion indicates that BPM research offers established approaches for performance measurement, process modelling, complexity analysis, and entropy-based uncertainty assessment, each addressing different aspects of process analysis and evaluation. However, the integration of construct-level routing diagnostics, viability assessment, compositional uncertainty propagation, diagnostic validation mechanisms, and process-level uncertainty reporting within a unified BPMN analytics framework remains comparatively underexplored in the BPM literature.

To address this limitation, this study formulates the IEPI as a deterministic BPMN routing-uncertainty analytics artifact for BPMN 2.0 process models. The IEPI engine accepts a process representation, a routing-probability map, and predefined viability thresholds as inputs and produces (i) construct-level diagnostics, (ii) block-level propagated uncertainty quantities, and (iii) a bounded process-level reporting index. The transformation from process structure and routing probabilities to analytical outputs is governed by fixed composition and aggregation rules.

The objective of the proposed framework is not to predict process outcomes, optimise process performance, or infer routing behaviour from execution logs. Rather, it provides a deterministic mechanism for evaluating routing uncertainty under explicitly specified probability assignments. In this regard, the contribution of the study is positioned as a BPM analytics artifact that operationalizes routing-uncertainty assessment through the integration of construct-level diagnostics, viability assessment, compositional uncertainty propagation, diagnostic validation, and process-level reporting within BPMN process representations.

The principal contribution of this study is not the introduction of a new entropy measure, but the formulation of a deterministic BPM analytics artifact that integrates construct-level routing diagnostics, responsiveness assessment, viability-band evaluation, compositional uncertainty propagation, diagnostic validation mechanisms, and process-level reporting within a unified BPMN-oriented computational workflow. The evaluation scenarios introduced later in the paper are designed to exercise the principal BPMN routing constructs supported by the artifact, namely XOR, OR, and LOOP routing behaviour, under controlled and reproducible probability configurations.

3. Materials and Methods

3.1. IEPI Engine Overview

The IEPI framework is formulated as a deterministic analytics engine that transforms a BPMN 2.0 process representation and an externally specified routing-probability map into construct-level, block-level, and process-level uncertainty outputs. The engine does not estimate probabilities, learn from event logs, predict process outcomes, or optimise process behaviour. Instead, it evaluates routing uncertainty under explicitly defined inputs and fixed analytical rules.

The computation proceeds in four stages. First, routing constructs are identified from the control-flow representation and associated with externally specified probability distributions. Second, construct-level quantities are computed for each routing construct, including normalized entropy $H_N\left(c\right)$, responsiveness $R\left(c\right)$, viability classification $\kappa \left(c\right)$, and diagnostic flags $f\left[c\right]$. Third, block-level uncertainty and responsiveness quantities, $U\left(B\right)$ and $R\left(B\right)$, are obtained through bottom-up application of the IEPI composition rules. Fourth, construct-level violations are aggregated into the bounded process-level reporting index $\mathrm{IEPI}$, which summarizes compliance with the specified viability criteria at the process level.

This staged structure separates local routing diagnostics from block-level propagation and process-level reporting. Consequently, the IEPI score should be interpreted as a deterministic viability-band reporting index derived from routing-uncertainty diagnostics rather than as an empirical performance measure, predictive model, process-complexity metric, or optimisation objective.

3.2. Data Sources and Process Selection

The scenarios were intentionally designed as controlled reference cases for evaluating the behaviour of the IEPI analytics artifact under different routing topologies. They do not represent the execution logs or operational data of a specific organisation; rather, they provide analytically tractable BPMN structures that enable reproducible evaluation of construct-level diagnostics, uncertainty propagation, and process-level viability reporting across the routing constructs supported by the framework. All scenarios follow segregation-of-duties principles commonly employed in accounting and financial-control environments [19].

The evaluation design consists of four structurally related BPMN workflows that collectively exercise the routing constructs supported by the IEPI framework. Scenarios A and B employ Exclusive Gateways (XOR), Scenario C introduces an Inclusive Gateway (OR), and Scenario D introduces a LOOP construct. Maintaining a common accounting authorisation context controls for domain-specific variation and isolates the effects of routing topology on the analytical outputs produced by the IEPI engine.

The four processes are defined as follows.

• Scenario A: Two-Level Accounting authorisation Workflow (Fixed Approvers).

This process represents a hierarchical two-stage financial authorisation structure enforcing segregation of duties. It consists of two sequential Exclusive Gateways (XOR) and three terminal states, with no concurrency, OR-splits, or loops. The topology is strictly acyclic with a structural depth of two decision levels. Authorisation requires sequential approval by a Financial Controller (Level 1) followed by a Finance Director or CFO (Level 2), while any rejection results in immediate termination. The BPMN representation of Scenario A is shown in Figure 1.

• Scenario B: Two-Level Accounting authorisation with LDAP-Based Approver Determination.

This variant extends the baseline workflow by introducing an additional Exclusive Gateway (XOR) preceding the approval hierarchy. A service task determines the identities of the responsible approvers via an enterprise directory query using the Lightweight Directory Access Protocol (LDAP) prior to human decision-making. The process therefore contains three sequential XOR gateways and four terminal states, with no concurrency, OR-splits, or loops. The topology remains strictly acyclic with a structural depth of three decision levels. The BPMN representation of Scenario B is shown in Figure 2.

• Scenario C: Accounting authorisation with Optional Compliance Review (OR Routing).

This variant extends the baseline authorisation workflow by introducing an Inclusive Gateway (OR) following the initial validation stage. Depending on the characteristics of the authorisation request, the process may initiate an additional compliance review, proceed directly to authorisation preparation, or execute both activities before synchronization and continuation to the approval hierarchy. The process therefore contains one Inclusive Gateway (OR), one corresponding OR-join, and two subsequent Exclusive Gateways (XOR) governing the approval hierarchy. Unlike the XOR-only scenarios, multiple branches may be activated concurrently before synchronization at the OR-join. The topology remains acyclic and introduces an additional routing layer associated with optional review activities while preserving the underlying accounting authorisation semantics. The BPMN representation of Scenario C is shown in Figure 3.

• Scenario D: Accounting authorisation with Rework and Resubmission Loop (LOOP Routing).

This variant extends the baseline authorisation workflow by introducing an explicit LOOP construct preceding the approval hierarchy. Following the initial validation stage, authorisation requests that fail verification are returned for correction and review. A subsequent routing decision determines whether the corrected request is resubmitted for revalidation or withdrawn from further processing. The process therefore contains a cyclic routing structure in addition to the two subsequent Exclusive Gateways (XOR) governing the approval hierarchy. Unlike the acyclic scenarios, requests may traverse the validation stage multiple times before progressing to authorisation or exiting the process. The topology introduces iterative routing behaviour while preserving the underlying accounting authorisation semantics. The BPMN representation of Scenario D is shown in Figure 4.

The scenarios were selected based on structural criteria relevant to deterministic entropy-based evaluation. Scenarios A and B provide controlled XOR-only process structures of increasing routing depth, enabling examination of the effect of introducing an additional decision layer under otherwise comparable governance semantics. Scenario C demonstrates the behaviour of the IEPI engine under OR routing semantics, whereas Scenario D evaluates cyclic process behaviour through LOOP routing.

This evaluation design enables assessment of construct-level diagnostics, block-level uncertainty propagation, and process-level viability reporting across XOR, OR, and LOOP routing structures while maintaining a common accounting authorisation context. Consequently, observed differences in construct-level diagnostics, propagated uncertainty quantities, and IEPI reporting outputs can be attributed primarily to routing topology and probability assignments rather than to differences in process domain or business objective.

3.3. Process Representation

The BPMN 2.0 models described in Section 3.1 are transformed into a deterministic control-flow representation suitable for IEPI computation. In this representation, only control-flow semantics and supported routing constructs are retained, while presentation-layer elements such as pools, lanes, message flows, and user-interface annotations are excluded [20].

Let $\mathcal{C}$ denote the set of routing constructs extracted from the control-flow structure.

The IEPI engine supports Exclusive (XOR), Inclusive (OR), and LOOP routing constructs. The resulting abstraction corresponds to a directed control-flow graph composed of atomic tasks and routing constructs. Atomic tasks represent operational activities that do not introduce routing uncertainty and therefore contribute zero uncertainty and zero responsiveness under the IEPI framework. Routing uncertainty arises exclusively from routing constructs that define alternative execution paths.

The evaluation scenarios exercise the complete routing-construct taxonomy currently supported by the IEPI engine. Scenarios A and B contain only Exclusive Gateways (XOR), Scenario C introduces an Inclusive Gateway (OR), and Scenario D introduces a LOOP construct through an explicit rework and resubmission cycle. Consequently, the evaluation includes both acyclic and cyclic routing structures.

Under this abstraction, uncertainty and responsiveness quantities are computed locally at each routing construct and subsequently aggregated according to the IEPI composition rules. These intermediate quantities support construct-level diagnostics, block-level uncertainty propagation, and the process-level viability-band reporting outputs produced by the IEPI engine. Scenarios A, B, and C remain acyclic and therefore support direct bottom-up aggregation of construct-level quantities. Scenario D contains a cyclic routing structure whose uncertainty contribution is evaluated using the LOOP formulation defined in Section 3.5. This representation permits consistent evaluation across XOR, OR, and LOOP routing semantics while preserving the underlying BPMN control-flow structure and providing a common computational basis for construct-level diagnostics, uncertainty propagation, and process-level viability reporting.

3.4. Probability Assignment Strategy

The IEPI engine requires an explicit discrete probability assignment for every routing construct in the control-flow structure. For a routing construct with k outgoing alternatives, routing behaviour is represented by a categorical probability vector $p=(p_1,\dots ,p_k)$ with $p_i\ge 0$ and ${\sum }_{i=1}^k{p}_i=1$ [8]. These probabilities represent the likelihood of selecting each branch when the construct is encountered.

Routing probabilities are supplied externally and are not estimated, learned, or inferred by the IEPI engine. The artifact performs only deterministic evaluation of uncertainty and responsiveness given the provided inputs. Consequently, the IEPI framework separates probability specification from uncertainty evaluation and may operate on routing distributions obtained from different sources.

Probability assignments may originate from three sources:

• Event log frequencies. Empirical execution traces may be used to compute branch frequencies.
• Simulation outputs. Routing frequencies generated by process simulation models may be used when operational data are unavailable.
• Expert elicitation. Domain experts may specify routing probabilities based on operational knowledge.

For the purposes of artifact evaluation, routing probabilities may also be specified analytically in order to create controlled reference scenarios. Such assignments permit reproducible examination of the deterministic behaviour of the IEPI engine under known routing conditions and facilitate systematic exploration of different uncertainty and viability profiles. In this case, probability assignments are selected to exercise the behaviour of the IEPI engine under different routing conditions, uncertainty levels, and viability-band outcomes rather than to represent observed operational frequencies. This approach is consistent with the objective of evaluating the deterministic properties of the analytics artifact independently of probability-estimation procedures.

All probability vectors must satisfy definability constraints, specifically non-negativity and unit sum. The IEPI engine validates these conditions prior to computation. Invalid or missing probability assignments are flagged and excluded from IEPI aggregation rather than corrected or imputed.

For the evaluation scenarios in Section 3.1, routing probabilities are specified explicitly as fixed input parameters for each routing construct. The selected values are intended to create controlled routing conditions with different entropy and responsiveness profiles across XOR, OR, and LOOP structures and therefore serve as analytical inputs to the evaluation rather than estimates of organisational behaviour. These probabilities are used directly in the IEPI computation under the specified threshold configuration and are not obtained through statistical estimation, machine learning, process mining, or inference procedures. To assess the robustness of the resulting classifications and reporting outputs, a threshold sensitivity analysis is subsequently performed under fixed routing probabilities, as examined through the threshold sensitivity analysis presented later in the evaluation.

3.5. IEPI Definition

3.5.1. Routing Probability Model

All uncertainty quantities are defined over discrete random variables with finite support. For a routing construct with $k\ge 2$ outgoing alternatives, let

$$p=(p_1,\dots ,p_k)\in {\Delta }_{k-1},{\Delta }_{k-1}=\left\{p\in {\mathbb{R}}_{\ge 0}^k:{\displaystyle \sum _{i=1}^k}{p}_i=1\right\},$$

denote the categorical routing probabilities.

For each routing construct $c\in \mathcal{C}$, the associated routing distribution is denoted by $p^{\left(c\right)}$.

The Shannon entropy of p is defined as

$$H\left(p\right)=-{\displaystyle \sum _{i=1}^k}{p}_{i}log{p}_i,(0log0:=0),$$

(1)

where logarithms are taken to the natural base. The entropy satisfies $0\le H\left(p\right)\le logk$, with equality at the uniform distribution.

To enable comparability across routing constructs of varying arity, entropy is normalized as

$$H_N\left(p\right)={\displaystyle \frac{H\left(p\right)}{logk}}\in [0,1].$$

(2)

For each routing construct $c\in \mathcal{C}$, define

$$H\left(c\right):=H\left(p^{\left(c\right)}\right),H_N\left(c\right):=H_N\left(p^{\left(c\right)}\right).$$

Normalized entropy $H_N$ is used exclusively for construct-level comparability, viability classification, and IEPI scoring. Uncertainty propagation within the IEPI engine uses the unnormalized entropy terms defined in the composition rules.

3.5.2. Responsiveness Measure and Entropy Consistency

To quantify routing dispersion without introducing parametric assumptions, the engine uses the collision-based (Gini–Simpson) responsiveness measure:

$$R\left(p\right)=1-{\displaystyle \sum _{i=1}^k}{p}_i^2,R\left(p\right)\in \left[0,1-{\displaystyle \frac{1}{k}}\right].$$

(3)

For each routing construct $c\in \mathcal{C}$, define

$$R\left(c\right):=R\left(p^{\left(c\right)}\right).$$

The corresponding Rényi-2 (collision) entropy is

$$H_2\left(p\right)=-log\left({\displaystyle \sum _{i=1}^k}{p}_i^2\right)=-log\left(1-R\left(p\right)\right).$$

For all categorical distributions $p\in {\Delta }_{k-1}$, Shannon entropy is lower-bounded by the collision entropy:

$$H\left(p\right)\ge -log\left(1-R\left(p\right)\right).$$

(4)

Within the IEPI engine, Equation (4) is used only as a diagnostic coherence check. Violations indicate numerical inconsistencies (up to floating-point tolerance), malformed probability inputs (e.g., negative entries or ${\sum }_i{p}_i\ne 1$), or mismatched probability assignments due to mapping or indexing errors. No penalties are applied.

3.5.3. Viability Band

Let $0\le H_{min}<H_{max}\le 1$ denote the normalized entropy thresholds and let ${\rho }_{min}>0$ denote the minimum responsiveness threshold. A routing construct is classified as under-responsive if $R\left(c\right)<{\rho }_{min}$, under-uncertain if $H_N\left(c\right)<H_{min}$, and over-uncertain if $H_N\left(c\right)>H_{max}$.

A routing construct is classified as viable when

$$H_{min}\le H_N\left(c\right)\le H_{max},R\left(c\right)\ge {\rho }_{min}.$$

(5)

All classifications are evaluated locally at each routing construct $c\in \mathcal{C}$.

For loop constructs, the same viability criteria apply using the normalized Bernoulli entropy

$$H_N\left(q\right)={\displaystyle \frac{H\left(q\right)}{log2}},$$

and the loop responsiveness measure

$$R\left(q\right)=q(1-q).$$

Since $R\left(q\right)$ attains its maximum at $q=\frac{1}{2}$, it is bounded by

$$R\left(q\right)\le {\displaystyle \frac{1}{4}}.$$

Consequently, loop viability requires ${\rho }_{min}\le \frac{1}{4}$.

The corresponding Bernoulli collision term satisfies

$$q^2+{(1-q)}^2=1-2R\left(q\right).$$

3.5.4. Block-Level Quantities

Each process fragment (block) B is associated with two scalar quantities:

$$U\left(B\right)(\mathrm{uncertainty}\mathrm{contribution}),R\left(B\right)(\mathrm{responsiveness}\mathrm{summary}).$$

For atomic, non-routing blocks, the engine sets

$$U\left(B\right)=0,R\left(B\right)=0.$$

Uncertainty $U\left(B\right)$ represents an expected-value accumulation across the process structure. Responsiveness $R\left(B\right)$ represents a descriptive aggregation of routing dispersion induced by the routing constructs associated with the block.

Under sequential or parallel composition (SEQ/AND), responsiveness aggregates additively across sub-blocks.

Unlike $U\left(B\right)$, responsiveness is not propagated through routing constructs as an expected-value quantity. Viability evaluation is defined exclusively at the routing-construct level via $R\left(c\right)$. Accordingly, the block-level quantity $R\left(B\right)$ serves only as a descriptive summary and does not participate in viability assessment or IEPI scoring.

3.5.5. Composition Rules and Closure

The composition rules follow an entropy-based decomposition of process uncertainty over primitive control-flow patterns, where uncertainty is expressed as a combination of routing entropy and expected sub-block contributions [6]. The IEPI engine adopts this structural formulation and extends it with normalized entropy, responsiveness measures, and deterministic aggregation rules.

Let ${\left\{B_g\right\}}_{g=1}^G$ denote the immediate sub-blocks following a routing construct $c\in \mathcal{C}$ and let $p^{\left(c\right)}=\left(p_g\right)$ denote the associated routing distribution.

The IEPI engine evaluates block-level uncertainty $U(·)$ and responsiveness $R(·)$ according to the following composition rules.

Sequential/parallel composition (SEQ/AND).

$$\begin{array}{cc}\hfill U(\mathrm{SEQ}/\mathrm{AND})& ={\displaystyle \sum _{g=1}^G}U\left(B_g\right),\hfill \\ \hfill R(\mathrm{SEQ}/\mathrm{AND})& ={\displaystyle \sum _{g=1}^G}R\left(B_g\right).\hfill \end{array}$$

(6)

Exclusive choice (XOR).

$$\begin{array}{cc}\hfill U\left(\mathrm{XOR}\right)& =H\left(p^{\left(c\right)}\right)+{\displaystyle \sum _{g=1}^G}{p}_{g}U\left(B_g\right),\hfill \\ \hfill R\left(\mathrm{XOR}\right)& =1-{\displaystyle \sum _{g=1}^G}{p}_g^2.\hfill \end{array}$$

(7)

Inclusive choice (OR).

For OR routing constructs, propagated uncertainty is evaluated using the collision-entropy surrogate:

$$\begin{array}{cc}\hfill U\left(\mathrm{OR}\right)& =H_2\left(p^{\left(c\right)}\right)+{\displaystyle \sum _{g=1}^G}{p}_{g}U\left(B_g\right),\hfill \\ \hfill R\left(\mathrm{OR}\right)& =1-{\displaystyle \sum _{g=1}^G}{p}_g^2.\hfill \end{array}$$

(8)

Here $p^{\left(c\right)}$ denotes a normalized marginal activation vector in ${\Delta }_{k-1}$ used for local comparability rather than a joint activation distribution. The vector may be derived from observed activations or expert elicitation. For OR routing constructs, $H_N\left(p^{\left(c\right)}\right)$ is used for profile-level comparability, while block-level propagation employs the collision-entropy surrogate $H_2$, consistent with the responsiveness measure.

Loop construct (LOOP).

Let $q\in (0,1)$ denote the continuation probability of a loop and $B_{\mathrm{body}}$ its body. The engine adopts a 0-or-more execution semantics, in which the loop body may execute zero or more times with continuation probability q after each iteration.

Under this assumption, the expected contributions are

$$\begin{array}{cc}\hfill U\left(\mathrm{LOOP}\right)& =H\left(q\right)+{\displaystyle \frac{q}{1-q}}U\left(B_{\mathrm{body}}\right),\hfill \\ \hfill R\left(\mathrm{LOOP}\right)& =q(1-q).\hfill \end{array}$$

(9)

where $H\left(q\right)=-qlogq-(1-q)log(1-q)$.

For diagnostic purposes, entropy–responsiveness coherence for loops uses the Bernoulli collision term

$$H_2\left(q\right)=-log\left(q^2+{(1-q)}^2\right)=-log\left(1-2R\left(q\right)\right).$$

Given valid probability assignments for all routing constructs, the SEQ/AND, XOR, OR, and LOOP composition rules (Equations (6)–(9)) yield well-defined uncertainty and responsiveness quantities $U(·)$ and $R(·)$. Viability is evaluated locally at each routing construct $c\in \mathcal{C}$ by comparing the corresponding normalized entropy and responsiveness measures against the prescribed thresholds defined in Equation (5).

The IEPI engine applies these rules over the process representation to produce construct-level routing diagnostics, block-level uncertainty summaries, and a process-level viability-band reporting index.

3.5.6. Single-Score IEPI Aggregation (Reporting Index)

Let $\mathcal{C}$ denote the set of routing constructs in a BPMN model. Routing constructs without valid probability assignments are flagged as incomplete probability coverage. Define the subset of constructs with valid inputs as

$${\mathcal{C}}_{\mathrm{valid}}=\{c\in \mathcal{C}:H_N\left(c\right)\mathrm{and}R\left(c\right)\mathrm{are}\mathrm{defined}\mathrm{from}\mathrm{valid}\mathrm{inputs}\}.$$

The IEPI score is computed over ${\mathcal{C}}_{\mathrm{valid}}$ and reported together with probability-coverage flags.

For each routing construct $c\in {\mathcal{C}}_{\mathrm{valid}}$, let $H_N\left(c\right)\in [0,1]$ denote the normalized entropy and let $R\left(c\right)$ denote the responsiveness measure. Given thresholds $0\le H_{min}<H_{max}\le 1$ and ${\rho }_{min}>0$, define the non-negative violation terms

$$v_H^{-}\left(c\right)={\left[H_{min}-H_N\left(c\right)\right]}_{+},v_H^{+}\left(c\right)={\left[H_N\left(c\right)-H_{max}\right]}_{+},v_R\left(c\right)={\left[{\rho }_{min}-R\left(c\right)\right]}_{+},$$

where ${\left[x\right]}_{+}=max\{x,0\}$. The total violation at routing construct c is

$$V\left(c\right)=v_H^{-}\left(c\right)+v_H^{+}\left(c\right)+v_R\left(c\right).$$

If $|{\mathcal{C}}_{\mathrm{valid}}|=0$, the process contains no routing constructs with defined probability inputs and the IEPI score is set to $\mathrm{IEPI}=1$ by definition. Probability-coverage flags distinguish between routing-free models and cases of missing probability assignments.

The process-level IEPI score is intended as a bounded viability-band reporting index taking values in $(0,1]$ that summarizes the average deviation of routing constructs from the prescribed viability criteria. The transformation from average violation to a unit-bounded score was selected to satisfy five design requirements: (i) boundedness within the interval $(0,1]$, (ii) monotonic decrease as average violation increases, (iii) preservation of the ideal state $\mathrm{IEPI}=1$ when no violations occur, (iv) computational simplicity and interpretability, and (v) deterministic reproducibility without calibration parameters. The resulting score is therefore intended as a reporting measure of routing-uncertainty viability rather than as a statistical estimator, predictive model, or operational performance metric.

Otherwise, define the average violation

$$\overline{V}={\displaystyle \frac{1}{|{\mathcal{C}}_{\mathrm{valid}}|}}\sum _{c\in {\mathcal{C}}_{\mathrm{valid}}}V\left(c\right).$$

(10)

and map it to a bounded scalar score in $(0,1]$ via

$$\mathrm{IEPI}={\displaystyle \frac{1}{1+\overline{V}}}.$$

(11)

The mapping in Equation (11) is adopted as a reporting transformation because it is continuous, strictly monotonic, bounded on $(0,1]$, preserves the ordering induced by $\overline{V}$, and introduces no additional calibration parameters. The analytical content of the framework remains contained in the construct-level violation terms $V\left(c\right)$ and their aggregate $\overline{V}$, while the IEPI score provides a normalized reporting representation of aggregate viability-band compliance.

The reciprocal transformation in Equation (11) ensures that increasing average violation produces progressively lower scores while preserving a fixed upper bound of one. Because the mapping depends only on the aggregated violation quantity, the resulting score is straightforward to interpret: larger deviations from the prescribed viability thresholds correspond to lower IEPI values. Consequently, the IEPI score should be interpreted as a measure of aggregate viability-band compliance rather than as a direct measure of propagated uncertainty, routing complexity, or process performance. The transformation is used solely for process-level reporting and does not affect construct-level diagnostics, block-level uncertainty propagation, or viability classification.

The reciprocal mapping is not claimed to be uniquely optimal. Rather, it is adopted as a parameter-free, monotone, bounded transformation that satisfies the design requirements stated above while avoiding the introduction of calibration parameters. Alternative monotone transformations, such as exponential or logistic mappings, could be investigated in future extensions of the framework. The present formulation employs Equation (11) to preserve deterministic reproducibility and maintain a transparent relationship between average violation magnitude and the reported IEPI value.

Thus, $\mathrm{IEPI}=1$ indicates that all scored routing constructs satisfy the viability band ($H_{min}\le H_N\left(c\right)\le H_{max}$ and $R\left(c\right)\ge {\rho }_{min}$), while decreasing values indicate increasing average deviation from the prescribed range.

Local quantities $(H_N\left(c\right),R\left(c\right))$, block-level quantities $\left(U\right(B),R(B\left)\right)$, and the aggregate IEPI score are defined on distinct analytical levels and serve different analytical purposes. Routing diagnostics characterize individual routing constructs, block-level quantities summarize propagated uncertainty within the process structure, and the IEPI score provides a process-level viability-band reporting summary derived from construct-level violations.

3.6. IEPI Engine Implementation

3.6.1. IEPI Engine Overview and Interface

The IEPI Engine constitutes the reference implementation of the proposed IEPI framework. It operates on a predefined control-flow block representation of a BPMN 2.0 process model, together with a routing-construct probability map and viability thresholds $(H_{min},H_{max},{\rho }_{min})$. The control-flow structure contains supported routing constructs (XOR, OR, LOOP), to which probabilities are externally assigned. For OR routing constructs, probabilities are represented as normalized marginal activation vectors in ${\Delta }_{k-1}$ used for local comparability rather than joint activation distributions over branch combinations. The engine does not perform BPMN parsing; instead, it evaluates a structured representation derived from the process model.

The computational workflow of the IEPI reference implementation is summarized in Algorithms 1 and 2, which describe the deterministic evaluation procedure from probability ingestion to process-level reporting.

Algorithm 1 IEPI Engine (reference computation over a predefined block structure), Part I: probability ingestion and local profiles

Input: predefined block decomposition $\mathcal{B}$; routing-probability map $\mathcal{P}$; thresholds $(H_{min},H_{max},{\rho }_{min})$ Output: routing constructs $\mathcal{C}$; per-construct profiles $\mathrm{\Pi }$   1: Identify supported routing constructs $\mathcal{C}\subset \mathcal{B}$ Possible diagnostic flag states include valid, invalid probability input, missing probability assignment, and diagnostic consistency warnings.   2: for all  $c\in \mathcal{C}$  do   3:       Initialize diagnostic flag $f\left[c\right]\leftarrow$ valid   4:       if c is XOR or OR routing construct then   5:             Retrieve routing vector $p^{\left(c\right)}\leftarrow \mathcal{P}\left[c\right]$   6:             if $p^{\left(c\right)}$ violates probability constraints then   7:                 Set $f\left[c\right]\leftarrow$ invalid probability input   8:                 continue   9:             end if 10:             Let $k\leftarrow |p^{\left(c\right)}|$ 11:             Compute $H_N\left(c\right)\leftarrow H\left(p^{\left(c\right)}\right)/logk$ 12:             Compute $R\left(c\right)\leftarrow 1-{\sum }_i{\left(p_i^{\left(c\right)}\right)}^2$ 13:       else if c is LOOP routing construct then 14:             Retrieve continuation probability $q\leftarrow \mathcal{P}\left[c\right]$ 15:             if q violates probability constraints then 16:                  Set $f\left[c\right]\leftarrow$ invalid probability input 17:                  continue 18:             end if 19:             Compute $H_N\left(c\right)\leftarrow H\left(q\right)/log2$ 20:             Compute $R\left(c\right)\leftarrow q(1-q)$ 21:        end if 22:        Assign viability class $\kappa \left(c\right)$ using $(H_{min},H_{max},{\rho }_{min})$ 23:        Store $\mathrm{\Pi }\left[c\right]\leftarrow (H_N\left(c\right),R\left(c\right),\kappa \left(c\right),f\left[c\right])$ 24: end for 25: return $\mathcal{C}$ and $\mathrm{\Pi }$

Algorithm 2 IEPI Engine (reference computation over a predefined block structure), Part II: block propagation and reporting score

Prerequisites: predefined block decomposition $\mathcal{B}$, routing constructs $\mathcal{C}$, probability map $\mathcal{P}$, and profiles $\mathrm{\Pi }\left[c\right]$ Block propagation (bottom-up).   1: ${\mathcal{B}}_{\uparrow }\leftarrow BottomUpOrder\left(\mathcal{B}\right)$   2: for all  $B\in {\mathcal{B}}_{\uparrow }$  do   3:       if B is SEQ/AND with children $B_g\ast {g=1}^G$ then   4:          $U\left(B\right)\leftarrow \sum \ast {g=1}^{G}U\left(B_g\right)$   5:          $R\left(B\right)\leftarrow {\sum }_{g=1}^{G}R\left(B_g\right)$   6:       else if B is XOR with routing construct c and children $B_g\ast {g=1}^G$ then   7:          Retrieve routing vector $p_c\leftarrow \mathcal{P}\left[c\right]$   8:          $U\left(B\right)\leftarrow H\left(p_c\right)+\sum \ast {g=1}^G{p}_{c,g},U\left(B_g\right)$   9:          $R_{\mathrm{local}}\left(c\right)\leftarrow 1-{\sum }_{g=1}^G{\left(p_{c,g}\right)}^2$ 10:          $R\left(B\right)\leftarrow R_{\mathrm{local}}\left(c\right)+{\sum }_{g=1}^{G}R\left(B_g\right)$ 11:       else if B is OR with routing construct c and children $B_g\ast {g=1}^G$ then 12:          Retrieve routing vector $p_c\leftarrow \mathcal{P}\left[c\right]$ 13:          $H_2\left(p_c\right)\leftarrow -log!\left(\sum \ast {g=1}^G{\left(p_{c,g}\right)}^2\right)$ 14:          $U\left(B\right)\leftarrow H_2\left(p_c\right)+{\sum }_{g=1}^G{p}_{c,g},U\left(B_g\right)$ 15:          $R_{\mathrm{local}}\left(c\right)\leftarrow 1-{\sum }_{g=1}^G{\left(p_{c,g}\right)}^2$ 16:          $R\left(B\right)\leftarrow R_{\mathrm{local}}\left(c\right)+{\sum }_{g=1}^{G}R\left(B_g\right)$ 17:       else if B is LOOP with routing construct c and body $B_{\mathrm{body}}$ then 18:          Retrieve continuation probability $q\leftarrow \mathcal{P}\left[c\right]$ 19:          $H\left(q\right)\leftarrow -qlogq-(1-q)log(1-q)$ 20:          $U\left(B\right)\leftarrow H\left(q\right)+{\displaystyle \frac{q}{1-q}},U\left(B_{\mathrm{body}}\right)$ 21:          $R_{\mathrm{local}}\left(c\right)\leftarrow q(1-q)$ 22:          $R\left(B\right)\leftarrow R_{\mathrm{local}}\left(c\right)+R\left(B_{\mathrm{body}}\right)$ 23:       else 24:          $U\left(B\right)\leftarrow 0$ 25:          $R\left(B\right)\leftarrow 0$ 26:       end if 27: end for Single-score IEPI (reporting-only). The IEPI score is a bounded reporting index derived from the average viability-band violation across routing constructs. 28: ${\mathcal{C}}_{\mathrm{valid}}\leftarrow c\in \mathcal{C}:\mathrm{\Pi }\left[c\right]\mathrm{defines}{H}_N\left(c\right)\mathrm{and}R\left(c\right)$ 29: if   $|{\mathcal{C}}_{\mathrm{valid}}|=0$  then 30:       $\mathrm{IEPI}\leftarrow 1$ 31: else 32:       $\overline{V}\leftarrow 0$ 33:       for all $c\in \mathcal{C}\ast \mathrm{valid}$ do 34:          $V\left(c\right)\leftarrow [H\ast min-H_N\left(c\right)]\ast ++[H_N\left(c\right)-H\ast max]\ast ++{[\rho \ast min-R\left(c\right)]}_{+}$ 35:          $\overline{V}\leftarrow \overline{V}+V\left(c\right)$ 36:       end for 37:       $\overline{V}\leftarrow \overline{V}/\left|{\mathcal{C}}_{\mathrm{valid}}\right|$ 38:       $\mathrm{IEPI}\leftarrow 1/(1+\overline{V})$ 39: end if The reciprocal transformation preserves $\mathrm{IEPI}=1$ under zero violation and decreases monotonically as average violation increases. 40: return $\mathrm{\Pi }$, ${U\left(B\right),R\left(B\right)}_{B\in \mathcal{B}}$, and $\mathrm{IEPI}$

Computation proceeds in two stages. First, per-construct quantities $(H_N\left(c\right),R\left(c\right))$ and the corresponding viability classification $\kappa \left(c\right)$, together with diagnostic flags $f\left[c\right]$, are computed for each routing construct c. Second, block-level quantities $\left(U\right(B),R(B\left)\right)$ are obtained through bottom-up application of the composition rules over the control-flow structure.

The outputs consist of the per-construct profile $\mathrm{\Pi }\left[c\right]=(H_N\left(c\right),R\left(c\right),\kappa \left(c\right),f\left[c\right])$, the propagated block-level quantities $\left(U\right(B),R(B\left)\right)$, and the process-level viability-band reporting index $\mathrm{IEPI}\in (0,1]$, computed over the valid construct subset ${\mathcal{C}}_{\mathrm{valid}}$.

The evaluation scenarios presented in Section 3.1 exercise all routing constructs currently supported by the reference implementation. Scenarios A and B evaluate XOR routing behaviour, Scenario C evaluates OR routing behaviour, and Scenario D evaluates LOOP routing behaviour. Consequently, the evaluation demonstrates the complete computational workflow of the IEPI engine across all routing constructs currently supported by the framework.

In this formulation, block-level responsiveness is reported as a descriptive aggregation of local routing responsiveness across the process structure and serves as an auxiliary analytical quantity for process interpretation. Viability assessment is performed exclusively at the routing-construct level through the measures $(H_N\left(c\right),R\left(c\right))$, while the process-level IEPI score is derived solely from construct-level viability-band violations. Consequently, block-level responsiveness does not participate directly in viability classification or IEPI scoring and is reported only as a supplementary summary of routing dispersion within the process structure.

3.6.2. Implementation Details and Reproducibility

A reference implementation of the IEPI engine is provided as open-source Python 3.13 code in a public repository [21]. The implementation covers probability validation, construct-level routing diagnostics, viability classification, diagnostic flag generation, block-level uncertainty propagation, and process-level viability-band reporting based on predefined control-flow block structures.

The reference implementation operates on explicitly specified block representations and externally provided routing probabilities. It does not include BPMN 2.0 XML parsing, process discovery, probability estimation, machine-learning components, or process-mining functionality. These capabilities are intentionally outside the scope of the present work, whose objective is the deterministic evaluation of routing uncertainty given a predefined process structure and routing-probability map.

All outputs are deterministic functions of the supplied process representation, routing probabilities, and threshold configuration. The public availability of the implementation supports computational reproducibility and enables independent verification of the construct-level diagnostics, block-level quantities, and IEPI reporting outputs presented in this study.

3.7. Evaluation Design

3.7.1. Purpose and Scope of Evaluation

This section specifies the evaluation protocol used to assess the IEPI engine as a deterministic analytics artifact. The evaluation focuses on four aspects relevant to the behaviour of the IEPI analytics artifact: (i) computation and definability of the routing-construct diagnostics $\mathrm{\Pi }\left[c\right]=(H_N\left(c\right),R\left(c\right),\kappa \left(c\right),f\left[c\right])$, (ii) behaviour of the block-level quantities $\left(U\right(B),R(B\left)\right)$ under the supported routing semantics, (iii) process-level differentiation achieved by the reporting-only IEPI score under fixed threshold settings, and (iv) sensitivity of local viability classifications and the aggregated IEPI score to controlled variations of viability thresholds and routing distributions. The evaluation does not address learning, prediction, optimisation, process redesign, process mining, or causal interpretation.

3.7.2. Evaluation Inputs and Process Set

The evaluation uses predefined control-flow block representations derived from BPMN 2.0 process models, a routing-probability map $\mathcal{P}$ keyed by routing-construct identifier, and fixed viability thresholds $(H_{min},H_{max},{\rho }_{min})$. Routing probabilities are externally specified and may originate from event-log frequencies, simulation outputs, expert elicitation, or analytically defined reference scenarios. All probability inputs are validated for non-negativity and unit sum. Invalid or missing probability assignments are flagged and excluded from the valid construct set ${\mathcal{C}}_{\mathrm{valid}}$ used for IEPI aggregation (Section 3.5).

The process set consists of four analytically constructed accounting authorisation workflows selected to exercise the complete routing-construct taxonomy supported by the IEPI engine. Scenarios A and B evaluate Exclusive Gateway (XOR) routing under different levels of routing depth, Scenario C evaluates Inclusive Gateway (OR) routing, and Scenario D evaluates LOOP routing through an explicit rework cycle. All scenarios are represented through their corresponding control-flow abstractions without structural modification.

3.7.3. Reported Outputs and Aggregation Scope

The evaluation reports per-construct profiles $\mathrm{\Pi }\left[c\right]=(H_N\left(c\right),R\left(c\right),\kappa \left(c\right),f\left[c\right])$ for routing constructs with valid probability inputs together with block-level quantities $\left(U\right(B),R(B\left)\right)$ for all process blocks. Diagnostic flags are reported explicitly in order to identify probability-coverage issues, invalid inputs, and consistency conditions. Viability classification and IEPI scoring depend exclusively on the construct-level quantities $H_N\left(c\right)$ and $R\left(c\right)$. Block-level quantities do not participate in viability classification or process-level aggregation.

3.7.4. Evaluation Protocol and Sensitivity

For each evaluation scenario, the IEPI engine computes construct-level quantities $(H_N\left(c\right),R\left(c\right))$, viability classifications $\kappa \left(c\right)$, diagnostic flags $f\left[c\right]$, block-level quantities $\left(U\right(B),R(B\left)\right)$, and the process-level IEPI score. Threshold sensitivity is evaluated by varying $(H_{min},H_{max},{\rho }_{min})$ one parameter at a time while holding process structures and routing probabilities fixed. Probability sensitivity analysis is outside the scope of the present evaluation and is identified as a potential direction for future work. The reported sensitivity analysis therefore focuses exclusively on controlled variation of the viability-threshold parameters while holding process structures and routing probabilities fixed. For LOOP constructs, the feasibility condition ${\rho }_{min}\le 1/4$ is enforced. For each configuration, the IEPI engine recomputes all outputs from the same underlying process representation.

3.7.5. Baseline Summaries and Experimental Controls

The evaluation focuses on construct-level diagnostics, block-level uncertainty propagation, process-level IEPI reporting, and threshold sensitivity analysis. These outputs are reported independently of one another and serve distinct analytical purposes within the IEPI framework. All experiments use fixed process structures, routing-probability assignments, and threshold configurations; identical inputs produce identical outputs. Consequently, the evaluation is fully deterministic and computationally reproducible.

4. Results

The results are presented at three analytical levels: (i) construct-level routing diagnostics, including normalized entropy, responsiveness, viability classifications, and diagnostic flags; (ii) block-level propagated uncertainty quantities obtained through deterministic application of the composition rules; and (iii) the process-level IEPI viability-band reporting index. The evaluation covers the four BPMN 2.0 scenarios introduced in Section 3.1, collectively exercising the XOR, OR, and LOOP routing constructs supported by the IEPI engine. Unless otherwise stated, all reported quantities are computed using valid probability assignments and fixed threshold configurations, such that repeated execution with identical inputs yields identical outputs. For all routing constructs considered in the evaluation, the diagnostic flag is reported as $f\left[c\right]=\mathrm{valid}$, indicating that the probability definability constraints are satisfied and that the corresponding constructs are eligible for inclusion in the reported analytical outputs.

4.1. Experimental Setup and Reported Configurations

All reported results are generated from the four BPMN 2.0 evaluation scenarios introduced in Section 3.1: Scenario A (two-level accounting authorisation with fixed approvers), Scenario B (two-level accounting authorisation with LDAP-based approver determination), Scenario C (accounting authorisation with optional compliance review and OR routing), and Scenario D (accounting authorisation with rework and resubmission loop routing). Collectively, the scenarios exercise the Exclusive (XOR), Inclusive (OR), and LOOP routing constructs supported by the IEPI engine and therefore provide controlled coverage of the complete routing-construct set addressed by the reference implementation.

For each routing construct in these models, externally specified routing probabilities are provided as fixed input parameters in accordance with the probability-assignment strategy defined in Section 3.3. The reported probability assignments are analytical evaluation inputs selected to exercise different routing-uncertainty and viability-band conditions under controlled and reproducible settings rather than to represent estimates of organisational behaviour.

The baseline runs use a common viability-threshold configuration $(H_{min},H_{max},{\rho }_{min})$, applied uniformly across all evaluation scenarios. Under these fixed inputs, the IEPI engine computes construct-level routing diagnostics, including normalized entropy, responsiveness, viability classifications, and diagnostic flags; block-level propagated uncertainty quantities; and the process-level viability-band reporting index $\mathrm{IEPI}$, as defined in Section 3.4 and Section 3.5.

All reported quantities are deterministic functions of the process structure, routing-probability assignments, and threshold settings; repeated execution with identical inputs yields identical outputs. No probability estimation, optimisation, statistical learning, or parameter fitting is performed during evaluation.

4.2. Local Routing Diagnostics

This subsection reports the construct-level diagnostics produced by the IEPI engine for each routing construct contained in the four evaluation scenarios introduced in Section 3.1. For every routing construct, the assigned routing probabilities are used to compute normalized entropy $H_N\left(c\right)$ and responsiveness $R\left(c\right)$ according to Equations (2) and (3). These quantities determine the viability classification $\kappa \left(c\right)$ under the baseline threshold configuration $(H_{min},H_{max},{\rho }_{min})=(0.30,0.95,0.20)$.

The reported diagnostics provide the primary local outputs of the IEPI engine and form the basis for subsequent block-level propagation and process-level aggregation. In addition to entropy and responsiveness measures, the engine reports diagnostic flags $f\left[c\right]$ that indicate probability-input validity and probability-coverage status. In the present evaluation, all routing constructs satisfy the probability definability constraints specified in Section 3.3 and, therefore, receive the flag $f\left[c\right]=\mathrm{valid}$. Consequently, all routing constructs are included in the reported construct-level diagnostics and subsequent analytical computations.

4.2.1. Baseline Probability Specification

In the absence of event-log data, routing probabilities are specified as fixed analytical inputs chosen to ensure non-degenerate routing behaviour and an interpretable contrast between routing constructs under controlled evaluation conditions. The selected values are intended to provide analytically useful uncertainty profiles rather than to represent empirically observed branch frequencies. Specifically, the selected values were chosen to produce routing constructs exhibiting different entropy and responsiveness characteristics, including configurations that fall within and outside the prescribed viability band, thereby enabling assessment of the diagnostic behaviour of the IEPI engine across multiple routing-uncertainty conditions.

The baseline threshold configuration defines a viability band that excludes near-deterministic routing behaviour while retaining sensitivity to diffuse routing patterns. The responsiveness threshold enforces a minimum level of dispersion across routing alternatives.

For Scenario A, the routing probabilities are assigned to the routing constructs labeled $G_1$ and $G_2$ as

$$p_{G_1}=(0.70,0.30),p_{G_2}=(0.85,0.15).$$

(12)

For Scenario B, the routing probabilities are assigned to the routing constructs labeled $G_0$, $G_1$, and $G_2$ as

$$p_{G_0}=(0.60,0.40),p_{G_1}=(0.70,0.30),p_{G_2}=(0.85,0.15).$$

(13)

For Scenario C, the OR routing construct is assigned the normalized marginal activation vector

$$p_{G_{\mathrm{OR}}}=(0.40,0.60),$$

(14)

while the subsequent authorisation stages retain the routing probabilities

$$p_{G_1}=(0.70,0.30),p_{G_2}=(0.85,0.15).$$

(15)

These values represent the normalized marginal activation vector used by the IEPI engine for construct-level diagnostics and local comparability within the OR gateway. They do not correspond to a joint probability distribution over branch combinations and therefore characterize local routing uncertainty rather than combinatorial activation behaviour.

For Scenario D, the loop construct is assigned a continuation probability

$$q=0.35,$$

(16)

while the authorisation stages retain

$$p_{G_1}=(0.70,0.30),p_{G_2}=(0.85,0.15).$$

(17)

The continuation probability q denotes the likelihood that a corrected authorisation request re-enters the validation stage rather than exiting the rework loop. This specification allows the IEPI engine to capture the iterative propagation of uncertainty and responsiveness under controlled, analytically defined loop behaviour.

In all scenarios, the assigned probability values satisfy the definability constraints specified in Section 3.3. The resulting probability configurations provide a controlled set of routing conditions spanning XOR, OR, and LOOP constructs while maintaining a common accounting authorisation context and supporting reproducible evaluation of construct-level diagnostics, uncertainty propagation, and viability-band reporting outputs.

4.2.2. Scenario A

Scenario A contains two sequential XOR routing constructs corresponding to the Level 1 and Level 2 authorisation decisions.

Table 1. Local routing diagnostics for Scenario A.

Construct	Probabilities	${\mathit{H}}_{\mathit{N}}$	R	$\mathit{\kappa }\left(\mathit{c}\right)$	$\mathit{f}\left[\mathit{c}\right]$
$G_1$	$(0.70,0.30)$	0.881	0.420	viable	valid
$G_2$	$(0.85,0.15)$	0.610	0.255	viable	valid

reports the routing probabilities and the resulting IEPI diagnostics for each construct. Under the baseline threshold configuration, both routing constructs are classified as viable and, therefore, contribute zero violation to the process-level IEPI computation. The first decision point ($G_1$) exhibits higher normalized entropy and responsiveness owing to its more balanced routing distribution, whereas the second decision point ($G_2$) exhibits lower uncertainty and dispersion due to the stronger preference for the approval branch. In both cases, the computed diagnostics remain within the prescribed viability band, and all probability inputs satisfy the definability constraints specified in Section 3.3.

4.2.3. Scenario B

Scenario B extends the routing structure by introducing an additional XOR routing construct associated with organisational resolution.

Table 2. Local routing diagnostics for Scenario B.

Construct Label	Probabilities $\left(\mathit{p}\right)$	${\mathit{H}}_{\mathit{N}}\left(\mathit{c}\right)$	$\mathit{R}\left(\mathit{c}\right)$	$\mathit{\kappa }\left(\mathit{c}\right)$	$\mathit{f}\left[\mathit{c}\right]$
$G_0$	$(0.60,0.40)$	0.971	0.480	over-uncertain	valid
$G_1$	$(0.70,0.30)$	0.881	0.420	viable	valid
$G_2$	$(0.85,0.15)$	0.610	0.255	viable	valid

reports the corresponding construct-level diagnostics. The routing construct labeled $G_0$ exhibits the highest normalized entropy and responsiveness because its probability distribution is closest to balanced. Under the baseline threshold configuration, $G_0$ is classified as over-uncertain because $H_N\left(c\right)>H_{max}$, whereas $G_1$ and $G_2$ remain within the prescribed viability band. All probability inputs satisfy the definability constraints and therefore receive the diagnostic flag $f\left[c\right]=\mathrm{valid}$.

4.2.4. Scenario C

Scenario C extends the authorisation workflow by introducing an Inclusive Gateway associated with optional compliance review.

Table 3. Local routing diagnostics for Scenario C.

Construct Label	Probabilities $\left(\mathit{p}\right)$	${\mathit{H}}_{\mathit{N}}\left(\mathit{c}\right)$	$\mathit{R}\left(\mathit{c}\right)$	$\mathit{\kappa }\left(\mathit{c}\right)$	$\mathit{f}\left[\mathit{c}\right]$
OR gateway	(0.40, 0.60)	0.971	0.480	over-uncertain	valid
G1	(0.70, 0.30)	0.881	0.420	viable	valid
G2	(0.85, 0.15)	0.610	0.255	viable	valid

reports the resulting construct-level diagnostics. The OR routing construct exhibits a highly balanced marginal activation profile, resulting in the highest normalized entropy and responsiveness values among the routing constructs considered in the evaluation. Under the IEPI framework, these values are used for construct-level OR diagnostics and comparability rather than representing a joint activation distribution over branch combinations. Under the baseline threshold configuration, the OR construct is classified as over-uncertain because $H_N\left(c\right)>H_{max}$, whereas the subsequent authorisation constructs $G_1$ and $G_2$ remain within the prescribed viability band. All probability inputs satisfy the definability constraints and therefore receive valid diagnostic flags.

4.2.5. Scenario D

Scenario D introduces an explicit LOOP construct through the rework and resubmission cycle preceding the approval hierarchy.

Table 4. Local routing diagnostics for Scenario D.

Construct Label	Probabilities $\left(\mathit{p}\right)$	${\mathit{H}}_{\mathit{N}}\left(\mathit{c}\right)$	$\mathit{R}\left(\mathit{c}\right)$	$\mathit{\kappa }\left(\mathit{c}\right)$	$\mathit{f}\left[\mathit{c}\right]$
LOOP	q = 0.35	0.934	0.228	viable	valid
G1	(0.70, 0.30)	0.881	0.420	viable	valid
G2	(0.85, 0.15)	0.610	0.255	viable	valid

reports the corresponding construct-level diagnostics. The loop continuation probability is set to $q=0.35$, indicating that a corrected authorisation request has a 35% probability of re-entering the validation stage and a 65% probability of exiting the rework cycle. This produces a normalized Bernoulli entropy of 0.934 and responsiveness of 0.228, reflecting substantial routing uncertainty while remaining within the prescribed viability band. The subsequent authorisation constructs $G_1$ and $G_2$ are also classified as viable. All probability inputs satisfy the definability constraints and therefore receive valid diagnostic flags.

All reported quantities are computed deterministically from the specified routing probabilities and threshold configuration. No non-valid diagnostic states were observed, as all probability assignments satisfy the definability constraints specified in Section 3.3. Diagnostic flags are nevertheless reported because the IEPI engine explicitly supports detection of invalid probability assignments, incomplete probability coverage, and malformed routing inputs. Although such conditions are not present in the evaluation scenarios considered here, their inclusion demonstrates the diagnostic-validation capabilities of the IEPI framework in addition to its routing-uncertainty assessment functionality.

4.3. Block-Level Propagation Results

This subsection reports the block-level quantities obtained through deterministic bottom-up application of the IEPI composition rules defined in Section 3.4 and Algorithm 2. The focus is on the propagated uncertainty contribution $U\left(B\right)$ for the evaluated process structures. These block-level quantities summarize uncertainty propagation through the process topology and are analytically distinct from the process-level IEPI reporting index. Block-level responsiveness summaries $R\left(B\right)$ are reported for descriptive reference only and do not participate in viability classification or IEPI scoring.

4.3.1. Scenario A

Scenario A consists of two sequential XOR routing constructs labeled $G_1$ and $G_2$. Under the block representation used for evaluation, the ordering of each routing probability vector $p^{\left(c\right)}$ is aligned with the structural ordering of the corresponding child blocks. In particular, the first component corresponds to the continuation branch used in recursive composition.

Applying the XOR composition rule to the sequential authorisation structure yields the propagated uncertainty

$$U_A=H\left(p_{G_1}\right)+p_{G_1}^{\mathrm{pass}}H\left(p_{G_2}\right),$$

where $p_{G_1}^{\mathrm{pass}}=0.70$ denotes the probability of continuing to the second authorisation stage. Using the entropy values computed from the assigned routing probabilities,

$$H\left(p_{G_1}\right)=0.611,H\left(p_{G_2}\right)=0.423,$$

the resulting propagated uncertainty is

$$U_A=0.611+0.70\times 0.423=0.907.$$

The corresponding block-level responsiveness summary is obtained through additive aggregation across the sequential routing constructs:

$$R_A=R\left(p_{G_1}\right)+R\left(p_{G_2}\right)=0.420+0.255=0.675.$$

The propagated uncertainty reflects both the uncertainty associated with the initial authorisation decision and the expected contribution of the downstream authorisation stage. This quantity characterizes uncertainty propagation within the process structure and does not participate directly in viability classification or IEPI computation. Because the second routing construct is reached only with probability $0.70$, its contribution is weighted accordingly in the recursive aggregation.

4.3.2. Scenario B

Scenario B extends Scenario A by introducing a preceding XOR routing construct labeled $G_0$. Applying the XOR composition rule recursively over the resulting three-stage authorisation structure yields

$$U_B=H\left(p_{G_0}\right)+p_{G_0}^{\mathrm{pass}}\left[H\left(p_{G_1}\right)+p_{G_1}^{\mathrm{pass}}H\left(p_{G_2}\right)\right],$$

where $p_{G_0}^{\mathrm{pass}}=0.60$ and $p_{G_1}^{\mathrm{pass}}=0.70$ denote the continuation-branch probabilities.

Using

$$H\left(p_{G_0}\right)=0.673,H\left(p_{G_1}\right)=0.611,H\left(p_{G_2}\right)=0.423,$$

gives

$$U_B=0.673+0.60\left(0.611+0.70\times 0.423\right)=1.217.$$

The corresponding block-level responsiveness summary is obtained through additive aggregation across the three routing constructs:

$$R_B=R\left(p_{G_0}\right)+R\left(p_{G_1}\right)+R\left(p_{G_2}\right)=0.480+0.420+0.255=1.155.$$

The propagated uncertainty contribution in Scenario B reflects the effect of introducing an additional XOR routing construct into the authorisation workflow and therefore exceeds the corresponding value obtained for Scenario A. Through recursive application of the IEPI composition rules, the uncertainty associated with the organisational-resolution decision is incorporated into the overall block-level uncertainty contribution. The corresponding responsiveness summary reflects the additive aggregation of routing dispersion across the three routing constructs.

4.3.3. Scenario C

Scenario C extends the authorisation workflow by introducing an OR routing construct associated with optional compliance review. Under the IEPI framework, the OR gateway is represented by a normalized marginal activation vector and propagated using the collision-entropy composition rule. The two review branches synchronize before entering the same downstream authorisation structure; consequently, the expected downstream contribution corresponds to the propagated uncertainty previously computed for Scenario A.

Applying the OR composition rule yields

$$U_C=H_2\left(p_{\mathrm{OR}}\right)+0.40U_A+0.60U_A,$$

where $U_A$ denotes the propagated uncertainty contribution of the downstream authorisation structure reported for Scenario A.

Using

$$H_2\left(p_{\mathrm{OR}}\right)=-log(0.4^2+0.6^2)=0.654,$$

and

$$U_A=0.907,$$

gives

$$U_C=0.654+0.40\times 0.907+0.60\times 0.907=1.561.$$

The corresponding block-level responsiveness summary is obtained through additive aggregation of the local responsiveness quantities:

$$R_C=R\left(p_{\mathrm{OR}}\right)+R\left(p_{G_1}\right)+R\left(p_{G_2}\right)=0.480+0.420+0.255=1.155.$$

The propagated uncertainty contribution in Scenario C illustrates how the IEPI engine evaluates OR routing behaviour through the collision-entropy composition rule. The resulting uncertainty combines the local contribution of the OR gateway with the propagated contribution of the downstream authorisation structure. As expected, the propagated uncertainty exceeds that of Scenario A because the OR routing construct contributes an additional collision-entropy term prior to the authorisation hierarchy. The corresponding responsiveness summary reflects the cumulative routing dispersion associated with the OR gateway and the downstream authorisation decisions.

4.3.4. Scenario D

Scenario D introduces an explicit rework and resubmission loop before the authorisation hierarchy. In the BPMN structure, requests that fail validation are corrected and then evaluated by a resubmission decision. If resubmitted, the request re-enters the validation stage; otherwise, it exits the process. Under the IEPI abstraction, this pre-approval rework cycle is evaluated as a LOOP construct, followed by the same downstream authorisation structure used in Scenario A.

Applying the LOOP composition rule gives

$$U_{\mathrm{LOOP}}=H\left(q\right)+{\displaystyle \frac{q}{1-q}}U\left(B_{\mathrm{body}}\right).$$

In this scenario, the loop body contains correction and revalidation activities but no additional routing construct under the IEPI abstraction, so $U\left(B_{\mathrm{body}}\right)=0$. With $q=0.35$, the loop contribution is therefore

$$U_{\mathrm{LOOP}}=H\left(0.35\right)=0.647.$$

The propagated uncertainty for Scenario D is obtained by adding the downstream authorisation contribution from Scenario A:

$$U_D=U_{\mathrm{LOOP}}+U_A=0.647+0.907=1.554.$$

The corresponding block-level responsiveness summary is

$$R_D=R\left(q\right)+R\left(p_{G_1}\right)+R\left(p_{G_2}\right)=0.228+0.420+0.255=0.903.$$

Compared with Scenario A, Scenario D demonstrates how the introduction of a LOOP construct contributes additional uncertainty through the continuation decision associated with the rework cycle. Although the LOOP construct is classified as viable under the baseline threshold configuration, its nonzero Bernoulli entropy still contributes to the propagated uncertainty quantity. This illustrates the distinction between uncertainty propagation and viability-band compliance within the IEPI framework. Within the IEPI evaluation, the validation–correction–resubmission fragment is intentionally represented as a single LOOP construct in order to isolate and demonstrate the behaviour of the LOOP composition rule.

Across all evaluation scenarios, block-level uncertainty and responsiveness quantities are obtained through deterministic application of the IEPI composition rules and serve as descriptive summaries of routing behaviour within the process structure. The reported values depend solely on the specified process structures and probability assignments and are analytically distinct from the process-level IEPI reporting index.

4.4. Process-Level IEPI Comparison

This subsection compares the aggregate process-level results for the four evaluation scenarios under the baseline threshold configuration $(H_{min},H_{max},{\rho }_{min})=(0.30,0.95,0.20)$. For each process, the IEPI score is computed over the valid construct subset ${\mathcal{C}}_{\mathrm{valid}}$ as defined in Section 3.5. The reported quantities are the valid construct set size $|{\mathcal{C}}_{\mathrm{valid}}|$, the average violation $\overline{V}$, and the resulting viability-band reporting index $\mathrm{IEPI}$.

In Scenario A, both XOR routing constructs satisfy the prescribed viability criteria. Consequently, all violation terms are zero, yielding

$${\overline{V}}_A=0,{\mathrm{IEPI}}_A=1.$$

In Scenario B, all three routing constructs belong to the valid construct subset, so $|{\mathcal{C}}_{\mathrm{valid}}|=3$. The routing construct labeled $G_0$ is classified as over-uncertain because $H_N\left(G_0\right)=0.971>H_{max}=0.95$. The resulting violation is

$$V\left(G_0\right)={\left[H_N\left(G_0\right)-H_{max}\right]}_{+}=0.971-0.95=0.021.$$

The remaining routing constructs are classified as viable and therefore contribute zero violation. The average violation is

$${\overline{V}}_B={\displaystyle \frac{0.021}{3}}=0.0070,$$

which yields

$${\mathrm{IEPI}}_B={\displaystyle \frac{1}{1+0.0070}}=0.9930\approx 0.993.$$

In Scenario C, the OR routing construct is classified as over-uncertain because its normalized entropy exceeds the prescribed upper viability threshold. The corresponding violation is

$$V\left(G_{\mathrm{OR}}\right)={\left[H_N\left(G_{\mathrm{OR}}\right)-H_{max}\right]}_{+}=0.971-0.95=0.021.$$

The authorisation routing constructs $G_1$ and $G_2$ remain viable. Consequently,

$${\overline{V}}_C={\displaystyle \frac{0.021}{3}}=0.0070,$$

and

$${\mathrm{IEPI}}_C={\displaystyle \frac{1}{1+0.0070}}=0.9930\approx 0.993.$$

In Scenario D, the LOOP construct and both authorisation routing constructs satisfy the viability criteria. Therefore,

$${\overline{V}}_D=0,{\mathrm{IEPI}}_D=1.$$

Table 5. Process-level IEPI comparison under the baseline threshold configuration.

Scenario	$|{\mathcal{C}}_{\mathbf{valid}}|$	$\overline{\mathit{V}}$	$\mathbf{IEPI}$
Scenario A	2	0.0000	1.000
Scenario B	3	0.0070	0.993
Scenario C	3	0.0070	0.993
Scenario D	3	0.0000	1.000

summarizes the aggregate process-level results.

The reported IEPI values should be interpreted as summaries of aggregate viability-band compliance rather than as direct measures of propagated uncertainty or process complexity.

The propagated uncertainty quantities reported in the previous subsection indicate that the four scenarios differ in the amount of uncertainty accumulated through their respective routing structures. However, the IEPI score evaluates a different property, namely compliance with the prescribed viability band. Under the baseline threshold configuration, all routing constructs in Scenarios A and D satisfy the viability criteria and therefore yield the maximum reporting score. Scenarios B and C each contain a single routing construct whose normalized entropy exceeds the prescribed upper threshold, producing a small nonzero violation and a corresponding reduction in the IEPI score.

This distinction illustrates the complementary roles of propagated uncertainty and the IEPI viability-band reporting index. The propagated uncertainty quantities characterize how uncertainty accumulates through the process structure under the specified routing probabilities, whereas the IEPI score characterizes the extent to which routing behaviour remains within the prescribed viability region. Consequently, processes that differ substantially in structure or propagated uncertainty may nevertheless receive identical IEPI values when all routing constructs satisfy the viability criteria. This behaviour is consistent with the intended purpose of IEPI as a reporting mechanism for aggregate viability-band compliance rather than as a direct measure of uncertainty accumulation within the process structure.

4.5. Threshold Sensitivity Analysis

This subsection reports the response of local viability classifications and the process-level IEPI score to controlled variations of the viability-threshold vector $(H_{min},H_{max},{\rho }_{min})$ under the protocol defined in Section 3.6. The analysis is conducted deterministically, with BPMN models and routing probabilities held fixed. The objective is to examine how local classifications and the IEPI score respond to changes in threshold settings rather than to identify optimal parameter values.

The sensitivity analysis focuses on variation of the upper entropy threshold $H_{max}$ while holding $H_{min}=0.30$ and ${\rho }_{min}=0.20$ fixed. This isolates the effect of modifying the admissible uncertainty range on both local classifications and the aggregate IEPI score.

4.5.1. Effect on Local Viability Classifications

As $H_{max}$ varies, classification changes occur whenever the threshold crosses the normalized entropy value associated with a routing construct. For the routing construct labeled $G_1$, with

$$H_N\left(G_1\right)=0.881,$$

the classification is over-uncertain when $H_{max}<0.881$ and viable when $H_{max}\ge 0.881$.

For the routing constructs labeled $G_0$ (Scenario B) and $G_{\mathrm{OR}}$ (Scenario C), both of which have

$$H_N=0.971,$$

the classification is over-uncertain when $H_{max}<0.971$ and viable when $H_{max}\ge 0.971$.

The routing construct labeled $G_2$, with

$$H_N\left(G_2\right)=0.610,$$

satisfies the entropy-based viability condition for all tested values of $H_{max}$ considered in this analysis. Likewise, the LOOP construct in Scenario D, with

$$H_N\left(\mathrm{LOOP}\right)=0.934,$$

becomes over-uncertain only when $H_{max}<0.934$.

These transitions occur precisely when the upper entropy threshold crosses the corresponding normalized entropy value of a routing construct. Consequently, the resulting classification changes follow directly from the comparison between $H_N\left(c\right)$ and the viability threshold parameters.

4.5.2. Effect on Process-Level IEPI

The process-level IEPI viability-band reporting index varies through the average violation term $\overline{V}$ defined in Equation (10). As the upper entropy threshold $H_{max}$ changes, routing constructs may transition between the viable and over-uncertain classifications, thereby altering both the number and magnitude of violation terms contributing to the aggregate score.

For threshold values below $H_N\left(G_1\right)=0.881$, the routing construct labeled $G_1$ contributes a nonzero violation term. When $H_{max}$ reaches or exceeds 0.881, the construct becomes viable and its contribution to the average violation is eliminated. Similarly, the LOOP construct in Scenario D becomes viable when $H_{max}\ge 0.934$, while the routing constructs $G_0$ (Scenario B) and $G_{\mathrm{OR}}$ (Scenario C) become viable only when $H_{max}\ge 0.971$.

Between these transition points, the violation magnitude associated with each over-uncertain routing construct decreases continuously according to

$$V\left(c\right)={\left[H_N\left(c\right)-H_{max}\right]}_{+},$$

which reduces to $H_N\left(c\right)-H_{max}$ whenever $H_N\left(c\right)>H_{max}$. Consequently, the IEPI score may increase through two distinct mechanisms: (i) discrete changes in viability classification when a threshold crossing occurs, and (ii) continuous reduction of violation magnitudes while the classification remains unchanged.

Because the evaluation scenarios contain different numbers and types of routing constructs, the resulting sensitivity profiles differ across scenarios. Nevertheless, in all cases the IEPI score varies deterministically and monotonically with respect to the aggregate violation term. This behaviour is consistent with the intended role of the IEPI as a viability-band reporting index. Changes in the score reflect changes in routing-viability compliance rather than changes in propagated uncertainty or structural complexity. Consequently, threshold sensitivity analysis provides insight into the stability of the reporting outputs under alternative viability-band specifications rather than into the sensitivity of uncertainty propagation itself.

4.5.3. Sensitivity Results

Table 6. Sensitivity of viability classifications and IEPI reporting outputs to variation in $H_{max}$.

Scenario	${\mathit{H}}_{max}$	Violating Constructs	$\overline{\mathit{V}}$	IEPI
A	0.85	$G_1$	0.0155	0.985
A	0.90	None	0.0000	1.000
A	0.95	None	0.0000	1.000
B	0.85	$G_0$, $G_1$	0.0507	0.952
B	0.90	$G_0$	0.0237	0.977
B	0.95	$G_0$	0.0070	0.993
C	0.85	OR, $G_1$	0.0507	0.952
C	0.90	OR	0.0237	0.977
C	0.95	OR	0.0070	0.993
D	0.85	LOOP, $G_1$	0.0383	0.963
D	0.90	LOOP	0.0113	0.989
D	0.95	None	0.0000	1.000

summarizes the effect of varying the upper entropy threshold $H_{max}$ while holding $H_{min}=0.30$ and ${\rho }_{min}=0.20$ fixed. The reported classifications reflect the viability status of the routing constructs under each threshold configuration.

The sensitivity results demonstrate that the IEPI reporting index responds predictably to changes in the admissible uncertainty range defined by the viability thresholds. Lower values of $H_{max}$ increase both the number and magnitude of entropy-based violations, thereby reducing the IEPI score. As the threshold is relaxed, routing constructs progressively transition into the viable region, causing the aggregate violation term to decrease and the IEPI score to approach its maximum value of one.

The observed transition points correspond directly to the normalized entropy values of the routing constructs. In particular, viability changes occur at $H_N\left(G_1\right)=0.881$, $H_N\left(\mathrm{LOOP}\right)=0.934$, and $H_N\left(G_0\right)=H_N\left(G_{\mathrm{OR}}\right)=0.971$. The resulting behaviour confirms that the IEPI engine responds deterministically to threshold variation and that the aggregate reporting score remains fully consistent with the underlying construct-level diagnostics and viability classifications.

4.5.4. Analytical Observations

Across the tested configurations, the IEPI score varies with the threshold parameters through changes in the average violation term $\overline{V}$. As $H_{max}$ increases, the admissible uncertainty range expands, reducing the magnitude and number of entropy-based violations. Consequently, the average violation decreases and the IEPI score increases according to the aggregation rule defined in Section 3.5.

The observed transitions occur when the upper entropy threshold crosses the normalized entropy value of a routing construct. In the present evaluation, classification changes are associated with the threshold values $H_N\left(G_1\right)=0.881$, $H_N\left(\mathrm{LOOP}\right)=0.934$, and $H_N\left(G_0\right)=H_N\left(G_{\mathrm{OR}}\right)=0.971$. Between these transition points, the IEPI score varies continuously through the corresponding violation magnitudes, even when the underlying classifications remain unchanged.

The sensitivity results further illustrate the distinction between propagated uncertainty and viability-band compliance. Throughout the analysis, the propagated uncertainty quantities associated with the process structures remain unchanged because both the routing probabilities and process topologies are held fixed. While the process structures and routing probabilities remain fixed throughout the analysis, changes in the threshold configuration alter the interpretation of the resulting routing behaviour relative to the prescribed viability criteria. The IEPI score therefore reflects the degree of compliance with the viability band rather than the absolute magnitude of propagated uncertainty or structural complexity.

IEPI should be interpreted as a routing-governance indicator rather than a business-performance indicator. A process may exhibit excellent time, cost, and quality performance while simultaneously displaying undesirable routing-uncertainty characteristics, and vice versa. Consequently, IEPI is intended to complement rather than replace traditional BPM KPIs. Process-improvement decisions should be guided primarily by construct-level diagnostics identifying specific routing structures that violate the prescribed viability criteria.

All reported quantities are deterministic functions of the process models, routing probabilities, and threshold settings. No statistical inference, optimisation, parameter fitting, or significance testing is applied.

4.6. Summary of Evaluation Findings

The evaluation produces outputs at the routing-construct, block, and process levels. At the routing-construct level, normalized entropy and responsiveness are used to generate construct-level diagnostics, viability classifications, and diagnostic validity flags under fixed threshold settings. At the block level, uncertainty quantities are propagated through the process structure using the composition rules and recursive aggregation procedure described in Section 3.5 and Algorithm 2, enabling deterministic evaluation of uncertainty accumulation across XOR, OR, and LOOP routing constructs.

At the process level, the IEPI score provides a bounded viability-band reporting index that aggregates construct-level violations relative to a prescribed viability band. The evaluation demonstrates that the resulting score reflects compliance with the specified viability criteria rather than the absolute magnitude of propagated uncertainty. Consequently, processes with different structures and uncertainty-propagation characteristics may produce identical IEPI values when all routing constructs satisfy the viability conditions.

The sensitivity analysis further demonstrates that local classifications and process-level IEPI values respond predictably to threshold variation. Classification transitions occur when threshold values cross the normalized entropy values of the corresponding routing constructs, while continuous score variation arises from changes in violation magnitudes within fixed classification regions. Across all tested configurations, the IEPI score varies deterministically and monotonically with respect to the aggregate violation term.

Overall, the evaluation demonstrates that the IEPI engine produces reproducible construct-level diagnostics, block-level uncertainty summaries, and process-level viability-band reporting outputs from BPMN process structures, routing-probability assignments, and analyst-specified threshold configurations without requiring statistical estimation, optimisation, or parameter fitting.

5. Discussion

5.1. Interpretation of the IEPI Results

The IEPI artifact provides a structured mapping from BPMN routing constructs and externally specified probability assignments to three levels of analytical output. At the construct level, each routing construct c yields normalized entropy $H_N\left(c\right)$, responsiveness $R\left(c\right)$, a viability classification $\kappa \left(c\right)$, and a diagnostic flag $f\left[c\right]$. At the block level, uncertainty contributions are propagated through the process structure as $U\left(B\right)$ and $R\left(B\right)$ according to fixed composition rules. At the process level, the IEPI score aggregates construct-level violations over the valid construct set ${\mathcal{C}}_{\mathrm{valid}}$.

The IEPI value is determined by the violation terms $V\left(c\right)$ computed from $H_N\left(c\right)$ and $R\left(c\right)$ relative to the threshold parameters. Aggregation is performed through the average violation $\overline{V}$, mapped to the unit interval via the reporting rule. As shown in the evaluation, structural differences between process models affect the IEPI score through both the size of ${\mathcal{C}}_{\mathrm{valid}}$ and the distribution of violation terms across routing constructs.

A key property of the formulation is the strict separation between analytical levels. Construct-level quantities $(H_N\left(c\right),R\left(c\right))$ define local routing behaviour, block-level quantities $U\left(B\right)$ and $R\left(B\right)$ describe structural propagation of uncertainty, and the IEPI score provides a reporting-only aggregation. This separation ensures that local diagnostics, structural propagation, and aggregate reporting remain analytically distinct and do not introduce implicit dependencies or circular evaluation criteria.

The evaluation results highlight the distinction between uncertainty propagation and viability-band compliance. The block-level quantities $U\left(B\right)$ and $R\left(B\right)$ characterize how routing uncertainty accumulates through the process structure under specified routing probabilities. By contrast, the IEPI score evaluates whether the resulting routing behaviour remains within analyst-defined viability criteria. Consequently, the IEPI score is not intended as a direct measure of uncertainty, process complexity, or process performance. Rather, it provides a reporting-oriented summary of aggregate compliance with the prescribed viability band.

5.2. Relationship to Existing BPM and Entropy-Based Approaches

The IEPI framework introduces a deterministic mechanism for evaluating routing uncertainty in BPMN models without extending the underlying modelling language or requiring additional execution data. In contrast to conventional BPM performance indicators, which focus on time, cost, or quality metrics, the IEPI formulation operates directly on routing distributions and control-flow structure. This formulation is consistent with prior work linking entropy-based measures and process viability in structured workflows [11].

Although entropy-based process uncertainty measures have previously been proposed in the BPM literature, including the routing-uncertainty formulation of Jung et al. [6], the contribution of the present work lies in the construction of a deterministic BPMN analytics artifact rather than in the introduction of a new entropy measure. The IEPI framework integrates construct-level diagnostics, viability assessment, diagnostic flagging, compositional uncertainty propagation, and process-level reporting within a unified analytical workflow. In this sense, the framework operates at a different analytical level from the underlying uncertainty measures on which it relies.

Whereas process-complexity measures quantify structural characteristics of process models and entropy measures quantify routing uncertainty, the IEPI framework combines these diagnostic outputs with analyst-defined viability criteria and reporting mechanisms. The objective is therefore not to replace existing complexity or uncertainty measures but to provide a structured analytical layer through which routing behaviour can be evaluated relative to a specified operational context.

5.3. Limitations

Several limitations should be acknowledged. First, the current evaluation relies on analytically specified routing probabilities rather than empirically observed execution frequencies. Although this choice supports controlled and reproducible artifact evaluation, further investigation using event logs and operational process data would strengthen external validity.

Second, the present study focuses on threshold sensitivity and does not examine sensitivity with respect to routing-probability perturbations. Third, the current implementation operates on predefined control-flow representations and therefore does not include BPMN parsing, process discovery, or probability-estimation capabilities. These functions remain outside the scope of the present artifact.

Finally, the present evaluation does not include direct empirical comparison with alternative BPM performance indicators, process-complexity measures, or entropy-based process-analysis approaches. The objective of this work is the formulation and demonstration of the IEPI analytics artifact rather than comparative benchmarking. Future studies may investigate comparative evaluations using real-world process datasets and event-log-derived routing probabilities.

5.4. Future Research Directions

Future work may proceed in several directions. Empirical evaluation using publicly available event logs and organisational process datasets would provide additional evidence regarding practical applicability. The integration of probability-estimation procedures derived from process mining and event-log analysis represents a natural extension of the current framework.

Further investigation of alternative uncertainty measures, including formulations based on Rényi entropy, Tsallis entropy, Fisher information, or related information-theoretic quantities, may provide insight into the robustness of the viability-band reporting architecture. Because the IEPI framework is defined at the level of diagnostics, viability assessment, and reporting aggregation, such extensions could be incorporated without altering the overall analytical structure of the artifact.

A further limitation concerns the aggregation behaviour of the process-level IEPI score. Because IEPI is computed from the average construct-level violation, the addition of routing constructs that satisfy the viability criteria may increase the reported score even when an existing violating construct remains unchanged. Consequently, the IEPI score should not be interpreted as a measure of process risk, process quality, or the severity of individual routing deficiencies. Rather, it provides a reporting-oriented summary of aggregate viability-band compliance across the routing constructs included in the process. For this reason, process-level IEPI values should be interpreted together with the construct-level diagnostics and violation records. Alternative aggregation schemes, such as weighted or worst-case violation formulations, may be explored in future work.

Additional research could also explore domain-specific viability-band calibration, comparative evaluation against existing process-complexity and uncertainty measures, and integration with BPM platforms and process-mining environments for operational deployment.

6. Conclusions

This study presented the IEPI as a deterministic BPMN analytics artifact for evaluating routing uncertainty in BPMN 2.0 process models under externally specified routing probabilities. The framework combines construct-level routing diagnostics, viability assessment, diagnostic flagging, compositional uncertainty propagation, and process-level reporting within a unified analytical workflow.

The evaluation demonstrated the behaviour of the IEPI engine across BPMN process models containing XOR, OR, and LOOP routing constructs. The reported results showed that construct-level entropy and responsiveness measures provide interpretable routing diagnostics, that uncertainty quantities can be propagated deterministically through process structures using fixed composition rules, and that the resulting process-level IEPI score provides a bounded summary of aggregate viability-band compliance.

A central finding of the evaluation is the distinction between propagated uncertainty and viability-band reporting. While block-level quantities characterize how routing uncertainty accumulates through a process structure, the IEPI score evaluates whether the resulting routing behaviour remains within analyst-specified viability criteria. Consequently, processes exhibiting different uncertainty-propagation characteristics may receive identical IEPI scores when all routing constructs satisfy the prescribed viability conditions. This separation allows uncertainty propagation and viability assessment to remain analytically distinct while operating within a common framework.

The proposed artifact operates entirely on defined process structures, routing probabilities, and threshold configurations. All reported outputs are deterministic functions of these inputs and therefore remain fully reproducible. No statistical estimation, machine learning, process discovery, optimisation, or parameter fitting is required for computation.

The present work represents an initial step toward viability-oriented routing analysis in BPMN process models. Future research should evaluate the framework using event-log-derived routing probabilities and real-world process datasets, investigate probability-sensitivity behaviour, and examine alternative uncertainty measures and propagation mechanisms. Because the IEPI framework is defined at the level of diagnostics, viability assessment, and reporting aggregation, such extensions can be incorporated without altering the overall analytical architecture of the artifact.