State-Aware Object-Centric Process Mining: Two Synthetic OCEL 2.0 Evaluation Logs

## Overview

This dataset contains two synthetic, paper-scale object-centric event logs created for the
evaluation of FlowVault, a browser-based platform for state-aware object-centric process mining
(SA-OCPM). The scenarios cover:

- inventory management, with stock-policy states along item-location lifecycles; and
- manufacturing and predictive maintenance, with operational states along machine lifecycles.

The logs support evaluation of deterministic state-expression correctness, operational state
validity, state-aware pattern and transition analysis, state-aware object-centric directly-follows
graphs, transition KPIs, and unsupervised execution-state detection. Both logs use the OCEL 2.0
JSON exchange format and contain synthetic data only; they contain no personal or confidential
information.

These are the complete observed logs, including passive inventory observations or machine
telemetry. The derived `observed.behavior.ocel.json` variants present in the source evaluation
bundle are not part of this dataset.

## Dataset contents

| File | Scenario | Original source file |
|---|---|---|
| `inventory-management.ocel.json` | Inventory management | `results/saocpm_15x/inventory-paper/observed.ocel.json` |
| `manufacturing-maintenance.ocel.json` | Manufacturing and predictive maintenance | `results/saocpm_15x/manufacturing-paper/observed.ocel.json` |

The OCEL files were copied without content changes and renamed to make the scenario explicit.
They are compact, single-line UTF-8/ASCII-compatible JSON documents with the standard OCEL 2.0
top-level collections `eventTypes`, `objectTypes`, `events`, and `objects`.

## Log summary

| Property | Inventory management | Manufacturing and maintenance |
|---|---:|---:|
| Events | 46,256 | 43,458 |
| Objects | 18,506 | 3,578 |
| Event types | 24 | 30 |
| Object types | 10 | 11 |
| Event-to-object relationships | 187,191 | 92,581 |
| Object-to-object relationships | 18,551 | 3,554 |
| Leading object type | `ItemLocation` | `Machine` |
| Leading objects | 48 | 8 |
| Configured study period | 2023-01-01 to 2025-01-01 UTC | 2024-01-01 to 2025-03-26 UTC |
| Observed event-time range after jitter | 2022-12-31T23:58:12Z to 2025-01-01T00:02:39Z | 2023-12-31T23:59:24Z to 2025-03-26T00:01:05Z |
| State labels in the evaluation notion | 5 | 8 |
| Expected lifecycle state transitions | 10,833 | 11,196 |

The observed ranges extend slightly beyond the configured study periods because controlled
timestamp jitter is part of the observation-noise profile.

### Inventory-management log

The inventory scenario follows stock, demand, replenishment, receipt, transfer, adjustment,
policy-change, and data-gap behavior. Each event used for state analysis is associated with one
leading `ItemLocation` lifecycle. The ten object types are:

`ItemLocation`, `Material`, `Location`, `Supplier`, `SalesOrderItem`,
`ReplenishmentProposal`, `PurchaseOrderItem`, `Delivery`, `TransferOrder`, and `Planner`.

The 24 declared event types cover initialization and end snapshots; sales-order creation,
reservation, goods issue, backorder, and cancellation; replenishment proposal and approval;
purchase-order creation and change; supplier confirmation, delay, expedition, receipt, and
rejection; transfers; cycle counts and adjustments; policy updates; and data-gap boundaries.

The paper profile spans 731 days and uses 48 item-locations, 24 materials, three locations, six
suppliers, and four planners. Its controlled observation-noise profile uses 1% event-attribute
MCAR masking, 0.5% relationship MCAR masking, and timestamp jitter configured at two minutes.

### Manufacturing and predictive-maintenance log

The manufacturing scenario combines production, telemetry, alarms, quality holds, failures,
maintenance response, repair, inspection, testing, restart, and recovery. Each event used for
state analysis is associated with one leading `Machine` lifecycle. The eleven object types are:

`Machine`, `ProductionOrder`, `Operation`, `WorkOrder`, `Component`, `MaterialLot`, `Alarm`,
`Inspection`, `Operator`, `MaintenanceTeam`, and `Shift`.

The 30 declared event types cover initialization and end snapshots; production release, setup,
and operation; sensor snapshots and alarms; defect and quality-hold handling; automatic stops;
maintenance requests, work orders, dispatch, diagnosis, repair, replacement, calibration, and
inspection; test runs; restart; and maintenance completion.

The paper profile spans 450 days, uses eight machines, and emits scheduled telemetry at a
two-hour cadence. Its controlled observation-noise profile uses 1% telemetry MCAR masking, 0.2%
process-event MCAR deletion, 0.2% relationship MCAR masking, and timestamp jitter configured at
one minute.

## State semantics used in the evaluation

The evaluation deliberately separates several meanings of “state”:

1. **Explicit operational state** is a discrete event label produced by a deterministic
   FlowVault state expression. This is the state used in state-aware patterns, transition KPIs,
   lifecycle views, and state-aware OC-DFGs.
2. **Independent reference state** uses the same domain taxonomy but is computed independently by
   the simulator-side oracle. It is used to test expression correctness without sharing the query
   evaluator's implementation. Reference labels are not included in the observed OCEL files.
3. **Hidden execution regime** describes the mechanism that generated an episode, such as a
   supplier delay or bearing degradation. These simulator-only labels are used to evaluate
   automatic state detection and are not present in the observed logs.
4. **Discovered execution state** is a self-organizing-map (SOM) cell learned from numerical
   lifecycle-window features after PCA projection. A discovered cell is an empirical execution
   abstraction, not one of the explicit CASE-query labels.
5. For manufacturing, **physical truth** (wear, true health, and fault family) and a deliberately
   **noisy operational record** are additional, separately evaluated notions. Neither is included
   as a label in the deposited observed log.

For the explicit and reference notions, the state at an event is the **post-event state**. CASE
branches are evaluated from top to bottom, so the order shown below defines precedence. The
`FOR LEADING OBJECT TYPE` clause defines the lifecycle basis. Only events related to at least one
object of that leading type receive the derived `state` attribute.

The deposited logs contain the observable attributes needed by these expressions but do not
already contain a derived `state`, `reference_state`, hidden-regime label, future outcome,
injected-pattern identifier, or causal-treatment outcome.

### Inventory state expression

```sql
STATE state FOR LEADING OBJECT TYPE 'ItemLocation' AS CASE
  WHEN event.data_complete = false THEN 'Unknown'
  WHEN event.critical_understock = true THEN 'Critical Understock'
  WHEN event.on_hand_after < event.lower_threshold THEN 'Understock'
  WHEN event.on_hand_after > event.upper_threshold THEN 'Overstock'
  ELSE 'Normal'
END
```

The five-state inventory notion is:

- `Unknown`: required stock or threshold data are unavailable;
- `Critical Understock`: confirmed demand inside the decision horizon exceeds usable stock plus
  timely inbound;
- `Understock`: post-event on-hand stock is below the lower policy threshold;
- `Overstock`: post-event on-hand stock is above the upper policy threshold; and
- `Normal`: post-event on-hand stock lies within the policy thresholds.

`Critical Understock` has precedence over ordinary `Understock`. The query reads the observable
`critical_understock` flag for the critical-demand test and the post-event stock and threshold
attributes for the remaining comparisons.

Applying this expression to the full inventory log is expected to assign all 46,256 events:

| State | Events |
|---|---:|
| `Unknown` | 5,986 |
| `Critical Understock` | 26,148 |
| `Understock` | 3,431 |
| `Overstock` | 1,187 |
| `Normal` | 9,504 |

### Manufacturing state expression

