PaperlayerView exact revision on arXiv

Source-linked AI summary

A Framework for Object-Centric Predictive Monitoring of Collaborative Processes

Daniel Calegari, Andrea Delgado, Leonel Peña, Martín Rubio

arXiv:2608.27671v1cs.AI

TL;DR

Collaborative predictive monitoring lacks an explicit object-centric representation: existing approaches retain a single-case view, while object-centric prediction has not directly addressed collaboration. This paper maps collaborative logs to OCEL 2.0, reformulates fourteen tasks, and validates their execution across 350 task–log–predictor combinations, all completing five folds without failure.

  • Problem

    Existing collaborative prediction techniques lack an explicit object-centric mapping, while object-centric approaches have not addressed collaboration-specific entities, relations, and prediction targets.

    Source: §1 · p. 2

  • Method

    The paper maps extended collaborative event logs to an OCED-conformant OCEL 2.0 representation, reformulates fourteen prediction tasks, and provides a reproducible converter and prediction pipeline.

    Source: §9 · p. 34

  • Results

    350 task–log–predictor combinations completed five folds without failure, and reformulated tasks reproduced source labels on every evaluated prefix with zero mismatches.

    Source: §9 · p. 34

  • Takeaways & Limitations

    The representation makes collaboration structure explicit and supports targets arising from object-centric relations beyond the original single-case taxonomy.

    Source: §9 · p. 34

    Evaluation metrics are descriptive, not estimates for comparing or ranking representations; only one real-life log was included, and predictors used fixed configurations without systematic tuning.

    Source: §8 · p. 32

Abstract

from arXiv · show

Predictive Process Monitoring (PPM) of collaborative, inter-organizational processes requires reasoning over multiple interdependent entities, including participants, messages, local executions, and the global collaboration case. Existing approaches extend traditional event logs with collaboration attributes but retain a single-case perspective, leaving much of this structure implicit. Object-centric process mining (OCPM) provides an alternative by representing these entities as first-class objects with explicit relations and multiple notions of case. This study connects collaborative PPM and OCPM through three contributions: (i) a formal semantic mapping from extended collaborative event logs to an OCED-conformant object-centric representation, serialized in OCEL 2.0; (ii) a reformulation of collaborative prediction tasks as object-centric prediction tasks; and (iii) a reproducible converter and prediction pipeline implementing the proposed mapping. We evaluate the framework on four public collaborative event logs and a fifth derived from the BPI Challenge 2013 incident-management log by executing the fourteen reformulated tasks using five predictive strategies across tabular, sequential, and graph-native encodings. We further discuss the benefits, limitations, and threats to the approach's validity. The representation makes collaboration structure explicit and makes it natural to state prediction targets based on object relations that fall outside the case-centric taxonomy, at the cost of increased relational complexity and dependence on object-centric tooling.

1. Introduction

Collaborative PPM involves multiple interdependent entities that single-case logs leave implicit; this study maps them to an OCED-conformant object-centric representation and reformulates collaborative prediction tasks around explicit object relations.

1. Introduction

  • Single-case PPM is restrictive for collaborative processes, while extended collaborative logs encode participants and messages as event attributes and require extra projections for their analysis.Collaborative processes also involve fragmented visibility, privacy constraints, asynchronous interactions, and cross-participant event correlation.Source: §1 · pp. 1–2
  • The study formally maps extended collaborative logs to an OCED Core Model representation [11], serialized in OCEL 2.0 [12], with machine-checkable consistency criteria and an automated converter.Participants, local cases, communication interactions, and global collaboration cases become explicitly related objects rather than event attributes or traditional cases.Source: §1 · pp. 2–3
  • Retaining Predict-Collab’s fourteen-task taxonomy, the study reformulates collaborative prediction tasks in object-centric terms and enables targets over objects and relations beyond a flattened case.The reformulation is intended to preserve label information, addressing the question of whether such tasks can be restated without loss.Source: §1 · pp. 2–3
  • An end-to-end pipeline demonstrates the definitions on five collaborative logs using tabular, sequential, and graph encodings with Random Forest, XGBoost, Transformer, LSTM, and GNN strategies.Four logs are public collaborative baselines and the fifth is derived from an incident-management log; the work does not propose a new predictive model or claim predictive superiority.Source: §1 · p. 3
  • The object-centric structure makes prediction targets outside the case-centric taxonomy natural, and the study assesses its benefits and limitations relative to the extended collaborative representation.The motivation is the gap between collaborative PPM’s implicit structure and object-centric prediction approaches’ limited treatment of collaboration-specific entities, relations, and targets.Source: §1 · pp. 2–3
  • Across five logs, the mapping and task reformulation passed consistency, schema, and label-reproduction checks, and all fourteen tasks ran end-to-end; predictive results varied by target type and encoding.Categorical and structural targets beat a trivial baseline on all but one task–log–predictor entry, while numeric targets did not on the real-life log; pipeline cost was predictable from prefix count only for graph-native encoding. Fold dispersion did not support ranking predictors.Source: §1 · p. 3

