---
title: Analyst-Defined Process Scopes
url: https://www.emergentmind.com/topics/analyst-defined-process-scopes
type: topic
---

# Analyst-Defined Process Scopes

Analyst-defined process scopes are explicit delimitations of what counts as the relevant process, process fragment, cohort, or analytical unit for a given inquiry. In the literature, such scopes are specified through predicates over traces, utility functions and constraints over local process models, rule-based embeddings into object-centric event data, characterization maps for software process lines, or formal bounds over scenario spaces. A common premise is that process definitions are not purely intrinsic properties of data: they are often subjective and context-dependent, vary across organizations, roles, and analytical goals, and cannot always be discovered automatically [2508.18830]. In this sense, analyst-defined process scopes are both a representational device and a methodological commitment: they determine what is observed, compared, optimized, or verified.

## 1. Conceptual status of process scope

In process variant analysis, scope is operationalized as a partition of an event log into cohorts distinguished by a predicate on trace or case attributes. A process variant is defined as a subset of executions of a business process that can be distinguished from others based on a given predicate, and the paper formalizes this as a finite partition \(L = \varsigma_1 \cup \varsigma_2 \cup \dots \varsigma_n\) with \(\varsigma_i \cap \varsigma_j = \emptyset\) and a distinguishing attribute \(d\) shared by all traces within each cohort [1911.07582]. This makes scope selection the first technical act of analysis rather than a downstream visualization choice.

Object-centric process mining generalizes the issue. Standard Object-Centric Event Data formats capture interactions among multiple business objects, but existing formats lack explicit process scope definitions. The consequence is that analysis remains restricted to individual processes and to a low level of granularity even when the data spans multiple interrelated processes across an organizational value chain [2508.18830]. The literature therefore treats scope not merely as filtering, but as an explicit semantic layer over event data.

A related perspective appears in business process analysis methodology. The Business Process Analysis Canvas organizes domain knowledge into eight sections—BP Signature, BP Statement, BP User Stories, Actor, Activity, Outcome Matrix, BP Glossary, OPAAL Lexicon, UML Class Diagram, and BPA Ontology—to clarify process boundaries, participating actors, objects, triggers, objectives, and outputs [2201.06860]. This suggests that analyst-defined scope is often established progressively, from narrative articulation to formal ontology.

## 2. Scope as an analytical level

The most explicit scope taxonomy is given in goal-driven Local Process Model discovery, where utility functions and constraints are defined on four scopes: trace-level, event-level, activity-level, and model-level [1703.07116].

