diff --git a/submission_thesis/appendixes/algorithmic.tex b/submission_thesis/appendixes/algorithmic.tex
index 0231e6e..fb8590f 100644
--- a/submission_thesis/appendixes/algorithmic.tex
+++ b/submission_thesis/appendixes/algorithmic.tex
@@ -51,7 +51,7 @@ This process allows us to modularise and thus simplify FMEA analysis of systems.
 
 \paragraph{FMEA applied to the {\fg}: choosing test~cases.}
 As a {\fg} is a collection of components, the failure~modes
-that we have to consider are the failure modes of its components.
+to consider are the failure modes of its components.
 %, as
 %developed in the function definition $fm : \;\mathcal{G} \rightarrow \mathcal{F}$.
 %The aim here is to build `test cases', 
@@ -83,7 +83,7 @@ environmental conditions to which it may be exposed. In this way, all possible
 failure mode behaviour, due to all the conditions that can be applied for all the test~cases will be examined.
 %
 \paragraph{Symptom Identification.}
-When all test~cases have been analysed, we have a set of FMEA results for the given {\fg}. % applied.
+When all test~cases have been analysed,   a set of FMEA results exists for the given {\fg}. % applied.
 These results can be viewed as symptoms of failure of the {\fg}.
 %
 %This looks at the results of the `test~cases' as failure modes from the perspective not of the components, but of the {\fg}/sub-system. 
@@ -115,12 +115,12 @@ These results can be viewed as symptoms of failure of the {\fg}.
 % We can now create a new component and consider the symptoms as its failure modes.
 Common symptoms of failure of the {\fg} are collected.
 %
-We can now create a new component to represent the {\fg} and consider these aggregated symptoms as its failure modes.
+A new component is created  to represent the {\fg} and the aggregated symptoms considered as its failure modes.
 %
-We call this new component a `{\dc}'.
+This new component is called a `{\dc}'.
 %
 %Note that here, b
-Because the FMMD process is bottom up, we can ensure that all failure modes
+Because the FMMD process is bottom up,  it can be ensured that all failure modes
 from the components in a {\fg} have been considered.
 %\footnote{Software can check that all  failure modes have been included in at least one test case, and modelled individually. For Double
 %Simultaneous fault mode checking, all valid double failure modes can be checked for coverage as well.}.
@@ -154,7 +154,7 @@ form `test~cases'.
 % \item Where simultaneous failures are examined use overlapping contours
 % \item For each region on the diagram, make a test case
  \item Using the `test cases' as scenarios to examine the effects of component failures, %% APPLY FMEA
-we determine the failure~mode behaviour of the {\fg}. 
+ the failure~mode behaviour of the {\fg} is determined. 
 %
 This is a human process, applying FMEA for each test case.
 %
@@ -192,7 +192,7 @@ that will be used in the algorithmic description of FMMD.
 Let the set of all possible components  be $\mathcal{C}$
 and let the set of all possible failure modes be $\mathcal{F}$ and $\mathcal{P}$ the powerset.
 \fmmdgloss
-We can define a function $fm$  which returns the failure modes for a given component (see section~\ref{sec:formal7}):
+The function $fm$ is defined  which returns the failure modes for a given component (see section~\ref{sec:formal7}):
 
 \begin{equation}
 {fm} : \mathcal{C} \rightarrow \mathcal{P}\mathcal{F} .
@@ -201,8 +201,8 @@ We can define a function $fm$  which returns the failure modes for a given compo
 %defined by (where $C$ is a component and $F$ is a set of failure modes):
 %$$  fm ( C ) = F $$
 
-We overload the notation for the function $fm$
-and define it for the set of components within a {\fg} $FG$ (i.e. where $FG \subset \mathcal{C} $) thus:
+The notation for the function $fm$ is overloaded
+and defined for the set of components within a {\fg} $FG$ (i.e. where $FG \subset \mathcal{C} $) thus:
 
 \begin{equation}
 fm : FG \rightarrow \mathcal{F} .
@@ -211,7 +211,7 @@ fm : FG \rightarrow \mathcal{F} .
 
 
 Where $\mathcal{FG}$ is the set of all sets of {\fgs}, and $\mathcal{DC}$ 
-is the set of all derived components, we can define the symptom abstraction process thus:
+is the set of all derived components,  the symptom abstraction process is defined thus:
 $$
 %\derivec : SubSystemComponentFaultModes \rightarrow DerivedComponent 
 \derivec : \mathcal{FG} \rightarrow \mathcal{DC} .
@@ -327,13 +327,15 @@ all components within the given {\fg}.
 \subsection{ Determine Test Cases}
 
 From the failure modes associated with the functional~group,
