Object-centric event logs (OCEL 2.0) for multi-object business processes

Why flat case logs break multi-object processes

A flat log, the classic XES model, assumes every event belongs to exactly one case, so many-to-many processes get distorted the moment you pick a case notion [3][6]. XES (IEEE 1849-2023) is still the right container for single-entity processes such as a support ticket lifecycle [3]. The problem appears in order-to-cash and procure-to-pay, where one sales order spawns several items, items ship in partial deliveries, and one invoice can settle several deliveries.

Flattening onto any one object type produces three well-known failure modes in the object-centric literature [6]:

• Convergence. An event related to many cases is copied into each. Flatten by item, and a single "Create order" for a 12-line order becomes 12 events, which inflates activity frequencies and makes the agent believe orders are created 12 times as often as they are.
• Divergence. Repeated events for different sub-objects look like loops inside one case. Flatten by order, and "Pick item" appears as a self-loop, so a model cannot tell rework from parallel picking of distinct items.
• Deficiency. Events that do not touch the chosen case object vanish. Flatten by order, and a "Change delivery route" event linked only to a delivery is dropped.

For agents, these are not cosmetic issues. A process-aware agent trained on a convergent log learns wrong base rates; one trained on a divergent log learns phantom rework; one trained on a deficient log never sees the steps it is supposed to take. If your target behavior spans objects, for example "release a blocked invoice once all goods receipts for its PO lines are posted", only an object-centric representation keeps the evidence intact.

What OCEL 2.0 captures, element by element

OCEL 2.0 defines a metamodel of events, objects, their types, two kinds of qualified relations, and time-stamped attribute values [1]. Compared with OCEL 1.0, version 2.0 adds object-to-object relations, relation qualifiers and object attributes that change over time [1].

The qualifiers matter more than most buyers expect. "Approve" linked to a purchase order with qualifier "approved" and to a user object with qualifier "approver" lets you separate the acted-on object from the actor, which is the difference between a usable action trace and a bag of IDs.

Time-varying attributes are what make OCEL useful for environment modeling. With them you can reconstruct object state as of any event, which is the same point-in-time discipline described in our guide to point-in-time correct training data.

OCEL vs XES: choosing the format to request

Request OCEL 2.0 when two or more object types interact with many-to-many cardinality; request XES when a single, stable case notion covers the behavior you need [1][3].

The last row drives most decisions. An OCEL log can be flattened into one XES view per object type for legacy tools, while a delivered XES log cannot be lifted back to object-centric form without the original system tables. When in doubt, ask for the richer representation.

Of the three exchange formats, the SQLite serialization is usually the practical choice for large logs: it keeps events, objects, E2O and O2O relations in separate tables with per-type attribute tables, and it can be queried with plain SQL during acceptance testing [1]. JSON and XML suit smaller logs and tool interchange.

Where object-centric logs come from in enterprise systems

ERP document flows map naturally onto OCEL object types, because ERPs already store business documents with explicit header-item structure and predecessor-successor links. In SAP ECC or S/4HANA, typical sources include sales headers and items (VBAK, VBAP), delivery headers and items (LIKP, LIPS), billing documents (VBRK, VBRP), the sales document flow (VBFA), purchasing (EKKO, EKPO), purchase order history (EKBE), supplier invoices (RBKP, RSEG), and change documents (CDHDR, CDPOS). Oracle, Microsoft Dynamics and NetSuite expose equivalent header, line and link tables under different names.

The extraction logic is where quality is won or lost:

• Events usually come from document creation timestamps plus change documents. A status field without its change history gives you only the final state.
• E2O relations come from foreign keys on the document (PO number on a goods receipt line) and from document-flow tables.
• O2O relations come from header-item keys and reference fields, such as invoice line to PO line.
• Attribute changes require change logs or audit tables; see field-level audit trails for what those contain and where they are incomplete.

