diff --git a/doc/src.high-level/high-level-chain-mgr.tex b/doc/src.high-level/high-level-chain-mgr.tex
index 91209fe..4e03759 100644
--- a/doc/src.high-level/high-level-chain-mgr.tex
+++ b/doc/src.high-level/high-level-chain-mgr.tex
@@ -150,12 +150,12 @@ main focus of this document.
 Humming consensus's goal is to manage Chain Replication metadata
 safely.  If participants have differing notions of time, e.g., running
 on extremely fast or extremely slow hardware, then humming consensus
-may "churn" rapidly in different metadata states in such a way that
+may ``churn'' rapidly in different metadata states in such a way that
 the chain's data is effectively unavailable.  
 
 In practice, however, any series of network partition changes that
 case humming consensus to churn will cause other management techniques
-(such as an external "oracle") similar problems.
+(such as an external ``oracle'') similar problems.
 {\bf [Proof by handwaving assertion.]}
 (See also: Section~\ref{sub:time-model})
 
@@ -167,14 +167,14 @@ practice of chain replication metadata management options.
 
 \subsection{``Leveraging Sharding in the Design of Scalable Replication Protocols'' by Abu-Libdeh, van Renesse, and Vigfusson}
 \label{ssec:elastic-replication}
-Multiple chains are arranged in a ring (called a "band" in the paper).
+Multiple chains are arranged in a ring (called a ``band'' in the paper).
 The responsibility for managing the chain at position N is delegated
 to chain N-1.  As long as at least one chain is running, that is
 sufficient to start/bootstrap the next chain, and so on until all
 chains are running.  This technique is called ``Elastic Replication''.
 
 The paper then estimates mean-time-to-failure
-(MTTF) and suggests a "band of bands" topology to handle very large
+(MTTF) and suggests a ``band of bands'' topology to handle very large
 clusters while maintaining an MTTF that is as good or better than
 other management techniques.
 
@@ -212,7 +212,7 @@ Paxos, Raft, et al.), why bother with a slightly different set of
 assumptions and a slightly different protocol?
 
 The answer lies in one of our explicit goals: to have an option of
-running in an "eventually consistent" manner.  We wish to be able to
+running in an ``eventually consistent'' manner.  We wish to be able to
 make progress, i.e., remain available in the CAP sense, even if we are
 partitioned down to a single isolated node.  VR, Paxos, and Raft
 alone are not sufficient to coordinate service availability at such
@@ -250,9 +250,9 @@ timestamps, physical or logical.  Any mention of time inside of data
 structures are for human/historic/diagnostic purposes only.
 
 Having said that, some notion of physical time is suggested for
-purposes of efficiency.  It's recommended that there be some "sleep
-time" between iterations of the algorithm: there is no need to "busy
-wait" by executing the algorithm as quickly as possible.  See also
+purposes of efficiency.  It's recommended that there be some ``sleep
+time'' between iterations of the algorithm: there is no need to ``busy
+wait'' by executing the algorithm as quickly as possible.  See also
 Section~\ref{ssub:when-to-calc}.
 
 \subsection{Failure detector model}
@@ -278,7 +278,7 @@ will always be explictly noted.
 
 \subsection{Use of the ``wedge state''}
 
-A participant in Chain Replication will enter "wedge state", as
+A participant in Chain Replication will enter ``wedge state'', as
 described by the Machi high level design \cite{machi-design} and by CORFU,
 when it receives information that
 a newer projection (i.e., run-time chain state reconfiguration) is
@@ -295,13 +295,13 @@ operation mode.
 
 \subsection{Use of ``humming consensus''}
 
-CS literature uses the word "consensus" in the context of the problem
+CS literature uses the word ``consensus'' in the context of the problem
 description at \cite{wikipedia-consensus}
 .
 This traditional definition differs from what is described here as
 ``humming consensus''.
 
-"Humming consensus" describes
+``Humming consensus'' describes
 consensus that is derived only from data that is visible/known at the current
 time.
 The algorithm will calculate
@@ -478,7 +478,7 @@ Figure~\ref{fig:projection}.  To summarize the major components:
 According to the CORFU research papers, if a server node $S$ or client
 node $C$ believes that epoch $E$ is the latest epoch, then any information
 that $S$ or $C$ receives from any source that an epoch $E+\delta$ (where
-$\delta > 0$) exists will push $S$ into the "wedge" state and $C$ into a mode
+$\delta > 0$) exists will push $S$ into the ``wedge'' state and $C$ into a mode
 of searching for the projection definition for the newest epoch.
 
 In the humming consensus description in
@@ -775,7 +775,7 @@ is used by the flowchart and throughout this section.
 
 \item[E] The epoch number of a projection.
 
-\item[UPI] "Update Propagation Invariant".  The UPI part of the projection
+\item[UPI] ``Update Propagation Invariant''.  The UPI part of the projection
   is the ordered list of chain members where the
   Update Propagation Invariant of the original Chain Replication paper
   \cite{chain-replication} is preserved.