2. Background and Related Work

Collaborative process monitoring involves multiple autonomous participants, local executions, messages, and a global case, while object-centric process mining makes interacting entities and multiple case perspectives explicit. Prior work supplies object-centric encodings and case-centric collaborative prediction, but not a mapping from collaborative logs or collaboration-specific task definitions; this paper provides the representation and tasks for applying existing techniques.

2.1. Collaborative business processes

  • Collaborative processes join autonomous participants’ internal orchestrations through messages, while the extended collaborative log records participant and element type and, when available, message endpoints.Log integration challenges, including message-event correlation, are left out of scope; resource identity is visible only if present as an ordinary event attribute.Source: §2.1 · pp. 4–5
  • A collaboration case spans a joint end-to-end execution, orchestration cases capture participants’ local executions, activity instances belong to one participant and orchestration, and resources identify the actors performing them.Messages coordinate participants and may appear as separate send and receive events; participant identifiers and resource identifiers denote different granularities.Source: §2.1 · p. 4

2.2. Object-centric process mining

  • Object-centric process mining represents events against all involved objects and supports multiple case perspectives, avoiding event replication or unrelated interleaving caused by flattening to one case.The paper uses “viewpoint” for the object type or types that define a prediction target or flattened log; calls this the leading type.Source: §2.2 · p. 6
  • The OCED Core Model [11] represents events, objects, typed attributes, directed object-to-object relations, and event-to-object observes relations; its static baseline cannot express time-varying relations.The paper targets OCEL 2.0 [12] for serialization, which adds per-type attribute schemas and timestamped object attribute values.Source: §2.2 · p. 6

2.3. Predictive process monitoring

  • Traditional PPM forecasts properties of running single cases from flat prefixes, while collaborative PPM injects collaboration attributes into flattened events and defines outcome-based, numeric-value, and next-event prediction types.Predict-Collab extends ProcessTransformer [22] and implements a subset of those tasks.Source: §2.3 · p. 7
  • No prior work maps collaborative logs to object-centric representations or defines collaborative prediction tasks; this paper supplies the representation and task definitions, not a new prediction model.Existing object-centric approaches do not address collaboration-specific targets such as the next participant or next message.Source: §2.3 · pp. 7–9
  • Tabular object-centric encoding aggregates attributes across linked objects, while its sequential encoding uses hierarchical event-state tensors; PPM-OC and instead flatten logs around one object type.The graph-attention-embedded LSTM in outperforms its LSTM and ProcessTransformer baselines on most object types and prediction targets.Source: §2.3 · pp. 8–9
  • Graph-based encoding preserves object-event topology for GNN prediction, and prior work explores heterogeneous graphs, directly-follows graphs, graph architectures, and global monitoring.Reported benefits are conditional: finds improved remaining-time prediction by combining GNNs with object-centric features, whereas finds richer models do not automatically improve predictions; reports the strongest remaining-time and event-count accuracy for attention-based encodings.Source: §2.3 · p. 9

3. An Object-Centric Representation of Collaborative Processes

The section defines a transformation from collaborative event logs to an OCED-conformant object-centric representation, serialized in OCEL 2.0. It makes collaboration entities and relations explicit while preserving source information and guaranteeing checkable consistency criteria.

3.1. Design decisions

  • The mapping accommodates logs without individual-organization identifiers, message correlation, or native local-execution identifiers by representing interactions separately and identifying executions by case and participant.It also embeds per-case source order in event identifiers, keeps object attributes static, and preserves source activity attributes even when corresponding relations are materialized.Source: §3.1 · p. 10

