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 PPM needs to represent interdependent participants, messages, local executions, and global cases more explicitly than single-case logs allow. The paper maps extended collaborative logs to OCED- and OCEL 2.0-based object-centric data, reformulates fourteen prediction tasks, and implements a reproducible pipeline. Across five logs, the representation and tasks validate and execute end-to-end, while the resulting structure supports relational targets at the cost of greater complexity and tooling dependence.

  • Problem

    Collaborative PPM extends event logs with collaboration attributes but retains a single-case perspective, leaving collaboration-specific entities, relations, and targets implicit.

  • Method

    The paper defines an OCED-conformant semantic mapping serialized in OCEL 2.0, reformulates fourteen collaborative tasks object-centrically, and provides a reproducible converter and prediction pipeline.

  • Results

    All 350 task–log–predictor combinations completed five folds without failure, with valid representations and zero mismatches between reformulated and source labels.

  • Takeaways & Limitations

    The representation makes collaboration structure explicit and supports prediction targets over object relations beyond the original single-case taxonomy.

  • Takeaways & Limitations

    Predictor calibration for LSTM and Transformer was exploratory rather than systematic, so their metrics do not reflect systematically tuned configurations.

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 must handle multiple autonomous participants, local executions, and message exchanges, but existing approaches largely retain an implicit single-case representation. This paper maps collaborative logs to object-centric data, reformulates fourteen tasks, and evaluates the resulting pipeline across five logs and five predictive strategies.

  • Collaborative processes coordinate multiple autonomous participants through messages while each participant executes its own internal orchestration.
  • Traditional PPM assumes that each event belongs to one case and predicts from that case’s prefix.
  • Existing collaborative logs encode participants and message endpoints as event attributes within traces, leaving collaboration structure implicit.
  • The paper maps extended collaborative logs to an OCED-conformant representation serialized in OCEL 2.0, with formal rules, consistency criteria, and automated verification.
  • Fourteen case-centric collaborative prediction tasks are reformulated object-centrically, allowing targets over objects and relations that a flattened case cannot express.
  • The end-to-end evaluation covers five logs, three encodings, and five predictive strategies without proposing a new prediction model.
  • The mapping and reformulation satisfy validation and execution checks across all five logs, while categorical and structural targets generally exceed trivial baselines but numeric targets do not on the real-life log.

2. Background and Related Work

The background introduces collaborative processes, object-centric event data, and predictive monitoring as complementary perspectives. It motivates the paper’s mapping by contrasting explicit multi-object relations with case-centric encodings and by identifying missing collaboration-specific object-centric prediction support.

  • Collaborative business processes: A collaborative business process spans autonomous participants, internal orchestrations, and message exchanges, illustrated through a healthcare scenario involving a patient, gynecologist, hospital, and laboratory.
  • Collaborative business processes: A collaboration case covers an end-to-end execution, whereas orchestration cases capture participants’ local process executions and activity instances capture individual participant events.
  • Collaborative business processes: Distributed collaborative logs face fragmented visibility, privacy requirements, divergent objectives, and asynchronous events; this work leaves integration challenges such as message correlation out of scope.
  • Object-centric process mining: Object-centric event data associates events with multiple objects and supports multiple case viewpoints, avoiding distortions caused by flattening interacting entities onto one case notion.
  • Object-centric process mining: The OCED Core Model provides a minimal, storage-independent foundation of events, objects, attributes, and directed binary object-to-object relations.
  • Object-centric process mining: OCEL 2.0 serializes object-centric logs in typed object classes and extends the OCED base model with per-type schemas and timestamped object attributes.
  • Predictive process monitoring: PPM forecasts properties of running cases from prefixes, including next activities, outcomes, and remaining time, using classical and neural approaches.
  • Predictive process monitoring: Prior collaborative PPM extends case-centric logs with collaboration attributes and defines fourteen collaborative prediction types, while object-centric PPM had not addressed collaboration-specific targets such as next participants or messages.

3. An Object-Centric Representation of Collaborative Processes

