Process Relationships: Making Connected Operations Visible

A Connection Needs More Than Two Identifiers

This article uses process relationships as a working term for domain associations within specific executions. Their assessment includes relationship type, origin, and, where applicable, temporal validity.

A Correct Result Is Connected to the Wrong Sample

In an illustrative laboratory operation, result R-08 contains a correctly transferred measurement value. During assignment, however, sample P-31 was selected even though the corresponding documentation identifies P-13. Both identifiers exist. A check limited to valid identifiers would therefore not detect the error.

The investigation follows the relationship from the result to the sample actually tested and to its source object. The assignment is then corrected in a controlled manner. The original connection, the evidence supporting the correction, and the new reference remain distinguishable.

It must now be determined which reports or decisions have already used the incorrect connection. Correcting the relationship does not automatically assess these consequences. Until individually investigated, they remain identifiable as open or requiring review.

Relationship Quality Is a Distinct Aspect of Data Quality

Relationships require their own quality questions:

• Are both endpoints unambiguously identified?
• Is the relationship type permissible in domain terms and named clearly?
• Does the connection apply permanently or only during a particular period?
• Is its origin in execution, import, a rule, or manual assignment identifiable?
• Can an incorrect relationship be corrected traceably?
• Are expected minimum and maximum numbers of participating objects defined?

Such checks can take place during data capture. They should not, however, block every domain-specific exception. Where an unusual relationship may be permissible, a controlled exception path with a rationale and accountable review is needed.

In addition to the endpoint, the role of the connection must be checked. “Sample tested” and “Sample used as reference” can contain the same identifier but express different statements. The relationship must explain the specific operation.

Relationship Types That Support a Process

This article distinguishes six practical groups of relationships. They are an aid to organization, not a binding standard taxonomy:

• Event to object: An action processes, creates, tests, consumes, or changes a particular object.
• Object to object: A sample comes from a batch, an intermediate product becomes part of a finished product, or a document applies to a particular execution.
• Event to participant: A person or system performs, reviews, confirms, or releases.
• Event to specification: A task is performed under a particular SOP, recipe, or model version.
• State to event: A measured or approved state applies before or after a specific action.
• Event to event: One execution starts, ends, informs, or corrects another execution.

The terms should not merely exist technically but be controlled in domain terms. “Connected to” is usually too unspecific. Statements such as “consumed in,” “sampled from,” “reviewed by,” or “released for” reveal the role an object plays within the operation.

Relationships between processes operate at a different level from relationships between their data objects. Weske describes process interaction through message exchange and dependencies in which one process provides results as input to another.^[5] Applied to the laboratory example: production sends a test request to the laboratory and receives a result. This describes the interaction between the processes. The association “R-08 is the result for P-13” instead identifies the subject of that result. A request can reach the right laboratory while the returned result is still assigned to the wrong sample; correct communication does not establish a correct object reference.

Qualifiers Give Relationships Meaning

OCEL 2.0 distinguishes event-to-object and object-to-object relationships and allows both to be further specified through qualifiers.^[1] This allows the same object to participate in an event in different roles. In a mixing task, a batch can be the target object, several material lots can be inputs, and a container can be connected as a resource used. In batch traceability, for example, it makes a decisive difference whether a material was consumed in a mixture or merely transported alongside it.

Qualifiers are not mere labels. They influence which paths can later be meaningfully analyzed. An analysis can distinguish, for example, whether a material was merely provided, actually consumed, or placed on hold because of a deviation. It can likewise distinguish whether a person performed, cross-checked, or released.

Qualification must fit the data model and be used consistently over time. If the same roles are named differently or different roles are stored under a collective term, the relationship graph loses explanatory value. Controlled vocabularies, unambiguous identifiers, and documented cardinalities help keep meaning consistent.

Separating Temporal Order from Domain Relationships

Time is indispensable for process data, but it does not explain every connection. Two events can directly follow one another yet be independent. Conversely, an important domain relationship can persist over a long period, such as between a production batch and a retention sample collected later.

At least three perspectives must be distinguished for a sound assessment:

1. Temporal order: An event was recorded before, after, or simultaneously with another.
2. Structural connection: Events refer to the same object or to objects explicitly connected to one another.
3. Domain dependency: An action requires a result, creates a follow-up order, or changes an object's permissible state.

A dependency may be interpreted as such only when it follows from a specification, data model, or documented decision. Mere proximity of timestamps is insufficient.

How Standards Structure Relationships

XES and OCEL address different data perspectives. XES standardizes the exchange of classical event data with a case-based structure. OCEL extends the perspective to multiple object types, changing object attributes, and qualified relationships. The IEEE Task Force describes standardized event data as a prerequisite for exchanging data intelligibly between the information systems that generate them and analysis tools.^[3]

W3C PROV serves a different purpose. The domain-independent model describes entities, activities, agents, usage, generation, derivation, and responsibility, among other concepts.^[4] It is therefore suitable as a conceptual foundation for provenance relationships. It does not replace either an operational process model or a process mining standard.

An internal data model can draw on such standards without storing every piece of operational information directly in their exchange format. What matters is that the mapping remains documented: Which internal relationship corresponds to which standardized concept, which information is mandatory, and where do organization-specific extensions exist?

Relationship Quality Supports Cross-Object Analysis

Object-Centric Process Mining investigates intertwined object lifecycles.[2] The connections used must therefore be correct in substance. A larger relationship graph would merely propagate the incorrect reference from R-08 to P-31 into further analyses.

Selecting relevant object types must therefore be combined with a review of their relationships. More edges do not mean greater certainty. An assumed assignment should remain identifiable as such and should not receive the same evidential status as a confirmed reference.

Analyses That Build on Relationships

Explicit relationships expand the questions that can be asked of event data. In addition to the sequence of individual activities, transitions between object types, shared resources, and interdependent lifecycles become visible.

Process Discovery can derive process structures from observed sequences. When relationships are considered, not only activity sequences but also recurring object interactions can be investigated. Further analyses can examine whether expected connections are missing, whether unusually many objects participate in an event, or whether waiting times arise at particular handoffs.

An unusual pattern initially remains an analytical signal. It may result from a recording error, a permissible special execution, or an operational problem. The underlying events and relationships must therefore remain verifiable back to the original execution.

Fahland’s chapter on Event Knowledge Graphs adds an analytical perspective: events can be linked to multiple entities so that their behavior can be examined across several dimensions.^[6] In the example, a measurement event could belong to the history of sample P-13, the instrument used, and the person performing the measurement. These are several perspectives on the same event, not proof of several communicating processes. Process interaction, object association, and event-based analysis therefore need to remain distinguishable, even when they use some of the same data.

Distinguishing Process Relationships from Related Concepts

• Process event: Documents an individual action or observation; a process relationship connects that event to its domain context.
• Process variant: Describes a recurring process path; relationships explain which objects and roles support that path.
• Knowledge graph: Organizes knowledge as a network of entities and relationships; process relationships focus on the context of specific executions.
• Data provenance: Describes the origin and creation of data; process relationships here concern associations within specific executions. Both perspectives can use the same relationships, such as an activity's use of an entity. The distinction lies in the purpose of investigation, not in mutually exclusive relationship types.
• Correlation: Denotes a statistical relationship; a modeled process relationship is initially a domain or structural association.
• Causality: Claims a cause-and-effect relationship and requires stronger evidence than sequence or shared object membership.

What Process Relationships Do Not Provide

• They do not replace a process model. Observed relationships alone do not explain which connections were expected or permissible.
• They do not automatically make data complete. Unrecorded actions and external operations remain invisible even in the relationship model.
• They do not determine relevance. Which connection matters for a review or decision remains a domain question.
• They do not justify unlimited interconnection. Purpose, access, and retention must remain controlled even for linked data.

The Right Edge Connects the Right Operation

In the sample example, both identifiers are valid and the measurement value is correct. The error lies in their association. A complete data review must therefore also examine what the connection asserts and what evidence supports it.

This makes relationship quality concrete: unambiguous endpoints, an appropriate role, traceable origin, and controlled correction. These properties allow a relationship to be checked before further analyses build on it.