3.2. Mapping rules

  • The mapping represents collaboration cases, participants, participant-local executions, messages, and activity instances as explicit objects or events linked by qualified relations.Each participant identifier defines its own object type; an OrchestrationCase makes a participant’s execution within a collaboration directly addressable, while each send or receive interaction becomes a separate Message object.Source: §3.2 · pp. 11, 13
  • Events retain their timestamps, activity types, and source attributes, with event identifiers encoding per-case order and qualified relations connecting them to collaboration cases, local executions, participants, and messages.Orchestration cases link to collaboration cases and participants, while messages link to defined sender and receiver endpoints and their collaboration case; residual data attributes are preserved unchanged.Source: §3.2 · p. 13

3.3. Consistency criteria

  • The transformation’s six automatically checkable criteria ensure trace preservation and coherent message, execution, and participant relations, while preventing orphan objects.For example, sorting a collaboration case’s events by identifier reconstructs its source trace; each message corresponds to exactly one send or receive event, and event-to-participant relations agree with the associated orchestration case.Source: §3.3 · pp. 14–16

4. Object-Centric Definitions of Collaborative Prediction Tasks

The section reformulates all fourteen collaborative prediction tasks over the object-centric log while retaining CollaborationCase as the shared viewpoint, preserving the source-level prefixes. It distinguishes the object that scopes a prefix from the entities a target describes, and defines targets over object relations as well as events.

4.2. Redefining predictions

  • All fourteen tasks use CollaborationCase-scoped object-centric prefixes recoverable as the same source-log prefixes, preserving identical observations for object-centric and source-level targets.The object-centric events are ordered to match the source-log case order.Source: §4 · p. 16, §4.2 · p. 17

4.1. From global traces to viewpoints

  • The framework separates the CollaborationCase viewpoint from target anchors—Message, participant types, OrchestrationCase, or CollaborationCase—so one prefix supports labels about different entities.Anchors follow what a label denotes or ranges over, not the events it quantifies; the distinction is a feature of the object-centric reformulation.Source: §4.1 · pp. 16–17
  • A prediction task is a scoping viewpoint paired with a target function over the object-centric log, fixing ground truth independently of how a predictor encodes its inputs.Definitions use accessors over objects and qualified relations in µ(L), with prefixes matching those of the source log.Source: §4.1 · p. 17, §4.2 · p. 17

4.2. Redefining predictions

  • The fourteen tasks comprise six next-event types, six numeric time-or-count types, and two Boolean outcome types.Next-event message endpoints use message-object relations, and message kind is identified by the communication event type. Numeric counts use message objects whose communication event has not yet occurred; OB-P tests future participant activity and OB-M tests for a future message of a given kind.Source: §4.2 · pp. 17–19
  • Object relations also make prediction targets beyond the fourteen-task case-centric catalog natural, but this reformulation deliberately excludes them.Such targets read relations between objects rather than events of a single flattened case.Source: §4.2 · p. 19

5. Implementation

The section describes how the conceptual representation and task definitions are realized through OCEL 2.0 serialization, ground-truth label computation, and a prediction pipeline; code and materials are available at [18].

5.1. Serialization in OCEL 2.0

  • The converter implements M1–M8, checks P1.1–P1.6 plus export safeguard P1.7, and exports JSON and SQLite OCEL 2.0 logs, validating JSON against its schema.Per-type schemas and timestamped attribute values are serialization conventions; qualified relations store M6–M7 qualifier strings. SQLite feeds the prediction pipeline, while the core mapping remains independent of the analysis tool.Source: §5.1 · pp. 19–20

5.2. Computing the task labels

  • A standalone library computes all fourteen ground-truth targets from qualified object relations, without extracting features or fitting predictors.Labels are pure functions of the log and prefix, with task parameters supplied as arguments; the library depends on the M1–M7 vocabulary, not on the converter or prediction pipeline.Source: §5.2 · p. 20

5.3. Prediction pipeline

  • The prediction pipeline uses ocpa 1.3.3 and object-centric feature extraction to build tabular, per-case sequential, and ancestor-subgraph graph inputs.Features and labels are derived separately from the same imported log and joined by globally unique event identifier.Source: §5.3 · p. 20

6. Empirical Validation