At the trace level, functions are defined over entire traces or trace segments that fit a given LPM:
\[
f^t(L, \Gamma_{L,\mathit{LPM}})
\]
where \(\Gamma_{L,\mathit{LPM}}\) is the set of trace fragments in log \(L\) that fit the LPM. One example scores models higher when they fit fragments that explain a large proportion of the total trace cost:
\[
f^t_1(L, \Gamma_{L,\mathit{LPM}}) = \sum_{\sigma' \in \Gamma_{L,\mathit{LPM}}} \sum_{e \in \sigma'} \frac{\pi_\mathit{cost}(e)}{\phi_{total\_cost}(\sigma')}
\]

At the event level, functions are defined over events fitting the LPM, independently of trace context:
\[
f^\epsilon(\mathrm{events}(L), \mathrm{events}(\Gamma_{L,\mathit{LPM}}))
\]
For instance,
\[
f_1^\epsilon(\mathrm{events}(L), \mathrm{events}(\Gamma_{L,\mathit{LPM}})) = \sum_{e \in \mathrm{events}(\Gamma_{L,\mathit{LPM}})} \pi_\mathit{cost}(e)
\]
finds LPMs that cover costly events or events executed by specific resources.

At the activity level, functions operate on the frequency of each activity’s occurrence in the whole log and in fitting segments:
\[
f^a(\mathit{activities}(L), \mathit{activities}(\Gamma_{L,\mathit{LPM}}))
\]
Uniform weighting of activities recovers classic support-based LPM mining.

At the model level, functions depend only on the structure or semantics of the LPM itself:
\[
f^m(\mathit{LPM})
\]
An example is requiring that discovered LPMs always end with a particular activity.

These scope-specific functions can be composed. The paper defines the overall utility of an LPM on log \(L\) as
\[
u(L, LPM) = \prod_{i=1}^{n} c_i(L, LPM) \cdot \sum_{j=1}^{k} f_j(L, LPM)
\]
where each \(c_i\) is a constraint and each \(f_j\) is a utility function. If any constraint is not satisfied, the utility becomes \(0\). The formalism makes scope compositional: hard restrictions and soft preferences can be mixed across multiple analytical levels.

## 3. Specification mechanisms

Analyst-defined scopes are implemented through several recurrent mechanisms.

The first is predicate-based cohort selection. In variant analysis, scoping is aligned with business analysts’ views of the process, and a variant is typically selected by a boolean predicate over trace or case attributes, such as filtering traces where `country = 'Germany'`. After splitting the event log into cohorts, comparative analysis may proceed directly with statistical or machine learning methods or indirectly through process discovery and model comparison [1911.07582].

The second is rule-based embedding. In scope-enriched object-centric logs, process scopes are embedded as special objects with \(\mathit{objtype} = \textit{process}\). Analysts specify rulesets in a formal context-free grammar called the Enrichment Language using constructs such as `INCLUDE`, `EXCLUDE`, `AND`, and `OR`. The embedding procedure consists of filtering, instantiating a new process object, and linking it to selected events, objects, and optional sub-scope process objects via \(E2O\) and \(O2O\) relations [2508.18830].

The third is knowledge-structuring and formalization. The BPA Canvas supports early involvement of business experts while yielding a BP analysis Ontology. Its eight knowledge sections progressively transform informal descriptions into structured terminology, semantic categorization, class diagrams, and finally OWL-based formalization [2201.06860]. Scope, in this setting, is the result of systematic documentation rather than only log filtering.

The fourth is characterization-based scoping for process standards. In software process scoping, analysts characterize products, projects, and processes using product maps, project maps, and process maps. The resulting scope distinguishes stable core elements from variable parts and supports a software process line with decision rules for instantiation [1401.8072]. Here, scope is tied to anticipated future portfolios, process capabilities, and controlled variability.

## 4. Representation, embedding, and tool support

A central line of work seeks to make analyst-defined scopes first-class, machine-interpretable constructs.

In object-centric event data, the base OCEL is formalized as
\[
L = (E, O, \mathit{EA}, \mathit{OA}, \mathit{evtype}, \mathit{evid}, \mathit{time}, \mathit{objtype}, \mathit{objid}, \mathit{eatype}, \mathit{oatype}, \mathit{eaval}, \mathit{oaval}, \mathit{E2O}, \mathit{O2O})
\]
and a scope-enriched OCEL contains at least one object \(o \in O\) with \(\mathit{objtype}(o) = \textit{process}\). Relevant events are linked by \((e, q, o) \in E2O\), while nesting and higher-level aggregation are represented by \((o, q', o') \in O2O\). This representation supports multiple, coexisting, overlapping, and nested scopes as well as drill-down and roll-up operations [2508.18830].

The corresponding tools are Procellar and the Business Execution Graph. Procellar supports scope definition, management, and export in basic and advanced modes. The Business Execution Graph visualizes process interactions and dependencies, with nodes as process scopes and edges as object-type-based handovers or interactions [2508.18830].

In artifact-centric BPM, provenance-aware logging provides another representational answer. The proposed schema records artifact instance creation, lifecycle transitions, task execution, and associations, and the lifecycle is modeled as a finite state machine
\[
A = (S, s_0, F, \Sigma, T)
\]
The use of the W7 model supports logging what happened, when, where, who triggered it, how, which data was affected, and why. Because all incoming events, transitions, and associations are logged, analysts can define scopes retrospectively and query arbitrary logical subsets of artifact instances, transitions, or related data [1412.6638].

Formal methods provide an additional analogue. In Alloy, scope is a user-specified upper bound for the cardinality of signatures. Reach extends the Analyzer by staging scenario exploration by size, where size is the size of the largest signature present in a scenario. Instead of enumerating all scenarios in solver order, Reach allows analysts to explore size \(0\), then size \(1\), and so on up to the maximum scope, and it improves incremental analysis when the user changes the scope [2110.11898]. Although not a business-process framework, it illustrates the same principle: scope is an analyst-controlled boundary on the search space.

## 5. Empirical uses and domain-specific realizations

Goal-driven scoping has been demonstrated on real event logs. In an IT Service Desk case study, the business question was “Which process fragments are related to high numbers of email and phone interactions?” The event-level utility was defined as the sum of the `number_of_interactions` property over events fitting an LPM:
\[
f^\epsilon(\mathrm{events}(L), \mathrm{events}(\Gamma_{L, LPM})) = \sum_{e \in \mathrm{events}(\Gamma_{L, LPM})} \pi_\mathit{number\_of\_interactions}(e)
\]
The discovered LPMs highlighted anomalous fragments that traditional frequency-based mining would miss. In the Traffic Fine Handling case study, a trace-level utility representing the remaining unpaid fine in each relevant segment revealed where and why large unpaid amounts persist, including the effects of appeal processes, added penalties, and missed payments [1703.07116].

Scope-enriched OCEL has been demonstrated on a public logistics log with four analyst-defined processes: Order Management with 594 events, Goods Management with 13,155 events, Transportation Management with 18,314 events, and Export Management with 2,132 events. Business Execution Graph visualizations showed dependencies such as the handover of transport documents from Order Management to Goods Management, the flow of containers through Transportation Management to Export Management, and loops such as forklifts returning [2508.18830].

In requirements engineering, scope is explicitly divided into strategic and tactical levels. The strategic level is expressed through a scope directive that steers multiple products and releases, while the tactical level operates through the stages IN, PLAN, and PROJECT. Over five years of one company’s data, features addressing quality aspects explicitly constituted 4.41% of all features handled, and the authors concluded that relying on external stakeholders and upfront analysis seems to lead to long lead-times and an insufficient quality requirements scope [1812.04884]. This is a distinct but related use of analyst-defined scope: it governs what quality concerns enter the decision process and at which planning horizon.

## 6. Trade-offs, misconceptions, and evolving directions

A recurrent misconception is that process scope can be extracted automatically from data without prior judgment. The object-centric literature explicitly rejects this: process definitions are typically subjective and context-dependent, and vary across organizations, roles, and analytical goals [2508.18830]. Variant analysis reaches a similar conclusion from another direction, since all downstream comparison presupposes an initial split of the log into meaningful cohorts [1911.07582].

Another persistent trade-off concerns abstraction versus variability. In software process standards, eliminating variability by building more abstract models can result in less control over the process, whereas integrating all kinds of variability leads to high process deployment costs [1401.8072]. The same tension appears in business process analysis more broadly: a scope that is too coarse risks interpretive ambiguity, while a scope that is too fine can fragment the analytical object into numerous local decisions.

Interactive process pattern discovery addresses this tension by making scope iterative and multi-dimensional. Existing PPDMs are typically unsupervised and focus on a single dimension of interest, but the interactive multi-interest framework lets experts define interest functions, inspect non-dominated patterns on a Pareto front, and select which patterns to expand further [2308.14475]. Formally, a pattern \(P^l\) dominates \(P^j\) when it is at least as good on all selected interest functions and strictly better on at least one. This allows scope to evolve through analyst feedback rather than through a fixed threshold.

An adjacent formalization appears in models of data analytic iteration. There, the analyst defines a complete potential outcome set \(\mathcal{Y}\), an expected outcome set \(E\), and an anomaly outcome set \(E^c = \mathcal{Y} \setminus E\), together with subjective probabilities \(\widehat{P}\). Expected information gain and anomaly information gain then guide tool selection and iteration:
\[
\widehat{H} = \widehat{P}(Y \in E)\left[-\log \widehat{P}(Y \in E)\right] + \widehat{P}(Y \in E^c)\left[-\log \widehat{P}(Y \in E^c)\right]
\]
\[
\widehat{M} = -\log \widehat{P}(Y \in E^c)
\]
[2309.08494]. This is not a process-mining formalism, but it makes explicit that scope can also be the analyst’s expectation space rather than only a structural sublog.

Across these lines of work, the dominant direction is toward explicit, reproducible, and machine-processable scoping. Rule sets, predicates, utility functions, provenance-aware logs, ontologies, and staged enumeration all shift scope from tacit analyst judgment to an inspectable artifact. A plausible implication is that future work will continue to integrate domain knowledge and formal representation, not by replacing analysts, but by making their scope decisions computationally legible.

Source: https://www.emergentmind.com/topics/analyst-defined-process-scopes