Core concepts

We recommend reviewing the following concepts before working with Foundry's process mining capabilities through the Machinery application.

Process

In a real-world process, entities such as documents, equipment, or individuals transition through states over time. Each Machinery resource depicts such a process. These entities, also called "process objects", must be represented by an object type in your Ontology, such as Claim, Flight, or Employee. That object type must have a String-type property that denotes the object's state. Typically, it will have additional properties and links to relevant object types.

State

A state describes the current condition of an object, such as in progress or delivered for a parcel. The possible states must be enumerable, for instance, a Name property would not be suitable because there are indefinitely many possible names.

Every object must be in one of the possible states at a time. Scenarios where this is not the case should be modeled as a process hierarchy. For example, an employee could have state new-hire or onboarded and also paid or awaiting payment at the same time. These should be separate processes, with a parent process tracking whether the employee is payable.

Within the Ontology, the state is codified as a String-value of the State property. This value is equivalent to the state-id in Machinery. To change the state label shown on the graph, you can overwrite the display name.

Transition

Process objects transition from one state into another. In Machinery, you can define which transitions are expected. This allows you to filter out noise in your data, or focus on the most common paths.

Action

Actions are the cause of transitions. State changes that happen in Foundry are defined by an Action. You can import them to the Machinery graph and qualify their role in the process. For changes that occur externally, this information is often unavailable, but you can annotate action nodes with names and descriptions to provide context. Machinery utilizes the following information about Actions:

• Input States: Allowed states of objects prior to the action. For Foundry Actions, this can be enforced through submission criteria. You can inspect existing submission criteria in the Details panel of actions nodes.
• Output States: Possible resulting states after the action. For instance, an action extract entities can result in extraction succeeded or extraction failed. Output states cannot be enforced, however, they can be manually validated by reviewing the Action logic in Machinery.
• Automations (Foundry Actions): Actions can be automatically executed when certain conditions are met, for instance when process objects enter a certain state. Machinery allows you to easily view and create relevant Automations.

Process Log

The nature of a process is that entities undergo changes over time. To identify patterns in the paths that objects take or metrics like the average time spent in a state, it is essential to capture the time dimension of changes. Machinery does so by maintaining a Process Log object type that tracks every change made to an object, whether from external data sources or Foundry Actions. You can view this object type like any other, but you should not define Actions on it yourself.

For processes happening outside of Foundry, you need to provide a dataset in changelog format that tracks which object went into which state at what time. Machinery computes derivations required for analysis and monitoring, such as the previous state, the duration between those, and the path that an object took until this time.

Interaction modes

The Machinery application has two interaction modes. The View mode lets you inspect all components of the process definition, that is states, transitions, Actions, and Automations. You can move nodes on the graph, however, those positions will not be persisted. This mode also displays the current state of all process objects.

From the application header, you can enter the Edit mode, where you can alter and save to the process definition. By default, Machinery resources open in View mode.

Machinery offers two distinct perspectives of how actions relate to the process.

• State-centric perspective: The graph is focused on the paths that objects can take. Nodes represent states, and the connecting lines describe possible transitions between states. You can inspect the actions that are responsible for these transitions by selecting specific edges. This is the default perspective in the View mode of the application.

  

• Action-centric perspective: The graph explains how actions are impacting the process. Both states and actions are represented as nodes, with different styling. The connecting lines describe the expected input and output states of actions. If no action is configured between two states, the connecting line simply represents a possible state transition. This is the only supported perspective in Edit mode of the Machinery application. In View mode it is available for selection.