---
title: Object-Centric Petri Nets Overview
url: https://www.emergentmind.com/topics/object-centric-petri-nets-ocpn
type: topic
---

# Object-Centric Petri Nets Overview

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 [2010.02047, 2305.05113, 2204.10662, 2303.16680].

## 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 \(vmap\) is an attribute-value map. A common OCEL definition is \(L=(E,\preceq)\), with \(\preceq\) a partial order consistent with timestamps; related work on conformance uses \(L=(E,O,OT,\pi_{act},\pi_{obj},\pi_{time},\pi_{trace})\), and performance analysis introduces a start/completion-time variant \(e=(ei,act,st,ct,omap)\) [2010.02047, 2303.16680, 2305.05113, 2204.10662].

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 [2010.02047].

Several later techniques retain this object-centric viewpoint rather than reconstructing a single trace. One conformance line defines an object graph \(OG_L=(O,I)\) 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 [2305.05113, 2312.08537].

## 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,
\[
ON=(N,pt,F_{var}), \qquad N=(P,T,F,l),
\]
places are typed by object type, transitions are labeled by activities or \(\tau\), and variable arcs allow a transition to consume or produce a variable number of objects of a given type [2305.05113, 2010.02047].

The semantics differs from ordinary Petri nets because tokens are not anonymous. A possible token is a typed place-object pair
\[
Q_{ON}=\{(p,oi)\in P\times U_{oi}\mid type(oi)=pt(p)\},
\]
and a marking is a multiset over these tokens. Transition firing is defined through a binding \((t,b)\), where \(b\) assigns to each object type around \(t\) the set of object identifiers participating in the firing. Consumed and produced tokens are given by
\[
cons(t,b)=[(p,o)\in Q_{ON}\mid p\in \bullet t \land o\in b(pt(p))],
\]
\[
prod(t,b)=[(p,o)\in Q_{ON}\mid p\in t\bullet \land o\in b(pt(p))],
\]
and firing updates the marking by
\[
M' = M - cons(t,b) + prod(t,b).
\]
For non-variable object types, exactly one object is bound; for variable object types, a set of objects may be bound [2305.05113, 2110.05375].

A central well-formedness condition states that, for a given transition and object type, arcs are either all variable or all non-variable:
\[
tpl_{var}(t)\cap tpl_{nv}(t)=\emptyset \quad \forall t\in T.
\]
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 [2305.05113, 2303.16680].

Many analyses use an accepting OCPN \(OCPN_A=(OCPN,M_{init},M_{final})\) or \(AN=(ON,M_{init},M_{final})\). 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 [2010.02047, 2110.05375].

## 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 [2010.02047, 2303.16680].

A characteristic component of this pipeline is the identification of variable arcs through an activity-type score. For an activity \(act\) and object type \(ot\),
\[
score(act,ot)=\frac{|\{e\in E \mid act(e)=act \wedge |omap(e)(ot)|=1\}|}{|\{e\in E \mid act(e)=act\}|},
\]
and arcs for which the score falls below a threshold \(\tau\) are marked as variable. This gives a discovery-friendly approximation of one-to-many behavior from observed event-object multiplicities [2010.02047].

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 [2010.02047].

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 [2411.10468].

## 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 \(ON_{ot}\) 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 [2303.16680].

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 [2112.14994].

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 \(\varphi_{oiwlp}\) and its subpattern \(\varphi_{oiwlsp}\), introduces the notion of \(PT\)-soundness, proves in Theorem 1 that the original OCPD approach is \(PT\)-unsound for \(PT=\{\varphi_{oiwlsp}\}\), 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 \(\{oiwlsp\}\)-sound; the same paper also addresses **spurious interactions**, where merging same-labeled transitions forces unsupported synchronization [2303.16680].

Model quality beyond soundness is addressed through precision and fitness. For an event \(e\), the paper on precision and fitness constructs an event-object graph, defines the object-centric **context** of \(e\) 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
\[
fitness(L,OCPN_A)=\frac{1}{|E|}\sum_{e\in E}\frac{|en_L(e)\cap en_{OCPN_A}(e)|}{|en_L(e)|},
\]
\[
precision(L,OCPN_A)=\frac{1}{|E_f|}\sum_{e\in E_f}\frac{|en_L(e)\cap en_{OCPN_A}(e)|}{|en_{OCPN_A}(e)|}.
\]
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 \(=1\) and precision \(=0.25\), the restricted model fitness \(=0.31\) and precision \(=0.95\), and the appropriate model fitness \(=1\) and precision \(=0.57\) [2110.05375].

## 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 [2305.05113].

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 [2110.05375, 2305.05113].

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
\[
flow(eo,V)=\pi_{ct}(e)-\min(T),\quad sojourn(eo,V)=\pi_{ct}(e)-\max(T),
\]
\[
wait(eo,V)=\pi_{st}(e)-\max(T),\quad service(eo,V)=\pi_{ct}(e)-\pi_{st}(e),
\]
\[
sync(eo,V)=\max(T)-\min(T),
\]
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 [2204.10662].

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** [2204.10662].

## 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 recent 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 [2508.18231].

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 \(0\) 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** [2312.08537].

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 \(U^{\subseteq}\), exact-template inscriptions \(U^{=}\), and a rich constraint language with arithmetic, strings, uninterpreted functions, relations, and aggregation such as \(sum\), \(min\), \(max\), and \(mean\). 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 [2505.15409].

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 [2212.07363]. 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 [1304.2080]. 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.

Source: https://www.emergentmind.com/topics/object-centric-petri-nets-ocpn