The paper maps collaborative event logs to an OCED-conformant object-centric representation serialized in OCEL 2.0. The representation makes participants, messages, local executions, and global collaboration cases explicit objects connected by qualified relations.

  • Representation: The model-to-model transformation maps collaborative event logs to an OCED Core Model representation and serializes it in OCEL 2.0.Formal mapping rules and consistency criteria define the transformation; alternative representations remain possible.
  • Object types: The representation distinguishes organizational participant objects, message interaction objects, and CollaborationCase and OrchestrationCase execution-scoping objects.Each participant identifier receives its own object type, while orchestration cases represent participant-local executions within collaborations.
  • Mapping rules: Message objects represent individual recorded send or receive interactions rather than centrally correlated send–receive exchanges.The source format does not guarantee message identifiers or correlation information, so each interaction is modeled separately.
  • Design decisions: The transformation preserves source activity attributes and embeds per-case order in event identifiers, while keeping object attributes static.The converter implements rules M1–M8 and automatically checks six formal consistency criteria.
  • Mapping rules: Each source activity event becomes one object-centric event linked to its collaboration case, orchestration case, and participant through qualified E2O relations.The direct participant relation is retained alongside the in_orchestration–for_participant path.

4. Object-Centric Definitions of Collaborative Prediction Tasks

The fourteen collaborative prediction tasks are reformulated over an object-centric log while retaining CollaborationCase as the common scoping viewpoint. This preserves source-level prefixes while allowing targets to range over distinct object categories and relations.

  • Scoping viewpoints: All fourteen tasks retain CollaborationCase as the scoping viewpoint, so object-centric and source-level predictions use the same global execution prefixes.The mapping criterion P1.2 makes each object-centric prefix recoverable from the corresponding source prefix.
  • Target anchors: Target anchors identify the entity category denoted or quantified by a label, including Message, participant types, OrchestrationCase, and CollaborationCase.The anchor need not coincide with the object type that scopes the prediction prefix.
  • Task semantics: An object-centric task is defined by a scoping viewpoint and a target function over the object-centric log, independently of feature extraction or model fitting.The target for each prefix is therefore a property of the log rather than of a particular predictor.
  • Prediction types: The reformulated catalog preserves next-event, numeric-value, and outcome-based task types while also enabling future targets over relations between objects.The fourteen-task catalog deliberately remains aligned with the case-centric taxonomy and does not include these additional relational targets.
  • Prediction types: Remaining-message predictions count message objects whose communication events occur after the cutoff, converting an object-level quantity into a prediction target.Each send and receive interaction is a distinct message object under rule M4.

5. Implementation

The implementation realizes the representation and task definitions through OCEL 2.0 serialization, standalone label computation, and native object-centric feature extraction. Separate derivation paths join features and labels on globally unique event identifiers before prediction.

  • Serialization: The implementation serializes the representation in OCEL 2.0, computes task labels over the serialized log, and supplies a prediction pipeline built from the same conceptual definitions.The framework’s code and materials are made available for reproducibility.
  • Converter: The converter implements rules M1–M8, checks criteria P1.1–P1.6, exports JSON and SQLite, and validates the JSON output against the OCEL 2.0 schema.SQLite is consumed directly by the prediction pipeline, while P1.7 safeguards export reachability through PM4Py.
  • Labels: A standalone label library computes ground-truth targets from qualified E2O and O2O relations without extracting features or fitting models.Its label functions are pure functions of the log and parameterized tasks receive their task-specific arguments explicitly.
  • Labels: The label library depends on the object vocabulary and relation qualifiers rather than on the converter or prediction pipeline, allowing independent use with structurally compatible object-centric logs.This separates task computation from the tool that produced the log.
  • Feature pipeline: ocpa 1.3.3 provides native OCEL 2.0 import, event graphs, and tabular storage, while the pipeline builds sequential stacking and graph ancestor subgraphs on top.Features and labels follow separate derivation paths and are joined using globally unique event identifiers.

6. Empirical Validation

