Object-Centric Petri Nets Overview

• Object-Centric Petri Nets (OCPNs) are models that extend traditional Petri nets by incorporating multiple object types and variable arcs to capture intertwined object lifecycles.
• They address challenges in object-centric event logs by mitigating issues such as deficiency, convergence, and divergence, thus improving process discovery and analysis.
• OCPNs facilitate holistic process modeling with capabilities in conformance checking, performance analysis, and extensions into identifier-aware and data-aware frameworks.

Object-Centric Petri Nets (OCPNs) are Petri-net-based models for processes in which events are related not to one case identifier but to multiple objects of possibly different types. In the standard formulation, an OCPN is an object-centric Petri net $ON=(N,pt,F_{var})$, where $N=(P,T,F,l)$ is a labeled Petri net, $pt:P\to OT$ types places by object type, and $F_{var}\subseteq F$ designates variable arcs. This shifts process mining from single-case traces to multiple intertwined object lifecycles and their interactions, making OCPNs the central formalism for object-centric discovery, conformance checking, precision and fitness analysis, performance analysis, and a range of later identifier-aware and data-aware extensions (Aalst et al., 2020, Liss et al., 2023, Park et al., 2022, Benzin et al., 2023).

1. Object-centric event data and the departure from case-centric logs

The conceptual starting point of OCPNs is the object-centric event log. Instead of assuming a simple event log $L\in \bag(act^*)$, object-centric work models an event as

$e=(ei,act,time,omap,vmap),$

where $ei$ is a unique event identifier, $act$ is the activity label, $time$ is the timestamp, $omap$ maps object types to sets of object identifiers involved in the event, and $N=(P,T,F,l)$0 is an attribute-value map. A common OCEL definition is $N=(P,T,F,l)$1, with $N=(P,T,F,l)$2 a partial order consistent with timestamps; related work on conformance uses $N=(P,T,F,l)$3, and performance analysis introduces a start/completion-time variant $N=(P,T,F,l)$4 (Aalst et al., 2020, Benzin et al., 2023, Liss et al., 2023, Park et al., 2022).

This event model generalizes classical case-based logs because a single event may refer to mixtures of orders, items, packages, customers, products, applications, offers, tests, or samples. The central implication is that there is no single universally correct case notion. Flattening an object-centric log by one object type may therefore create the well-known problems of deficiency, convergence, and divergence: events may disappear because they do not mention the chosen type, may be duplicated because they refer to several objects of that type, or may induce spurious causal relations because behavior is projected onto an inappropriate case perspective (Aalst et al., 2020).

Several later techniques retain this object-centric viewpoint rather than reconstructing a single trace. One conformance line defines an object graph $N=(P,T,F,l)$5 with an edge between two objects if they co-occur in an event, and takes connected components of this graph as process executions. Another line uses trace graphs induced by object-wise successor relations. These constructions formalize the idea that the execution of a process is not a single sequence but a graph of events determined by interacting objects (Liss et al., 2023, Gianola et al., 2023).

2. Formal structure, markings, and firing semantics

An OCPN is a labeled Petri net enriched with object typing and variable-flow behavior. In the standard definition,

$N=(P,T,F,l)$6

places are typed by object type, transitions are labeled by activities or $N=(P,T,F,l)$7, and variable arcs allow a transition to consume or produce a variable number of objects of a given type (Liss et al., 2023, Aalst et al., 2020).

The semantics differs from ordinary Petri nets because tokens are not anonymous. A possible token is a typed place-object pair

$N=(P,T,F,l)$8

and a marking is a multiset over these tokens. Transition firing is defined through a binding $N=(P,T,F,l)$9, where $pt:P\to OT$0 assigns to each object type around $pt:P\to OT$1 the set of object identifiers participating in the firing. Consumed and produced tokens are given by

$pt:P\to OT$2

$pt:P\to OT$3

and firing updates the marking by

$pt:P\to OT$4

For non-variable object types, exactly one object is bound; for variable object types, a set of objects may be bound (Liss et al., 2023, Adams et al., 2021).

A central well-formedness condition states that, for a given transition and object type, arcs are either all variable or all non-variable: $pt:P\to OT$5 This prevents mixed semantics under which objects of one type could effectively disappear during firing. The same concern is expressed in discovery work: if a transition has both variable and non-variable arcs for the same object type, objects could “disappear,” which is not allowed (Liss et al., 2023, Benzin et al., 2023).

Many analyses use an accepting OCPN $pt:P\to OT$6 or $pt:P\to OT$7. The accepted behavior is defined as the set of binding sequences taking the model from the initial to the final marking, usually after projecting away silent transitions. This accepting form is the basis for discovery output, conformance checking, precision/fitness, and performance replay (Aalst et al., 2020, Adams et al., 2021).

3. Discovery of OCPNs and the move toward holistic process models