The validation checks the mapping and task reformulation, then tests end-to-end execution of 14 object-centric prediction task types across five logs. It finds zero label mismatches, while predictive metrics and execution costs vary by task, log, and model.

6.1. Datasets

  • Explicit message objects materialize collaboration structure but increase object counts and duplicate participant endpoint information; a fifth log recovers hand-overs heuristically from BPI Challenge 2013 incidents.The BPI-derived log treats organizational lines as participants and incidents as collaboration cases; synthesized send events are flagged rather than presented as directly observed.Source: §6.1 · pp. 21–22

6.2. (RQ1) Semantic transformation to an object-centric representation

  • All five converted logs passed mapping-specific consistency checks and OCEL 2.0 structural validation, supporting materialization of the proposed mapping on the evaluated datasets.Checks compared event attributes, event identifiers and order, relations, and materialized objects against independently recomputed expectations.Source: §6.2 · p. 22

6.3. (RQ2) Verifying the label-preserving task reformulation

  • Across 287 task–parameter combinations, independently computed labels had zero mismatches, including when temporal comparisons used zero tolerance.The two computation paths used the same accessors but applied source-level and object-centric definitions separately, demonstrating internal consistency rather than independent implementation replication.Source: §6.3 · pp. 22–23

6.4. (RQ3) End-to-end feasibility on a native object-centric pipeline

  • The pipeline covers OCEL loading through prediction with collaboration-case grouped five-fold validation, while excluding sentinel targets that remove up to 76.6% of BPIC 2013 cut points for four tasks.Features are computed only from observable prefixes, and all prefixes from a collaboration case remain in one fold.Source: §6.4 · p. 23

6.4.1. Selected models and hyperparameters for OCPM Prediction

  • Representative models span tabular, sequential, and graph encodings; the fixed configurations demonstrate reproducible execution, not predictor superiority.The selected models were Random Forest and XGBoost, Transformer and LSTM, and GNN; one hyperparameter configuration was used across logs, tasks, and folds.Source: §6.4.1 · pp. 23–24

6.4.2. Experimentation results & analysis

  • All 70 task–log combinations completed five-fold execution for five predictors, but results are descriptive: BPIC 2013 exposes limits in numeric prediction, especially for temporal targets.Across the full catalog, 31 of 330 non-degenerate task–log–predictor entries were worse than the trivial baseline; on BPIC 2013, no predictor extracted temporal signal except GNN on NV-PaT (−6.3% against baseline).Source: §6.4.2 · pp. 24–25, Table 8 · p. 26
  • Object-centric models score higher for next-participant prediction, while the case-centric approach scores better for next-message prediction; remaining-time performance is similar in magnitude.These are uncontrolled descriptive comparisons because architectures, preprocessing, and folds were not harmonized; object-centric models also predict remaining-message counts and target-message occurrence without direct Predict-Collab counterparts.Source: §6.4.2 · pp. 25, 27

6.4.3. Execution cost

  • GNN has the highest fitting cost and scales consistently with labeled-prefix count, Random Forest has the highest peak memory, and pipeline stages dominate runtime for less demanding learners.These execution-cost interpretations are conditional because sequence length, relational density, and hardware were not varied independently.Source: §6.4.3 · p. 28, Table 9 · p. 28

7. Benefits and limitations of the object-centric representation

The object-centric representation makes prediction targets, collaborative structure, and analysis viewpoints more explicit and flexible than the case-centric representation, while introducing structural and computational costs. Its limitations delimit which tasks and empirical settings have been demonstrated, without affecting the mapping’s structural correctness.

7.1. Expressiveness of prediction targets

  • A participant object enables targets over collaborations in which that participant is concurrently engaged, a quantity unavailable locally in any single-case taxonomy.On evaluated logs, participant identifiers denote roles or types, so the target concerns concurrent role engagement; instance-level organizational identifiers would instead support organization-level targets. The catalog remains fourteen task types, and this additional target remains unformalized and unevaluated.Source: §7.1 · p. 29

7.2. Explicit collaborative structure and traceability

  • Participants, orchestration cases, communication interactions, and collaboration cases become related first-class objects, making participant- and message-centered analyses and event-to-object traceability directly navigable.The case-centric representation requires projection and preprocessing for participant- and message-centered analyses; Figure 3 illustrates tracing events to participants and communication events to messages through relations.Source: §7.2 · p. 29