The evaluation validates the object-centric mapping and label reformulation across five logs, then assesses end-to-end execution, predictive behavior, and computational cost across task types and model families.

  • Validation: 172 task–log–parameter combinations across four baseline logs produced zero mismatches over 279,400 target labels, confirming label preservation.The full-scale BPIC 2013 check likewise found zero mismatches across 115 task–parameter combinations and 7,133,450 labels.
  • End-to-end feasibility: All 70 task–log combinations completed five-fold execution for each of five predictors across the fourteen task types.The workflow covered OCEL loading, viewpoint selection, prefix construction, feature extraction, target generation, training, and prediction.
  • Interpretation: The native event-to-object and object-to-object representation supports holistic monitoring of concurrent participant interactions, but materializes more objects and relational complexity.Message counts include separate Message objects for observed send and receive interactions, preserving the mapping information.
  • Predictive results: Structural and categorical targets generally exceeded trivial baselines, while temporal targets on BPIC 2013 showed little extracted signal except for GNN on NV-PaT.The GNN was within 0.15–0.54% of the median baseline on three temporal targets, while its NV-PaT result was −6.3% against baseline.
  • Validity and cost: The cross-paradigm observations are descriptive rather than controlled comparisons because architecture, preprocessing, and folds were not harmonized.Predict-Collab used only the Process Transformer, making the object-centric Transformer the primary comparison baseline.
  • Predictive results: Object-centric prediction scored higher for next-participant classification than the case-centric baseline, consistent with explicit multi-object bindings supplying structural context.The passage qualifies this pattern as consistent with, but not proof of, structural binding aiding participant prediction.
  • Predictive results: Next-message prediction favored the flattened case-centric approach, whereas remaining-time performance was similar in magnitude between paradigms.The object-centric approach also supports message-count and target-message predictions without direct numerical counterparts in the comparison study.
  • Validity and cost: GNN had the highest fitting cost, Random Forest the highest peak memory requirement, and model-independent stages dominated runtime for less demanding learners.GNN fitting cost scaled consistently with labeled-prefix count, while XGBoost demand varied with task characteristics including multiclass label cardinality.

7. Benefits and limitations of the object-centric representation

The object-centric representation improves target expressiveness, makes collaborative structure explicit, and supports flexible viewpoints, but introduces structural, operational, scalability, and predictive-scope costs.

  • Expressiveness of prediction targets: Object relations enable prediction targets, such as concurrent participant engagement across collaborations, that cannot be read locally from a single flattened case.The fourteen reformulated tasks remain the catalog, while formalizing and evaluating additional relation-based targets is left for future work.
  • Explicit collaborative structure and traceability: Participants, orchestration cases, communication interactions, and collaboration cases become explicit, navigable objects supporting participant- and message-centered analysis and traceability.Relations connect events to participants and communication events to messages without attribute filtering.
  • Flexibility of analysis viewpoints: Selecting an object type as the viewpoint decouples analysis scope from target anchors, allowing common prefixes to support participant-, message-, and orchestration-case labels.The evaluated reformulation fixes CollaborationCase as the scoping viewpoint, while alternative viewpoints remain possible.
  • Structural and operational costs: Materializing communication interactions as objects increases object and relation counts, serialized-log size, and preprocessing costs.Model-independent stages take roughly 6 seconds on four baseline logs and 40–87 seconds on BPIC 2013; for tabular predictors, preprocessing is comparable to training.
  • Behavior at scale: 13.71 s versus 13.46 s per 1,000 labeled prefixes makes graph-native runtime stable across the evaluated log groups, unlike the other encodings.This observation is experimental rather than a general predictability claim because sequence length, relational density, and hardware were not independently varied.
  • Representation limitations: Message-pairing, individual-performer identity, and repeated local-execution identity remain insufficiently represented for corresponding prediction targets.Send–receive backlog estimates require assumptions about one-to-one matching, completeness, no losses, and event ordering; repeated local executions may be aggregated.
  • Empirical predictive scope: Numeric-target performance exceeds trivial baselines on most curated-log entries but does not do so reliably on the real-life log, limiting the demonstrated predictive scope.The study cannot distinguish whether this reflects unexplained variance in the real process or unusually predictable numeric targets in curated logs.
  • Scope of validity: These limitations delimit the established scope without undermining the mapping’s structural correctness or the reformulated tasks under the stated interpretations.Future refinements could promote message correlation, actor identity, and local-execution identity into more addressable object-centric structures.