The discovery pipeline introduced for OCPNs is deliberately modular. Starting from an object-centric event log, the procedure first flattens the log once per object type, then discovers a sound accepting Petri net for each flattened log, merges the nets by unifying same-labeled transitions, assigns place types, identifies variable arcs, and lifts initial and final markings to the object-centric level (Aalst et al., 2020, Benzin et al., 2023).

A characteristic component of this pipeline is the identification of variable arcs through an activity-type score. For an activity $pt:P\to OT$8 and object type $pt:P\to OT$9,

$F_{var}\subseteq F$0

and arcs for which the score falls below a threshold $F_{var}\subseteq F$1 are marked as variable. This gives a discovery-friendly approximation of one-to-many behavior from observed event-object multiplicities (Aalst et al., 2020).

The output is a holistic model rather than a family of disconnected per-type models. Discovery work emphasizes that such a model can be used to drill down into specific viewpoints if needed, while avoiding the modeling bias created by committing prematurely to one case notion. The implementation reported for this discovery approach is in PM4Py via PM4Py-MDL, with import/export support including MDL, Parquet, and XOC, and with token-based replay for conformance and performance annotations (Aalst et al., 2020).

OCPNs also became the representation of choice for local behavioral pattern mining in object-centric data. In Object-Centric Local Process Models, the paper explicitly states that LPMs are labeled Petri nets and OCLPMs are OCPNs. The discovery pipeline first computes place nets per object type, then constructs a simple event log using a process execution oracle, discovers LPMs on that simple log, annotates places with object types, and finally identifies variable arcs using a threshold-based score over the events covered by the local model. This line is implemented in ProM and positions OCPNs not only as end-to-end models but also as pattern formalisms for local structure (Peeva et al., 2024).

4. Soundness, workflow structure, and discovery pathologies

A major research theme concerns when an OCPN should be considered correct. One line introduces object-centric workflow nets by requiring that every object-type projection $F_{var}\subseteq F$2 is a WF-net and that the whole net is weakly connected. For accepting OCPNs, soundness requires correct initial and final markings per object type, option to complete, and no dead transitions. The stated motivation is direct: without soundness, a discovered model may deadlock, leave objects stranded mid-process, or make activities impossible to execute (Benzin et al., 2023).

A related but distinct formal line studies OC WF-nets and OC-soundness for OC-nets with typed places and non-deterministic synchronization. There soundness is defined locally for an object type via a tracking extension: a selected object must always be able to complete properly, even while other objects remain active in the environment. The paper proves that checking OC-soundness for an OC WF-net is decidable (Lomazova et al., 2021).

The most specific soundness pathology studied for modern OCPN discovery arises in collaborative systems with loops. The generic OCPD approach from van der Aalst et al. may merge same-labeled transitions across object types too aggressively. For the object interactions with loops pattern, this can produce a net that deadlocks after the initial transition fires. The paper formalizes the problematic behavior as the pattern $F_{var}\subseteq F$3 and its subpattern $F_{var}\subseteq F$4, introduces the notion of $F_{var}\subseteq F$5-soundness, proves in Theorem 1 that the original OCPD approach is $F_{var}\subseteq F$6-unsound for $F_{var}\subseteq F$7, and presents two repairs: different activity, which temporarily relabels the problematic event, and similar activity, which transforms the discovered OCPN by adding one new place, two silent transitions, and reconnecting arcs. Under Inductive Miner on flattened logs, Theorems 2 and 3 show that both extensions are $F_{var}\subseteq F$8-sound; the same paper also addresses spurious interactions, where merging same-labeled transitions forces unsupported synchronization (Benzin et al., 2023).

Model quality beyond soundness is addressed through precision and fitness. For an event $F_{var}\subseteq F$9, the paper on precision and fitness constructs an event-object graph, defines the object-centric context of $L\in \bag(act^*)$0 as a multiset of prefixes per object type, and then compares enabled log activities with enabled model activities under that context. The resulting measures are

$L\in \bag(act^*)$1

$L\in \bag(act^*)$2

The evaluation reports the familiar pattern that a flower model is highly fit and imprecise, whereas a restrictive model is precise but not fit: the flower model has fitness $L\in \bag(act^*)$3 and precision $L\in \bag(act^*)$4, the restricted model fitness $L\in \bag(act^*)$5 and precision $L\in \bag(act^*)$6, and the appropriate model fitness $L\in \bag(act^*)$7 and precision $L\in \bag(act^*)$8 (Adams et al., 2021).

5. Conformance checking and performance analysis on OCPNs

Conformance checking on OCPNs first appeared through object-centric alignments, which generalize classical alignments from sequences to directed acyclic graphs of moves. A move may be a log move, a model move, or a synchronous move; synchronous moves require exact agreement of activity label and object set. The computation proceeds by building a synchronous product net from a process execution net and a preprocessed de-jure OCPN, then solving a shortest-path problem in the weighted state space, for example with Dijkstra. The qualitative evaluation argues that these alignments provide better insights because they correctly consider inter-object dependencies, while the quantitative evaluation on 755 BPI2017 variants reports runtime from 0.007 seconds to 1051.8 seconds and exponential growth with the number of events, the number of objects, and the alignment cost (Liss et al., 2023).