7.3. Flexibility of analysis viewpoints

  • Selecting an object type sets the analysis viewpoint, while target anchors can differ, allowing one collaboration-case prefix to support participant-, message-, or orchestration-case labels.The current fourteen tasks fix CollaborationCase as the scoping viewpoint to preserve prefixes matching. Alternative viewpoints would define different tasks: OrchestrationCase supports local-execution continuation, participant type supports cross-case workload prediction, and Message has limited sequential value unless modeled as a multi-event object; these alternatives remain unevaluated.Source: §7.3 · p. 29

7.4. Operational cost and behavior at scale

  • Materializing communication interactions increases object and relation counts and serialized-log size, while model-independent processing becomes a first-order cost when the predictor is cheap.Processing takes roughly 6 s per predictor run on four baseline logs and 40–87 s on BPIC 2013; neural training accounts for over 98% of runtime, while on BPIC 2013 processing takes 45 s versus 84 s for Random Forest fitting and 103 s for XGBoost fitting. Aggregate timing does not identify OCEL loading as the bottleneck.Source: §7.4 · p. 30, §7.5 · p. 31
  • Graph-native runtime was 13.71 s per 1,000 labeled prefixes on baseline logs and 13.46 s on BPIC 2013, while Random Forest peak memory shifted from 899 MB to 6,411 MB.The graph-native measurements span an 8.5× scale difference and are the only examined encoding whose per-prefix cost remains stable across the two log groups; this is an experiment-specific observation. Random Forest peak memory on BPIC 2013 was about 40% of machine memory and more than twice the graph-native peak; the whole-run measurement does not identify the stage driving it.Source: §7.4 · p. 30

7.5. Limitations

  • Message pairing is not represented, performers remain event attributes, and an OrchestrationCase aggregates repeated local executions by the same participant within a collaboration case.A send/receive count approximates unmatched-message backlog only under one-to-one matching, eventual completeness, no lost interactions, and send-before-receive assumptions, and cannot identify exchanges. These limits follow from mapping preconditions; promoting such attributes to relations or objects could make them addressable without changing mapping correctness.Source: §7.5 · pp. 30–31
  • On four baseline logs, predictors exceed the trivial baseline on numeric targets in all but four task–log–predictor entries, all on NV-TNE; on the real-life log, none does so reliably.The study cannot separate whether the gap reflects numeric targets in real collaborative processes or unusually predictable targets in the study logs, because log scale and provenance vary together. The reformulation is executable and label-preserving on every log, but demonstrated informative for numeric targets only on curated logs.Source: §7.5 · p. 31

8. Threats to Validity

Following [32], the section assesses conclusion, internal, construct, and external validity. It treats predictive metrics as descriptive evidence and qualifies interpretation by sampling, evaluation, task, and data-provenance limitations.

Conclusion validity

  • RQ3 metrics are descriptive evidence of feasibility and feature informativeness, not rankings, given small baseline samples and fixed, incompletely tuned configurations.The four baseline logs each contain 100 cases; mean and standard deviation are across folds from one fixed-seed run on one machine, not repeated runs or confidence intervals.Source: §8 · pp. 31–32

Internal validity

  • Grouped five-fold splits by collaboration case and prefix-only features mitigate future-information leakage, while an oracle check guards feature–target alignment.For NV-PaT and OB-M, the target parameter is chosen once per log before splitting; metrics therefore characterize the most frequent value, not an expectation over parameter values.Source: §8 · p. 32

Construct validity

  • Mapping correctness and label fidelity are assessed structurally through object-centric relations and two readers using different computation paths, though not independent implementations by different teams.One reader applies source-level definitions to the original log; the other traverses the generated OCEL 2.0 relations.Source: §8 · p. 32
  • On the four baseline logs, NE-NEPr and NE-NEPa induce identical label partitions because no activity is performed by multiple actors, so their scores are identical on three logs and differ little on one.The task types remain distinct by definition; the residual score gap reflects label ordering seen by stochastic components, not a different partition.Source: §8 · p. 33