```sql
STATE state FOR LEADING OBJECT TYPE 'Machine' AS CASE
  WHEN event.data_complete = false THEN 'Unknown'
  WHEN event.down_active = true OR event.mode = 'DOWN' THEN 'Down'
  WHEN event.quality_hold_active = true THEN 'Quality Hold'
  WHEN event.recovery_active = true THEN 'Recovery'
  WHEN event.mode = 'SETUP' THEN 'Setup'
  WHEN event.degraded_latched = true THEN 'Degraded'
  WHEN event.mode = 'RUNNING' THEN 'Running'
  ELSE 'Idle'
END
```

The eight-state manufacturing notion is:

- `Unknown`: telemetry or required mode data are incomplete;
- `Down`: a failure stop or `DOWN` mode is active;
- `Quality Hold`: a quality hold is active while the machine is not Down;
- `Recovery`: restart validation has started but the stable-run requirement has not yet been met;
- `Setup`: machine mode is `SETUP`;
- `Degraded`: the observed degradation hysteresis is latched;
- `Running`: machine mode is `RUNNING`; and
- `Idle`: the machine is available and not processing.

The `degraded_latched` input is maintained by an observed-data hysteresis state machine. It enters
the degraded condition when health is at or below 0.65, a critical alarm occurs, or
vibration/temperature exceeds its entry threshold for two samples. It exits only when health is
at or above 0.75 and all sensors remain below their exit thresholds for four samples. Recovery
lasts from restart or test-run start until 180 minutes of stable running have elapsed without a
new warning.

Applying this expression to the full manufacturing log is expected to assign all 43,458 events:

| State | Events |
|---|---:|
| `Unknown` | 4,685 |
| `Down` | 1,418 |
| `Quality Hold` | 12 |
| `Recovery` | 841 |
| `Setup` | 875 |
| `Degraded` | 1,455 |
| `Running` | 34,171 |
| `Idle` | 1 |

### Hidden regimes used for automatic-state evaluation

Hidden regimes are ground truth for evaluating whether automatically discovered SOM cells are
stable and interpretable. They are intentionally absent from the OCEL event attributes.

- Inventory regimes: `Nominal Replenishment`, `Stable Low Movement`,
  `Demand Surge Without Inbound`, `Supplier Delay`, `Replenishment In Transit`,
  `Receipt-Driven Excess`, `Forecast or Policy Bias`, `Transfer Recovery`,
  `Count Discrepancy`, and `Data Gap`.
- Manufacturing regimes: `Healthy Steady Run`, `Setup or Changeover`, `High-Load Wear`,
  `Bearing Degradation`, `Thermal Drift`, `Quality Drift`, `Alarm Escalation`,
  `Waiting for Maintenance`, `Active Repair`, `Post-Repair Recovery`, `Failed`, `Idle`, and
  `Data Gap`.

## Using the logs

Any OCEL 2.0-compatible reader can parse the two JSON files. In FlowVault, import a log and apply
the corresponding expression above in the state-query editor. FlowVault adds a derived string
event attribute named `state`; re-exporting the active log produces a self-describing OCEL 2.0
file with `state` declared on its event types.

For state-aware analyses, preserve the leading object type from the expression:

- `ItemLocation` for `inventory-management.ocel.json`;
- `Machine` for `manufacturing-maintenance.ocel.json`.

All timestamps are serialized as ISO 8601 UTC timestamps. Attribute values retain OCEL types
(`string`, `time`, `integer`, `float`, or `boolean`), and both event-to-object and object-to-object
relationships are included.

## References

- OCEL 2.0 specification and formats: <https://www.ocel-standard.org/2.0/>
- Kretzschmann, Berti, and van der Aalst, *State-Aware Object-Centric Process Mining: Enhancing
  OCEL 2.0 with Explicit State Transitions*:
  <https://www.alessandroberti.it/new_papers/2025_Dina_SAOCPM.pdf>
- FlowVault source and evaluation implementation:
  <https://github.com/fit-alessandro-berti/flowvault>