8. Threats to Validity

The study treats validity threats across conclusion, internal, construct, and external dimensions, using controls while limiting generalization of the empirical findings.

  • Conclusion validity: 100 collaboration cases per baseline log provide a small sample for estimating per-task predictive performance under class imbalance.
  • Conclusion validity: The evaluation reports metrics descriptively because the larger BPI log is still a single real-life log and predictors use one fixed configuration.
  • Internal validity: Grouped five-fold cross-validation partitions collaboration cases, keeping all prefixes together and restricting features to observable prefixes.
  • Internal validity: The two parameterized tasks resolve their target parameter once per log before fold splitting, defining the evaluated target without fold-specific selection.
  • Construct validity: The mapping and label fidelity are assessed structurally through independent source-log and generated-OCEL computation paths.
  • Construct validity: NE-NEPr and NE-NEPa induce identical label partitions on baseline logs because no activity is performed by multiple actors.
  • External validity: The four public logs cover a narrow domain range, while BPIC 2013 combines larger scale, real provenance, and heuristic collaboration reinterpretation.
  • External validity: On BPIC 2013, all five predictors exceed the trivial baseline for six non-degenerate classification types, whereas regression performance is generally worse or marginally better.

9. Conclusions

The paper connects collaborative and object-centric predictive monitoring through a formal representation, task reformulation, and executable pipeline. Validation across five logs supports operational feasibility while exposing relational and tooling costs and several open extensions.

  • The framework maps extended collaborative event logs to OCED-conformant OCEL 2.0 data with explicit collaboration cases, orchestration cases, participants, and communication objects.
  • Fourteen collaborative prediction tasks are reformulated over object-centric objects and relations, enabling targets beyond the single-case taxonomy.
  • Five logs validate the converter, label equivalence, and end-to-end task execution, including an order-of-magnitude-larger BPI Challenge 2013-derived log.
  • The representation makes collaboration explicit and supports flexible viewpoints and object-relational targets, at the cost of larger relational structures and dependence on object-centric tooling.
  • Open directions include message pairing, performer identity, repeated local-process instances, additional real-life logs, systematic hyperparameter search, and cross-domain validation.

Appendix A. Formal definitions of the mapping

Appendix A formalizes the mapping from extended collaborative logs into object-centric event data, including domain encodings, object creation, normalization, attributes, and relations.

  • The source log is defined as events with collaboration cases, participants, activities, timestamps, event elements, endpoints, residual attributes, and an ordering.
  • Prefix conventions exclude single-event collaboration cases because they have no valid prefix length under the stated range.
  • Normalization backfills an omitted send or receive event endpoint only from the event’s own participant, leaving an unavailable counterparty undefined.
  • Event and object attributes use per-type conventions, while event-to-object and object-to-object relations are qualified separately.
  • Injective encodings preserve source identifiers, timestamps, ordering, values, and durations within the OCEL universes.
  • The transformation µ(L) is defined component-wise as an object-centric event log with typed events, objects, attributes, timestamps, and relations.
  • Collaboration cases, participants, orchestration cases, and message objects are created with distinct object types and identifiers.

E2O relations (M6). With qualifiers

The mapping uses qualified relations to connect events and objects while preserving participant identity and supporting OCEL 2.0 conformance. Its construction is formally well-defined and satisfies the stated consistency criteria.

  • The in_participant path agrees with the two-step in_orchestration–for_participant path for each event.
  • The qualifier vocabularies are kept disjoint as a mapping presentation choice rather than an OCEL 2.0 requirement.
  • The construction µ(L) is well-defined for every extended collaborative log and conforms to the OCEL 2.0 metamodel.
  • The OCED-aligned representation distinguishes qualified event-to-object and object-to-object relations within the OCEL 2.0 metamodel.
  • For every well-formed source log, µ(L) satisfies consistency criteria P1.1–P1.6.
  • Consistency follows from injective naming, preserved event properties, reconstructed case order, and relations targeting objects created by the mapping.
  • Participant objects are reachable through in_participant, for_participant, from, and to relations without naming participant object types.