External validity

  • BPIC 2013’s collaborative structure is interpreted rather than observed: incidents become collaboration instances, organizational lines become participants, and handovers and send interactions are synthesized heuristically.Consequently, negative findings on this log depend on whether that reinterpretation adequately represents the underlying process.Source: §8 · p. 33
  • Generalization is limited by the four logs’ narrow domain range, BPIC 2013’s confounded scale and provenance, and the converter’s dependence on the Predict-Collab schema.The authors note the core mapping could be serialized for other OCED implementations, while making no superiority claim over the collaborative baseline.Source: §8 · p. 33
  • Across 30 classification task–predictor entries, all five predictors exceed the trivial baseline; across 30 regression entries, four are worse by 21.5% to 42.8% of mean relative MAE.GNN is better on four regression tasks, but by under 0.6% on three; the authors report these results descriptively rather than draw a comparative conclusion, and they depend on the BPIC 2013 reinterpretation.Source: §8 · p. 33

9. Conclusions

The paper maps collaborative event logs to an OCEL 2.0 object-centric representation, reformulates fourteen prediction tasks, and provides a reproducible converter and prediction pipeline. Validation confirms the pipeline runs across five logs, while the conclusion notes benefits, costs, and open directions.

9. Conclusions

  • The framework maps extended collaborative event logs to OCED-conformant OCEL 2.0 objects, reformulates fourteen tasks, and supplies a reproducible converter and prediction pipeline.The representation explicitly relates the global collaboration case, orchestration cases, participants, and communication interactions; the pipeline uses three encoding approaches and five corresponding predictive models.Source: §9 · p. 34
  • Across five logs, all 350 task–log–predictor combinations completed five folds without failure, with zero label mismatches and schema-valid OCEL 2.0 outputs.The converter’s outputs satisfied consistency criteria P1.1–P1.6, and the reformulated tasks reproduced source labels on every evaluated prefix. The fifth log, derived from BPI Challenge 2013, is an order of magnitude larger and the study’s only real-life log.Source: §9 · p. 34
  • The representation makes collaboration structure explicit and supports flexible analytical viewpoints and targets beyond the original single-case taxonomy, at the cost of relational complexity and dependence on object-centric tooling.These targets arise naturally from the object-centric structure.Source: §9 · p. 34
  • Future work includes extending the representation’s targets, evaluating additional real-life logs and domains, searching hyperparameters, and comparing predictive performance with case-centric methods.Potential extensions include relating the two interactions of one logical message, assigning performers their own identities, and separating repeated instantiations of a participant’s local process. The current real-life log cannot disentangle effects of scale from provenance; systematic hyperparameter search is a prerequisite for enriching native object-centric features or evaluating a second real-life log.Source: §9 · p. 34

Appendix A. Formal definitions of the mapping

Appendix A formalizes the mapping from extended collaborative event logs to object-centric logs and establishes the criteria for checking its consistency.

Extended collaborative event log

  • The source log defines cases, participants, activities, event types, endpoints, residual attributes, and a per-case event order that sorts by timestamp and breaks ties by original appearance.Events from different cases remain incomparable under this order, which is total within each case and preserves each case’s trace order through the mapping.Source: Appendix A · pp. 34–35

Normalization

  • Normalization fills a missing send or receive event’s own endpoint from its participant, but leaves an unrecorded counterparty endpoint undefined rather than inferring it.The mapping still creates a Message object when a counterparty is missing, while omitting the corresponding relation and sender or receiver attribute; recorded own-side disagreements remain visible.Source: Appendix A · pp. 35–36

Representation of source domains

  • The timestamp encoding must preserve order and differences so decoded time-based task outputs agree with source-level durations; formal source terms denote their encoded images.Durations are values rather than instants, and the inverse used for an output is selected by the task’s declared return type.Source: Appendix A · pp. 37–38

Objects and object types (M1–M4)

  • Each collaboration case, participant, participant–case orchestration, and send or receive event maps to a corresponding object, with each communication event creating its own Message.Participant objects have log-level scope, while orchestration objects are identified by a collaboration case and participant; the mapping does not link distinct send and receive events as one interaction.Source: Appendix A · p. 39

Attribute mapping

  • The mapping retains structural and residual event attributes alongside relations, while sender and receiver object attributes duplicate defined from/to relations for consistency checking.Static object attributes are assigned at timestamp 0, and attributes are represented per event or object type to keep their sets disjoint.Source: Appendix A · pp. 37, 40, 41

