## 3 Methodology
### The QUAD Metrics  
We have termed _Fitness_, _Precision_, _Simplicity_ and _Generalisation_ as the QUAD metrics [85]. From the results of our meta-review, we have seen vast usage of the four metrics. They have been used as primary dimensions for evaluating process models. Initial testing revealed them to have a direct impact on the modelling qualities of understandability and complexity. We performed technical analysis and derived mathematical equations for each metric specific to our modelling environment and dataset attributes. We have considered the following notations and terms to explain and describe the formulations of the metrics. Let \(E\) be an event log with \(n\) events and \(M\) be a process model of the same event log. \(T\) is a trace of events. \(C\) is the unique cases of events. Then, the metrics are derived as follows:  
1. _Replay Fitness_: Fitness is a measure that denotes how much of the behaviour present in the event log can be reproduced by the process model. It can be elaborated as the extent to which the model can reproduce the traces recorded in the event log. We have based replay fitness of the work [86]. They have used an alignment-based approach to identify the fitness of process models. This technique aligns as many events as possible from the trace with activities in a single execution of the model. The formulation is as follows: \[Replay\ Fitness=1-\frac{\left|\ T_{E}\ \cap\ T_{M}\right|}{\left|\ C_{E}\right|}\] (1) where, \(T_{E}\) is the traces from the event log, \(T_{M}\) is the traces from the process model, \(\left|T_{E}\cap T_{M}\right|\) is the number of traces, that occur in event log and process model and \(C_{E}\) is the unique cases of events in the event log. In our implementation, the numerator is calculated by aligning every case ID in the event log from start to end and observing if the model can align all of them. In simpler terms, we determine if the process model can replay every single trace as in the event log. The denominator here is the total number of unique case IDs present in the event log. On calculating, we obtain a rating between 0-1, where 1 indicates the process model can fully replay every single trace present in the event log via the generated process model and vice versa. This metric is measured on a scale of 0 to 100%, where 100% indicates the complete alignment of the traces in the event log to that of the model;
2. _Precision_: Precision is a measure used to show how clearly the process behaviour depicted in the event logs can be captured by the model without oversimplifying the model [86]. The metric aims to find out if there exist decisions that are possible in the model but never made in the log. At first glance, it may seem rather odd, as any mining tool by definition would not intentionally add additional behaviour or, rather, what is not given as input cannot be obtained as output. However, we found that it is possible to have behaviour that is not seen in the event log since there is always a possibility of not including every combination of edges and activities within the log. The measure here is inspired by the so-called escaping edges concept [87; 88], where escaping edges are representations of decisions that are not made in the log but exist only in the model. In situations when there are no escaping edges, the model is precise (state = 1). It is formulated as follows:  
\[Precision=1-\frac{\mid T_{E}^{\prime}\ \cap\ T_{M}\mid}{\mid C_{E}\mid} \tag{2}\]  
where \(T_{E}\) represents the traces from the event log, \(T_{M}\) represents the traces from the process model, \(\mid T_{E}^{\prime}\cap T_{M}\mid\) is the number of traces that occur in exclusively in the process model and not the event log and \(C_{E}\) is the unique cases of events in the event log. In our adaption, the numerator is calculated by checking if the process model has additional behaviour which does not exist in the log. Additional behaviour is analysed using individual traces from the event log.