Public benchmarks show the gap between flat and object-centric views. The BPI Challenge 2019 purchase-to-pay log, from a multinational coatings and paints company, was published as a case-based log and later re-modeled as a multi-entity event graph [5]. Simulated OCEL 2.0 logs for order-to-cash and procure-to-pay are available on Zenodo and are useful for building pipelines before real data arrives [4]. Real operational logs add what simulations lack: exceptions, manual workarounds, partial deliveries and the long tail of document types. For the commercial records behind these flows, see procure-to-pay and order-to-cash records.

Supplier questions and acceptance checks before committing to OCEL delivery

Before you commit to OCEL delivery, confirm which object types and relations the supplier can actually extract, because many source systems lose object links or attribute history. A supplier who can export only a status snapshot cannot produce a faithful object-centric log, whatever the file format.

Illustrative example: invented to show structure; it does not describe an available dataset.

OCEL request and acceptance checklist

1. Object types. List the object types you need (for example: sales_order, order_item, delivery, invoice, payment, customer, user) and ask which exist as distinct records in the source.
2. Relations. For each pair, ask whether the link is a stored key, a document-flow record or an inferred match. Inferred links (fuzzy amount matching of payments to invoices) should be flagged with a qualifier.
3. Event sources. Ask whether events come from creation timestamps, change documents or workflow logs, and what time zone and precision timestamps carry.
4. Attribute history. Confirm which attributes have change history and which are end-state only.
5. Coverage window. Ask how objects that started before or finished after the extract window are handled, so truncated lifecycles are marked rather than silently included.
6. Format and schema. Request OCEL 2.0 SQLite or JSON that validates against the published schemas at ocel-standard.org [2], plus a data dictionary for custom event and object attributes.
7. Referential integrity tests. Every E2O and O2O row should reference an existing event and object; objects that appear in no event should be listed and explained; no event timestamp should precede its object's creation.
8. Flattening sanity check. Flatten per object type and compare event counts to source document counts to catch duplication.

An abbreviated record set for one partial delivery might look like this (a full OCEL 2.0 JSON file also declares eventTypes and objectTypes with their attributes):

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "events": [{"id": "e-104", "type": "Post goods issue", "time": "2025-03-04T09:12:00Z",
              "relationships": [{"objectId": "dlv-77", "qualifier": "issued"},
                                {"objectId": "itm-3", "qualifier": "shipped item"},
                                {"objectId": "usr-9", "qualifier": "executed by"}]}],
  "objects": [{"id": "itm-3", "type": "order_item",
               "attributes": [{"name": "open_qty", "time": "2025-03-04T09:12:00Z", "value": 4}],
               "relationships": [{"objectId": "so-12", "qualifier": "part of"}]}]
}

Privacy and rights in multi-object logs

Object-centric logs can raise re-identification risk because linked objects combine timestamps, resources and attributes into more distinctive trajectories. Research on flat process mining logs already shows that individual uniqueness in event sequences enables re-identification [7], and an OCEL log connecting customers, users, addresses and payments widens that surface. Treat customer, vendor and user objects as personal data candidates, and expect suppliers to remove or replace names, emails, phone numbers and account numbers while keeping stable pseudonymous object IDs so relations survive.

Rights review matters as much as format. ERP data often includes counterparties' information and is subject to customer contracts, so confirm that the supplying company has authority to license it for model training. If a log will be used to train agents that act inside an employer's workflows, compare the terms discussed in agent deployment logs and training rights.

How SourceX handles object-centric process data requests

SourceX sources operational datasets from US companies on request and manages the licensing process; it does not hold OCEL logs in stock, and a request does not guarantee a match. Buyers describe the object types, relations and history they need; SourceX looks for US businesses that hold that data, and every release is approved by the supplying company. Each dataset is rights-reviewed for ownership and consents, personal details are removed or replaced before delivery with the method recorded and a sample checked, and delivery happens only after an executed agreement through private, access-controlled workflows. You can describe your object-centric data requirement to SourceX, and see the broader agent training data hub and workflow task histories for adjacent sources.

Request object-centric event logs for your agents

SourceX sources operational datasets, including engineering, finance and sales workflow records, from US companies and manages licensing for AI teams wherever they are based. Every dataset is rights-reviewed and delivered under a license that defines records, uses, term and delivery. Start a buyer request at sourcex.si/buyers.