diff --git a/chapters/03_background/03_00_background.tex b/chapters/03_background/03_00_background.tex
index e96c78d..72a1ffd 100644
--- a/chapters/03_background/03_00_background.tex
+++ b/chapters/03_background/03_00_background.tex
@@ -6,4 +6,8 @@
 
 \chapter{Background}\label{ch:background}
 
+\begin{enumerate}
+  \item Fault -> Error -> Failure (fault chain terminology). Also SDC/DUE differentiation
+\end{enumerate}
+
 \end{document}
diff --git a/chapters/03_background/03_01_wasm.tex b/chapters/03_background/03_01_wasm.tex
index 3792b85..e75afea 100644
--- a/chapters/03_background/03_01_wasm.tex
+++ b/chapters/03_background/03_01_wasm.tex
@@ -12,7 +12,7 @@ It is developed and maintained by the World Wide Web Consortium (W3C)\iffalse{}\
 While the initial implementations of \Gls{wasm} runtime environments were confined to web browsers\footnote{In 2016, experimental \Gls{wasm} runtimes were implemented in Firefox, Google Chrome and Microsoft Edge: \url[2026-07-01]{https://hacks.mozilla.org/2016/03/a-webassembly-milestone/}}, \Gls{wasm} does not make any web-specific assumptions, so many different standalone runtimes like \textquote{Wasmtime}\footnote{\url[2026-07-01]{https://github.com/bytecodealliance/wasmtime/}} or the \Acrfull{wamr} (see \autoref{sec:wamr}) have emerged since.
 
 Besides instructions or execution behavior, two file formats are defined by the \Gls{wasm} standard: the \Gls{wasm} \textquote{Binary Format} \iffalse{}(see \autoref{lst:wasmexample})\fi for space-efficient representation and fast transmission, and the Lisp-like \Gls{wasm} \textquote{Text Format} for human readability (see \autoref{lst:watexample}).
-Both formats are equivalent, they represent the same underlying content differently for alternate purposes.
+Both formats represent the same underlying content, but serve different purposes.
 
 % \begin{codeblock}[label=lst:wasmexample]{\Gls{wasm} Binary Format}{.wasm}
 %   \inputminted{hex}{\subfix{listings/wat_example.hex}}
@@ -25,23 +25,23 @@ Both formats are equivalent, they represent the same underlying content differen
 % TODO: Info on wat (module, type, func, memory, global, export)
 \autoref{lst:watexample} shows a minimal \Gls{wasm} module in text format.
 The \code{module} declaration groups all definitions of the compilation unit.
-A \code{type} declares the shared function signature, the \code{func} then references this type and provides its implementation.
+A \code{type} declaration defines a shared function signature, the \code{func} references this type and provides an implementation.
 The module uses two pages of \code{memory} and defines the stack pointer as a mutable \code{global}.
-At the end, the \textquote{memory} and \textquote{main} function are exported, so the host environment can invoke the module and access its state.
+At the end, the memory and the \textquote{main} function are exported, so the host environment can invoke the module and access its state.
 Not visible in the above example are \code{import} statements, which allow the \Gls{wasm} program to access functions, variables or memory from the host environment.
 
-In a typical workflow, a program written in a high-level language like C or Rust gets compiled to the \Gls{wasm} binary format using an LLVM-based toolchain, the binary is then executed in a web-based or standalone runtime environment.
+In a typical workflow, a program written in a high-level language like C or Rust is compiled to the \Gls{wasm} binary format using an LLVM-based toolchain, the resulting binary is then executed in a web-based or standalone runtime environment.
 The binaries mainly consist of \textit{values}, \textit{instructions}, \textit{functions} and \textit{memory}, bundled into \textit{modules}. % TODO: This is already visible in the watexample...
-To execute a program, the module is loaded from its binary format representation, \textit{decoded}, \textit{validated}, \textit{instantiated} and lastly, \textit{invoked}.
+To execute a program, the module is loaded from its binary format representation, \textit{decoded}, \textit{validated}, \textit{instantiated} and finally \textit{invoked}.
 
 During runtime, \Gls{wasm} provides memory safety, control flow integrity and independent execution (sandboxing)\footnote{\url[2026-07-01]{https://webassembly.org/docs/security/}}.
-Memory safety is achieved through a bounds-checked linear memory with an inaccessible call stack\footnote{The call stack is not part of \Gls{wasm}'s linear memory but the execution environment: \url[2026-07-01]{https://bytecodealliance.github.io/wamr.dev/blog/the-wamr-memory-model/}}, preventing arbitrary memory accesses and buffer overflows.
+Memory safety is improved through a bounds-checked linear memory with an inaccessible call stack\footnote{The call stack is not part of \Gls{wasm}'s linear memory but the execution environment: \url[2026-07-01]{https://bytecodealliance.github.io/wamr.dev/blog/the-wamr-memory-model/}}, preventing arbitrary memory accesses outside of the program's linear memory.
 The linear memory is a contiguous and growable byte array that is shared between the module and host.
 Control flow integrity stems from structured control flow: branches target verifiable positions and function calls are index-based and verified against the function table\iffalse{}\footnote{\url[2026-07-01]{https://clang.llvm.org/docs/ControlFlowIntegrity.html}}\fi.
 Additionally, the running program cannot observe its (immutable) source code to prevent control flow hijacking.
 Sandboxing is enforced by isolating each module's state: a module can only interact with the outside world through explicitly imported functions and resources provided by its host runtime.
 
-Its safety features, portability, language/hardware independence and well-definedness make \Gls{wasm} an interesting platform even for resource-constrained and security-critical systems.
+Its safety features, portability, language and hardware independence, and well-definedness make \Gls{wasm} an interesting platform even for resource-constrained and security-critical systems.
 
 % \subsection{\Glsdesc*{wasm} Binary Format}\label{ssec:wasmbinaryformat}
 % \subsection{\Glsdesc*{wasm} Text Format}\label{ssec:wasmtextformat}
diff --git a/chapters/03_background/03_02_wamr.tex b/chapters/03_background/03_02_wamr.tex
index e86376a..2b60463 100644
--- a/chapters/03_background/03_02_wamr.tex
+++ b/chapters/03_background/03_02_wamr.tex
@@ -11,19 +11,20 @@
 \Gls{wamr} includes three main components: The runtime libraries required to load and execute \Gls{wasm} modules (the decode, validate, instantiate, invoke process mentioned in \autoref{sec:wasm}) are called \textquote{\Gls{vmcore}}.
 \Gls{vmcore} can be embedded in C/C++ host applications.
 A standalone version of \Gls{vmcore} is provided by the \textquote{\gls{iwasm}} program.
-It acts as the host application and allows running \code{.wasm} files directly from the command-line.
+It acts as the host application and allows running \code{.wasm} files directly from the command line.
 The last component is \textquote{\gls{wamrc}}, a compiler transforming \code{.wasm} to \Gls{aot} compiled native code, necessary when not using one of \Gls{wamr}'s interpreter implementations.
 
 \Gls{wasm} modules can be executed in five different running modes using \Gls{vmcore}\footnote{\url[2026-07-01]{https://bytecodealliance.github.io/wamr.dev/blog/introduction-to-wamr-running-modes/}}:
 \begin{itemize}
   \item \sansbf{\Gls{aot}} mode sacrifices platform-independence for performance and runtime size efficiency. The \Gls{wasm} module is compiled to platform-native code with \Gls{wasm}-specific scaffolding to retain \Gls{wasm}'s security features.
-  \item \sansbf{Classic Interpreter} is \Gls{wamr}'s slow reference implementation of a \Gls{wasm} interpreter, mainly targeted towards debugging purposes.
+  \item \sansbf{Classic Interpreter} is \Gls{wamr}'s slow reference implementation of a \Gls{wasm} interpreter, primarily intended for debugging.
   \item \sansbf{Fast Interpreter} provides a speed boost over the classic interpreter by using a custom internal intermediate representation of \Gls{wasm} opcodes.
   \item \sansbf{LLVM \Gls{jit}} achieves the highest performance (excluding \Gls{aot} mode) by utilizing the LLVM framework for compilation.
-  \item \sansbf{Fast \Gls{jit}} improves startup time over the LLVM \Gls{jit} by utilizing a lighweight compiler instead of LLVM, but trades some runtime performance.
+  \item \sansbf{Fast \Gls{jit}} improves startup time over the LLVM \Gls{jit} by utilizing a lightweight compiler instead of LLVM at the cost of some execution performance.
 \end{itemize}
 In \Gls{aot} mode the \Gls{wasm} module is invoked by jumping into its native code, the interpreted modes follow a traditional opcode fetch, decode, execute loop.
 
-Of those five modes, this thesis is concerned with \Gls{aot} mode and the classic interpreter for analyzability reasons: \Gls{aot} mode is most similar to native execution without the additional \Gls{wasm} layer. The classic interpreter allows a simpler understanding of fault effects than the fast interpreter or \Glspl{jit} as no different code representations are involved.
+Of those five modes, this thesis is concerned with \Gls{aot} mode and the classic interpreter for analyzability reasons: \Gls{aot} mode is most similar to native execution without the additional \Gls{wasm} layer.
+The classic interpreter makes fault effects easier to analyze than the fast interpreter or \Glspl{jit} as no different code representations are involved.
 
 \end{document}
diff --git a/chapters/03_background/03_03_fail.tex b/chapters/03_background/03_03_fail.tex
index 9f0dae4..5a6254d 100644
--- a/chapters/03_background/03_03_fail.tex
+++ b/chapters/03_background/03_03_fail.tex
@@ -8,12 +8,12 @@
 
 \Gls{fail}~\autocite{schirmeierFAILOpenVersatile2015} is an emulation-based vulnerability analysis tool.
 It provides a toolset to perform \gls{fi} experiments to analyze the vulnerability of software to transient hardware faults.
-In contrast to other \gls{fi} tools\todo{give examples}, \Gls{fail} enables deep simulator state access while simultaneously supporting multiple simulator backends, like BOCHS\footnote{\url[2026-07-07]{https://bochs.sourceforge.io/}} or gem5\footnote{\url[2026-07-02]{https://www.gem5.org/}}.
+In contrast to other \gls{fi} tools\todo{give examples}, \Gls{fail} enables deep simulator state access while simultaneously supporting multiple simulator backends, like \Gls{bochs}\footnote{\url[2026-07-07]{https://bochs.sourceforge.io/}} or gem5\footnote{\url[2026-07-02]{https://www.gem5.org/}}.
 
 \Gls{fail} is split into different components: A \textit{campaign} consists of multiple \gls{fi} \textit{experiments}, where each experiment injects a single fault.
 The \textit{campaign controller} distributes those experiments to running \Gls{fail} instances.
 Campaigns can be parallelized by running multiple instances on different systems or cores.
-Each experiment utilizes \Gls{fail}'s \textit{simulator abstraction layer} to control the target backend, to fast-forward the target to the desired state and inject a fault.
+Each experiment utilizes \Gls{fail}'s \textit{simulator abstraction layer} to control the backend, advance execution to the desired state and inject.
 This abstraction layer allows switching out backends to support different target platforms.
 
 To perform a vulnerability analysis, the examined program needs to be instrumented with fences that define the region to trace (see \autoref{lst:tracefencemarkers}).
@@ -21,11 +21,11 @@ To perform a vulnerability analysis, the examined program needs to be instrument
   \inputminted{cpp}{\subfix{listings/tracefence.cpp}}
 \end{codeblock}
 \Gls{fail} then records the instruction pointer changes and memory accesses inside this region during the so-called \textquote{golden run}: a faultless execution of the program that determines which injections should be performed during the campaign.
-Then, the golden run is enriched with the traced region's disassembly to take into account the read and written registers.
+Then, the golden run is enriched with the traced region's disassembly to take into account the register reads and writes.
 The last step before campaign execution is the \textit{prune} step, where the collected data is translated into corresponding experiments.
 Different data points from the trace that result in the same \textquote{fault-similarity class} (as used by Schirmeier~\autocite{schirmeierEfficientFaultInjectionbasedAssessment}) are removed from the campaign.
 Two experiments belong to the same similarity class if the \textit{relevant} parts of their resulting simulator state are identical.
-From the pruned instruction pointer changes, memory accesses, and register accesses \Gls{fail} constructs a number of \textit{pilots}: representatives of the existing fault-similarity classes.
+From the pruned instruction pointer changes, memory accesses, and register accesses, \Gls{fail} constructs a number of \textit{pilots}: representatives of the existing fault-similarity classes.
 Each pilot then corresponds to a single experiment.
 
 \Gls{fail}'s campaigns are event-driven: the user specifies conditions, for example an access to a certain memory region.