Draft result filtering methodology section + expand wamr native call section

chapters/04_methodology/04_02_farm_model.tex

@@ -94,6 +94,7 @@ where \(\mathbf{1}\{o_{c,b} = o\}\) is the indicator function, which equals one
   In terms of \Gls{fail}'s database, this corresponds to summing \code{t.time2 - t.time1 + 1} after joining the trace intervals to their \gls{pilot} results and grouping them by outcome.
   The join accounts for the individual injected bits, so no additional factor for the bit width is required in the sum.
 }
+\todo[inline]{Don't put this in a footnote, put it in controlling what data gets extracted from the experiments}
 
 Weighted outcome totals are reported separately for each fault category, execution mode and injection location (memory, registers or instruction-pointer).
 Outcome shares describe the composition of each variant's fault space, while absolute totals show differences in vulnerability caused by executaion duration and memory footprint.

chapters/04_methodology/04_03_result_filtering.tex

@@ -6,4 +6,10 @@
 
 \section{Result Filtering}\label{sec:resultfiltering}
 
+To analyse specific facets of a system under fault-injection, parts of the observed outcomes and generated measures can be excluded from evaluations.
+Experiments in this thesis aim to characterize program behavior under transient fault conditions regarding its execution mode, so additional overhead caused by, e.g., \Gls{wamr} runtime components is included in the analysis.
+Overhead introduced solely by fault-injection instrumentation is excluded, it is an artifact of the measurement process.
+
+\todo[inline]{Depending on what I do in the evaluations, this needs expansion}
+
 \end{document}