E2O relations (M6). With qualifiers

The mapping yields an OCEL 2.0-conformant object-centric event log for any extended collaborative log and satisfies consistency criteria P1.1–P1.6 for well-formed logs. Its participant access paths are type-independent, while its OCED Core conformance follows by reducing the OCEL 2.0 representation.

E2O relations (M6). With qualifiers

  • For every extended collaborative log, whether well formed or not, the mapping produces an object-centric event log conforming to the OCEL 2.0 metamodel.The construction’s naming, typing, and relation targets are well-defined, including participant objects created for every participant in the log.Source: E2O relations (M6). With qualifiers · pp. 41–42
  • The mapping also reduces to an instance of the OCED Core Model after per-type schemas and object-attribute timestamps are forgotten, distinct from its OCEL 2.0 serialization.Object attributes use only reference timestamp 0, and the per-type schema supports machine-checkable typing but is not needed for the OCED Core reduction.Source: E2O relations (M6). With qualifiers · p. 42
  • For every well-formed log, µ(L) satisfies P1.1–P1.6, although only P1.3 depends on well-formedness.Normalization supplies the from/to condition when endpoints are recorded, provided any recorded own-side endpoint agrees with collab:participant; event sequences are reconstructed by event-identifier order, not timestamps, when queried in ≺ev order.Source: E2O relations (M6). With qualifiers · pp. 42–43
  • The in_participant, for_participant, from, and to qualifiers target participant objects only, making participants addressable without naming a participant object type.Under M2, P1.4 is the exception because the participant identifier is encoded in the object type as well as the name attribute; with one Participant type, that criterion instead concerns the name attribute alone.Source: E2O relations (M6). With qualifiers · pp. 43–44

Appendix B. Formal definitions of the collaborative prediction tasks

Appendix B formalizes fourteen collaborative prediction tasks over the object-centric representation, defining their labels and their equivalence to source-level interpretations of within the stated scope. The definitions use transported collaboration-case event sequences and explicit participant, message, and orchestration-case relations, with special handling for no-target and degenerate cases.

Definition domain and accessors

  • Each task uses the transported collaboration-case event prefix, whose events preserve source order, and accessors identify each event’s cases, participant, direction, and message object.The transported and source prefixes are interchangeable observations, but the definitions apply accessors to the object-centric prefix.Source: Appendix B · pp. 44–45

Participant-specific tasks

  • Participant-specific tasks predict a participant’s next message, remaining execution time, remaining messages, or whether that participant acts after the prefix.Participants are quantified over the full participant set, including those with no events in the case; their orchestration case is treated as empty when it is not materialized.Source: Appendix B · pp. 45–49

Next-event and next-message tasks

  • Next-event tasks predict the next event type, acting participant, event-participant pair, or direction-specific message endpoint; next-message tasks predict the next message event type.The message-endpoint task reads the endpoint through the message object’s from or to relation, depending on direction.Source: Appendix B · pp. 45–46

Time-valued tasks

  • Time tasks predict process or participant remaining time, time until the next event, or time until the next message in a selected direction.Participant remaining time returns zero when no later participant event exists, including when that participant never acts in the case. The time-until-next-event definition resolves an inconsistency in the referenced task formulation in favor of a duration; the next-message definition accepts a target at the final trace position and uses ⊥ when none exists.Source: Appendix B · pp. 47–48

Count and Boolean tasks

  • Count and Boolean tasks predict remaining message objects for a case or participant, future participant activity, or occurrence of a specified message-activity label.A message remains at the cutoff when its communication event occurs later; the message-label task returns false for ordinary task labels that no message event carries.Source: Appendix B · pp. 48–49

Proposition 2: label equivalence

  • For all fourteen task types, the object-centric and stated source-level definitions return equal labels for every collaboration case, prefix, and applicable parameter.The proposition requires a well-formed source log and applies both definitions to representations of the same prefix; their no-target and degenerate branches agree as well.Source: Appendix B · pp. 50–51

Coverage

  • Three tasks restate unchanged, five adapt published formulas, and six are reconstructed from Table 2 descriptions; the equivalence is to these explicit interpretations.[3] formalizes nine predictions, eight corresponding to the fourteen types; its additional Definition 7 prediction is outside this reformulation.Source: Appendix B · pp. 51, 53