A more basic conformance question is whether OCPN replay explains the behavior that a log exhibits under the relevant multi-object context. The context-based precision and fitness framework gives one answer, but alignment-based work adds diagnostic detail because it represents deviations as log, model, and synchronous moves over object-centric executions rather than over flattened traces. This suggests a division of labor: precision and fitness assess permissiveness and coverage, while alignments expose concrete deviation structures (Adams et al., 2021, Liss et al., 2023).

OCPNs also serve as the formal basis for object-centric performance analysis. The OPerA approach first discovers an OCPN from an OCEL, then replays the OCEL on the OCPN and derives event occurrences and token visits, from which both classical and object-centric performance measures are computed. The paper defines

$L\in \bag(act^*)$9

$e=(ei,act,time,omap,vmap),$0

$e=(ei,act,time,omap,vmap),$1

together with pooling time and lagging time per object type. The distinctive contribution is that OCPNs make it possible to compute newly introduced object-centric metrics such as synchronization time, pooling time, and lagging time using the exact token visits relevant to the interacting objects (Park et al., 2022).

The case study on a real-life loan application process illustrates why flattening is problematic for performance analysis. In the traditional analysis, activity Send appeared repeated 1,799 times and its average sojourn time was about 2 days and 23 hours, whereas the object-centric computation gave about 15 minutes. Activity Cancel application was reported as repeated 1,891 times with about 12 days and 22 hours in the traditional analysis, while the object-centric computation yielded 1,682 times and about 31 days and 22 hours. The same study reports an average synchronization time of Cancel application of about 4 days and 11 hours, an average lagging time of applications of about 3 days and 15 hours, and an average lagging time of offers of about 19 hours (Park et al., 2022).

6. Limits of standard OCPNs and the emergence of identifier-aware and data-aware extensions

A recurrent limitation of standard discovered OCPNs is that they are expressive about object flow and event co-occurrence but remain underspecified about relationships of specific objects. One paper states this directly: OCPNs are good at replaying object-centric logs, but they are too weak to prescribe or check object relationships, cannot represent synchronization according to intended relationships, and fail to identify violating executions. To address this, the paper defines a mapping from OCPN to an equivalent OPID and then to a synchronizing OPID under explicit stable many-to-one relationships, proving that the original OCPN and the resulting OPID coincide for executions that satisfy the intended relationships and that violating executions are rejected by the synchronizing model (Seidel et al., 18 Aug 2025).

This line connects to Object-Centric Petri Nets with Identifiers (OPIDs), introduced as a formalism combining the ability of OCPNs to capture one-to-many relations with the ability of Petri nets with identifiers to compare and synchronize objects based on their identity. In the motivating order-delivery example, earlier object-centric alignment methods could yield an optimal alignment of cost $e=(ei,act,time,omap,vmap),$2 even when items are shipped with the wrong order, because identity information is not retained strongly enough. OPID-based conformance checking uses an SMT encoding, is implemented in oCoCoMoT with the Yices 2 backend, and on the BPI 2017 setup evaluates 715 variants with traces of 3 to 23 events (average 12) and 2 to 11 objects (average 5); the average runtime is about 200 seconds and the maximum runtime about 7900 seconds (Gianola et al., 2023).

A further strict extension is DOPIDs, or data-aware OPIDs. DOPIDs extend OPIDs with structured data manipulation capabilities and full synchronization mechanisms. The model introduces data-value types, guards, list variables, subset-template inscriptions $e=(ei,act,time,omap,vmap),$3, exact-template inscriptions $e=(ei,act,time,omap,vmap),$4, and a rich constraint language with arithmetic, strings, uninterpreted functions, relations, and aggregation such as $e=(ei,act,time,omap,vmap),$5, $e=(ei,act,time,omap,vmap),$6, $e=(ei,act,time,omap,vmap),$7, and $e=(ei,act,time,omap,vmap),$8. The paper positions DOPIDs as a strict extension of OPIDs and as stronger than standard OCPN-style models because they support structured data and exact synchronization natively, while still admitting SMT-based conformance checking implemented in CoCoMoT using Yices 2 (Gianola et al., 21 May 2025).

Neighboring formalisms illuminate what OCPNs are and are not. Typed Petri nets with identifiers focus on explicit identifier vectors and correctness criteria such as proper type completion, weak type termination, and identifier soundness, showing that object life-cycle correctness can be studied independently of standard workflow soundness (Werf et al., 2022). By contrast, G-nets for web service composition are explicitly described as an object-oriented structuring of Petri nets with service interfaces, methods, and encapsulation, but not as object-centric nets in the OCPN sense, because they do not provide explicit object identity semantics with per-object lifecycle tokens (Chemaa et al., 2013). This distinction addresses a common misconception: in contemporary process mining, “object-centric” refers to multiple interacting object types and their token-level evolution, not merely to modular or object-oriented Petri-net design.