Appendix B. Formal definitions of the collaborative prediction tasks

Appendix B defines the fourteen collaborative prediction tasks over object-centric collaboration-case prefixes, using explicit event, object, and relation accessors. It establishes label equivalence with source-level tasks while documenting scope decisions and generality conditions.

  • Formalization: The task definitions operate on transported collaboration-case event sequences and object-centric prefixes rather than directly on source-event sequences.The mapping preserves event order, while accessors are defined over events in the generated object-centric log.
  • Formalization: The accessors identify each event’s orchestration case, collaboration case, participant, and related message objects through explicit qualifiers.Message events are linked to message objects through send or receive relations, and each event has unique orchestration-case and collaboration-case objects.
  • Task definitions: The catalog includes next-event, next-participant, joint event-and-participant, and direction-specific message-participant predictions.The message-participant task predicts the participant at the selected endpoint of the next send or receive event.
  • Task definitions: The joint next-event-and-participant target is semantically a pair, although the source tool concatenates it into a single string for single-column input.Proposition 2 compares the underlying pair rather than the concatenated presentation string.
  • Equivalence: Proposition 2 establishes equivalence between each object-centric task and its source-level counterpart under the stated interpretations.The equivalence concerns the fourteen tasks in the cited taxonomy and rules out discrepancies introduced by the mapping.
  • Equivalence: Set-valued message counts and Boolean tasks are shown equivalent through event-to-message bijections and corresponding existential conditions.The proof compares matching filtered sets for counts and matching existence conditions for Boolean outputs.
  • Scope and assumptions: The equivalence scope excludes targets outside the fourteen-task taxonomy and adopts prefix-dependent duration readings for the affected time-related tasks.The formalization also extends the zero-duration fallback to participants with no events in a case and applies the same reading on both sides.
  • Scope and assumptions: The mapping applies to every well-formed extended collaborative log, with normalization handling missing own-side endpoints but surfacing disagreements.Its core treatment represents each send and receive as independent message events.

Appendix C. Full-catalog experimentation results

Appendix C reports the full-catalog results for all fourteen reformulated tasks across five logs. The tables use seconds except for BPIC 2013, mark near-perfect or degenerate rows, and identify per-row extremes without presenting a global ranking.

  • Experimental catalog: All fourteen reformulated tasks are evaluated across five logs in the full-catalog experimental tables.The results are divided between Table C.11 and Table C.12.
  • Reporting conventions: Times are reported in seconds, except for BPIC 2013, whose time values are reported in days.The unit distinction is stated in the table notes.
  • Reporting conventions: The tables mark models at or near perfect scores, constant targets with trivial-baseline perfection, and models worse than the trivial baseline.Per-row best and worst values are also marked at the displayed precision.
  • Reporting conventions: Per-row extremes are not a ranking because models may tie and many marked differences overlap within one standard deviation.The comparison is therefore row-specific rather than an overall ordering of models.

CRediT authorship contribution statement

The CRediT statement assigns conceptualization, investigation, validation, and writing across the authors, with software and formal analysis concentrated among specific contributors.

  • Contributions: Daniel Calegari is credited with all listed contribution categories, including conceptualization, methodology, software, validation, and writing.The statement also credits him with investigation and formal analysis.
  • Contributions: Andrea Delgado contributed conceptualization, investigation, validation, and writing, while Leonel Peña and Martín Rubio contributed software and validation.

Declaration of competing interest

The declaration reports no known competing financial interests or personal relationships among the authors and describes a peer-review recusal for the guest editor.

  • Editorial independence: Andrea Delgado did not participate in peer review because she was the guest editor of the special issue.Responsibility for the editorial process was delegated to another editor.
  • Competing interests: The other authors declare no known competing financial interests or personal relationships that could have influenced the reported work.

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

The authors used Claude, ChatGPT, and Gemini to assist with manuscript drafting, language refinement, argument structuring, and code generation, then reviewed and edited the content.

  • Claude, ChatGPT, and Gemini assisted with drafting, language refinement, conceptual and methodological structuring, and code generation.The authors reviewed and edited the resulting content and retained full responsibility for the published article.
Loading 2608.27671v1…