Scope: the remaining reading only

  • For NV-NMPa, NV-NMPr, NV-PaT, and NV-PrT, Proposition 2 covers only the prefix-dependent remaining reading, not the total or duration reading.The appendix applies this scope on both the source and object-centric sides.Source: Appendix B · p. 52

Proof

  • The proof matches event positions and selection conditions, then handles fixed-index, searched-index, and set-valued targets before decoding outputs to their source values.The accessor identities ensure matching values; set-based counts use a bijection between message events and message objects.Source: Appendix B · pp. 52–53

Departures from a literal restatement

  • Five adapted tasks make explicit changes to parameterization, fallbacks, output representation, duration interpretation, or the domain of participant-time prediction.NE-NEPa returns a pair instead of concatenated text; NE-NPaM and NV-TNM generalize to send and receive with ⊥ fallbacks; NV-TNE returns duration; NV-PaT includes non-acting participants with fallback 0.Source: Appendix B · p. 54

Scope of the equivalence

  • Proposition 2 establishes pointwise equivalence between the fourteen object-centric targets and their stated source-level readings for every well-formed extended collaborative log.The proposition concerns the displayed source interpretations, not the cited formulas read literally.Source: Appendix B · pp. 51, 55

Generality

  • The result applies regardless of dataset, but targets requiring real-world send–reception correspondence or definitions absent from the fourteen-task taxonomy remain outside its scope.The mapping treats sends and receives as independent message objects and asserts no correspondence between them.Source: Appendix B · p. 55

Appendix C. Full-catalog experimentation results

Appendix C reports full-catalog experimental results for all 14 reformulated tasks across five logs. The tables mark rounded near-perfect scores and degenerate targets, but per-row extremes are not rankings and may overlap within one standard deviation.

Appendix C. Full-catalog experimentation results

  • Tables C.11 and C.12 present full-catalog results for all 14 reformulated tasks across five logs.The tables split the results into two parts.Source: Appendix C · p. 55, Table C.11 · p. 56, Table C.12 · p. 57
  • Per-row extremes are not rankings: models may tie, and the two marked models overlap within one standard deviation across folds in half of the rows.Best and worst are indicated at the same precision; best is bold and worst is underlined.Source: Appendix C · p. 55
  • Times are in seconds except for BPIC 2013 (*), which is reported in days; † marks near-perfect scores, ‡ degenerate targets, and § metrics worse than the trivial baseline.Near-perfect scores and near-zero errors are identified under two-decimal rounding; for ‡ targets, the trivial baseline rounds to a perfect score.Source: Appendix C · p. 55

CRediT authorship contribution statement

The authors’ contributions span conceptualization, research, software, validation, and writing, with roles distributed across four authors.

CRediT authorship contribution statement

  • Daniel Calegari contributed to conceptualization, methodology, investigation, formal analysis, software, validation, and writing; Andrea Delgado to conceptualization, investigation, validation, and review; Leonel Peña and Martín Rubio to software and validation.Calegari is credited with original-draft writing and review and editing; Delgado with review and editing.Source: CRediT authorship contribution statement · p. 58

Declaration of competing interest

Andrea Delgado recused herself from the article’s peer review as Guest Editor, and the other authors declared no known competing financial interests or personal relationships that could have influenced the work.

Declaration of competing interest

  • As Guest Editor, Andrea Delgado had no involvement in this article’s peer review and no access to information about it; another journal editor had full editorial responsibility.The declaration attributes the recusal to Delgado’s role in the special issue.Source: Declaration of competing interest · p. 58
  • The other authors declared no known competing financial interests or personal relationships that could have influenced the reported work.Source: Declaration of competing interest · p. 58

Declaration of generative AI and AI-assisted technologies in the manuscript preparation process

The authors used Claude, ChatGPT, and Gemini during manuscript preparation, then reviewed and edited the content and took full responsibility for the published article.

Declaration of generative AI and AI-assisted technologies in the manuscript preparation process

  • The tools assisted with drafting and language refinement, structuring the conceptual and methodological argumentation, and code generation; the authors reviewed and edited the content as needed.The authors stated that they took full responsibility for the published article.Source: Declaration of generative AI and… · p. 58
Loading 2608.27671v1…