-we now need to determine test cases.
+test cases must next be determined.
+%we now need to determine test cases.
+%
 The test cases are collections of failure modes.
 These can be formed from single failure modes or failure modes in combination.
 Let $\mathcal{TC}$ be the set of all test cases, $\mathcal{F}$ 
 be the set of all failure modes.
 %(associated with the functional group $FG$).
-We define the function $dtc$ thus:
+The function $dtc$ is defined thus:
 %
 $$ dtc: \mathcal{F} \rightarrow  \mathcal{TC}, $$
 %
@@ -507,7 +509,7 @@ Ideally field data and/or formal physical testing  should be used in addition to
 where possible.
 %
 When all the test cases have been analysed,
-we will have a `result' for each `test case'.
+a `result' will exist for each `test case'.
 %
 Each result will be described from the perspective of %{\wrt}  to 
 the {\fg}, not the members of it i.e. the components. % failure modes.
@@ -519,8 +521,10 @@ the {\fg}, not the members of it i.e. the components. % failure modes.
 %%
 
 %
-Thus we will have a set of 
-results corresponding to our test cases. These share a common index value ($j$ in the algorithm description).
+A set of 
+results corresponding to our test cases is now available. 
+%
+These share a common index value ($j$ in the algorithm description).
 These results are the failure modes of the {\fg}.
 \fmmdgloss
 %Once a functional group has been analysed, it can be re-used in 
@@ -546,7 +550,7 @@ has the same failure symptom.
 Let set $\mathcal{SP}$ be the set of all  symptoms,
 and $\mathcal{R}$ be the set of all test case results.
 %
-We define the function $fcs$ thus:
+The function $fcs$ is defined thus:
 %
 $$fcs:  \mathcal{R} \rightarrow \mathcal{SP} ,$$
 given by
@@ -602,7 +606,7 @@ $$ fcs(R) = SP .$$
 This raises the failure~mode abstraction level, $\abslev$ (see section~\ref{sec:alpha}).
 The failures have now been considered not from the component level, but from the sub-system or
 functional~group level.
-We now have a set $SP$ of the symptoms of failure.
+A set $SP$, the symptoms of failure is obtained.
 %
 \ifthenelse {\boolean{paper}}
 {
@@ -638,7 +642,7 @@ This final stage is the creation of the derived component.
 This derived component may now be used to build
 new {\fgs} at higher levels of fault abstraction.
 Let $DC$ be a derived component with its own set of failure~modes.
-We define the function $cdc$ thus:
+The function $cdc$ is defined thus:
 $$ cdc:  \mathcal{SP} \rightarrow \mathcal{DC} , $$
 %
 given by
@@ -670,19 +674,23 @@ The new component will have a set of failure modes that correspond to the common
 %
 %Algorithm \ref{alg55} 
 %The function $cdc$ is the final stage in the process. 
-We now have a 
-derived~component $DC$, which has its own set of failure~modes. This can now be
+A
+derived~component $DC$, which has its own set of failure~modes has been created. 
+%
+This can now be
 used in with other components (or derived~components) 
 to form functional~groups at higher levels of failure~mode~abstraction.
 %Hierarchies of fault abstraction can be built that can model an entire SYSTEM.
 \paragraph{Enumerating abstraction levels.}
 \label{sec:abstractionlevel}
-As described in section~\ref{sec:alpha} we can assign the attribute  of abstraction level $\abslev$  to
+%
+As described in section~\ref{sec:alpha}   the attribute  of abstraction level $\abslev$ can be assigned to
 components, where $\abslev$ is a natural number, ($\abslev \in \mathbb{N}_0$).
+%
 For a base component, let the abstraction level be zero.
 %
-If we apply the symptom abstraction process $\derivec$,
-the resulting derived~component will have an $\abslev$ value
+The symptom abstraction process is applied giving  a $\derivec$,
+this derived~component will have an $\abslev$ value
 one higher than the highest $\abslev$ value of any of the components
 in the {\fg} used to derive it.
 %
@@ -725,7 +733,8 @@ as is found in practise in real world systems.
 Since the fault modes are determined from the bottom-up, the causes
 for all high level faults naturally form trees.
 %
-That is to say from the bottom-up causes become symptoms, which in the next level become causes as we traverse up the tree.
+That is to say from the bottom-up causes become symptoms, 
+which in the next level become causes as the tree is traversed upwards.
 %
 This is demonstrated in the examples chapter~\ref{sec:chap5} where DAGS are drawn linking failure mode causes and symptoms
 in FMMD analysis hierarchies.