# Explainability of Predictive Process Monitoring Results: Can You See My Data Issues?
## 2 Background
### Predictive Process Monitoring
#### 2.1.1 PPM Workflow  
According to the survey results reported in [2], every PPM task follows a workflow that comprises four steps, which are in turn organised along two stages, i.e., an offline and an online stage (cf. Figure 1). Each PPM task starts with an event log that is (pre-)processed offline. By offline (pre-)processing, we mean transforming the historical cases of a business process captured in an event log into a form suitable for training a predictive model. The outcome of this preprocessing is passed to the online stage, in which an incomplete process instance is processed online, i.e., at runtime, and supported by online predictions. The complete PPM workflow is shown in Figure 1.  
1. **PPM offline stage. ** The input in this stage is an event log. Usually, the latter meets process mining requirements, i.e., it is organised in the form of cases. Each case has a  
Figure 1: PPM Workflow. number of mandatory and optional attributes. Preprocessing steps are performed on the event log to transform its cases into a format compatible with the constraints and requirements of the prediction generation process. 1. **Prefix log construction. ** As stated by [2], the input of most PPM approaches relying on ML is a _prefix log_ constructed from the input event log. Note that a predictive model is expected to predict information related to an incomplete process instance (i.e., a partial case). Consequently, the predictive model has to be trained on partial cases of historical process instances captured in the event log. Note that the prefixes generated from an event log may increase to the extent of slowing down the overall prediction process [2]. Therefore, prefixes can be generated by truncating a process instance up to a predefined number of events. As proposed by [13], truncating a process instance can be carried out up to the first k events of its case, or up to k events with a gap step (g) separating each two events, where k and g are user-defined. The latter prefixing approach is called _gap-based prefixing_. **Prefix case, prefix log. ** Consider a case \(<e_{1},(d_{11},\dots,d_{1m}),e_{2},\)\((d_{21},\dots,e_{n},(d_{n1},\dots,d_{nm})>,\) where n \(\in\) N is the number of events and m \(\in\) M is the number of event attributes. A prefix \(P_{k}\) is generated from \(\sigma\), where \(P_{1}=<e_{1}>,\) g is the gap or step size between an event and the following one in \(P_{k}\), \(1\leq k\leq N\), and \(1\leq g\leq N-1\). A prefix log is the set of all prefixes generated from all cases (or a defined set of cases) in the event log during pre-processing. A prefix log may include events with or without their associated data attributes. After obtaining a prefix log from the given event log, the prefixes need to be further preprocessed in order to serve as appropriate inputs for the predictive model. Prefix preprocessing steps include _bucketing_ and _encoding_. Available preprocessing configurations are limited in the literature, as reported by [2,12]. Figure 2 shows an overview of these techniques, which are introduced briefly through our illustration of the bucketing and encoding preprocessing steps. **Bucketing. ** During prefix bucketing, the prefixes are grouped according to certain criteria (e.g., the number of events or the state reached during process execution). Prefixes in the same bucket are treated as a unit in the encoding and training steps of the offline stage. Moreover, in the online stage, these prefixes form a unit when examining an incomplete process instance in order to find its respective bucket, i.e., similar group of instances. Bucketing can be based on the commonly reached state of the grouped prefixes, on applying clustering techniques to group prefixes, on using domain knowledge or prefix length to bucket several prefixes, or simply on grouping all prefixes into one bucket, which is called the _single bucketing_ technique.