diff --git a/certainty.tex b/certainty.tex
index 60808e6..0db24a5 100644
--- a/certainty.tex
+++ b/certainty.tex
@@ -62,18 +62,18 @@ developers to use \texttt{maybe} statements to prototype alternatives to
 existing well-tested code.
 
 A final question concerns when a \texttt{maybe} alternative should be
-assessed. In some cases it may be appropriate for \textit{a posteriori}
+evaluated. In some cases it may be appropriate for \textit{a posteriori}
 evaluation to happen immediately after execution. In others, it may be
-necessary to execute the same alternative over a period of time to perform a
-fair comparison. As described previously, \texttt{evaluate} blocks can
-indicate explicitly whether or not to continue evaluating the alternative,
-and we are determining how to make a similar choice available to
-\texttt{maybe} statements that do not use customized evaluation logic. In
-addition, \texttt{evaluate} blocks can store state across multiple
-alternative executions allowing them to evaluate not only micro- but also
-macro-level decisions. In both cases, however, the \texttt{maybe} system
-allows developers continuous per-statement control over alternative
-evaluation and selection as described in more detail later in this section.
+necessary to continue executing the same alternative over a period of time to
+perform a fair comparison. As described previously, \texttt{evaluate} blocks
+can indicate explicitly whether or not to continue evaluating the
+alternative, and we are determining how to make a similar choice available to
+\texttt{maybe} statements without \texttt{evaluate} blocks. In addition,
+\texttt{evaluate} blocks can store state across multiple alternative
+executions allowing them to evaluate not only micro- but also macro-level
+decisions. In both cases, however, the \texttt{maybe} system allows
+developers continuous per-statement control over alternative choice and
+evaluation as described in more detail later in this section.
 
 \subsection{\texttt{\large maybe} Alternative Testing}
 
@@ -85,42 +85,40 @@ ways for the developer to guide and control any step in the process.
 
 \subsubsection{Runtime control}
 
-To begin, we briefly outline how our Android prototype system implements the
-\texttt{maybe} construct. We (1) rewrite each \texttt{maybe} code block to an
+To begin, we briefly outline how our Android prototype implements the
+\texttt{maybe} statement. We (1) rewrite each \texttt{maybe} code block to an
 \texttt{if-else} statement controlled by a call into the \texttt{maybe}
 system and (2) generate a similar setter for each \texttt{maybe} variable.
 Variable values and code branches are now all under the control of a separate
 \texttt{maybe} service which can be deployed as a separate app or
-incorporated into the Android platform itself. It is responsible for
-communicating with the global \texttt{maybe} server to retrieve adaptation
-parameters for all \texttt{maybe}-enabled apps on the smartphone. When possible, 
-we avoid interprocess communication during each
-\texttt{maybe} decision by caching decisions in the app.  The local
-\texttt{maybe} service pushes cache invalidation messages when that decision
-changes. The
-\texttt{maybe} service tracks when alternatives change, runs both generic and
-app-specific alternative assessment logic when appropriate, and returns
-testing results to the \texttt{maybe} server.
-
-Because unpredictable changes to variables at runtime could cause crashes or
-incorrect program behavior, our \texttt{maybe} prototype currently only
-changes the values of these variables when they are set using a
-\texttt{maybe} statement. If the app wants to enable periodic readaptation of
-certain global variables, such as the interval controlling a timer, it can do
-so by periodically resetting the value using another \texttt{maybe}
-statement. This ensures that \texttt{maybe} variables only change when the
-developer expects them to.
+incorporated into the Android platform. It is responsible for communicating
+with the global \texttt{maybe} server to retrieve adaptation parameters for
+all \texttt{maybe}-enabled apps on the smartphone. When possible, we avoid
+interprocess communication during each \texttt{maybe} decision by caching
+decisions in the app, with the \texttt{maybe} service delivering cache
+invalidation messages when particular decisions change. The \texttt{maybe}
+service tracks when alternative decisions change, runs \texttt{evaluate}
+evaluation logic when appropriate, and returns testing results to the
+\texttt{maybe} server.
+
+Because unpredictable runtime variable changes could cause crashes or
+incorrect behavior, our prototype currently only changes variable values when
+they are set using a \texttt{maybe} statement. If the app wants to enable
+periodic readaptation of certain global variables, such as the interval
+controlling a timer, it can do so by periodically resetting the value using
+another \texttt{maybe} statement. This ensures that \texttt{maybe} variables
+only change when the developer expects them to.
 
 \subsubsection{Simulation or emulation}
 
 Pre-deployment simulation or emulation may provide a way to efficiently
-assess \texttt{maybe} blocks without involving users. Building simulation
+assess \texttt{maybe} statements without involving users. Building simulation
 environments that accurately reflect all of the uncertainties inherent to
 mobile systems programming, however, is difficult. To complicate matters,
 \texttt{maybe} alternatives may depend on details of user interaction that
-are difficult to know a priori, particularly when new apps and app
-functionalities are being investigated. So in most cases we believe that
-post-deployment testing will still be required.
+are difficult to know \textit{a priori}, particularly when new apps or
+functionalities are being investigated. So in most cases we believe
+post-deployment testing will be required.
 
 However, pre-deployment testing may still be a valuable approach, particularly
 when a large amount of uncertainties are present and a correspondingly-large
@@ -147,7 +145,7 @@ which \texttt{maybe} statements should be tested at any given time.
 
 Each time a \texttt{maybe} statement is reached or \texttt{maybe} variable is
 set, the \texttt{maybe} system records:
-
+%
 \begin{itemize}
 
 \item what \texttt{maybe} was reached;
@@ -165,7 +163,7 @@ and platform information; networking provider and conditions; location;
 battery level; and so on.
 
 \end{itemize}
-
+%
 This dataset is periodically uploaded to the \texttt{maybe} server by the
 \texttt{maybe} service and used to drive the adaptation approaches discussed
 next.
diff --git a/discussion.tex b/discussion.tex
index c4ed7ae..df56208 100644
--- a/discussion.tex
+++ b/discussion.tex
@@ -17,7 +17,8 @@ While \texttt{maybe} is a powerful programming tool, it is important that it
 be used sparingly. If objective dependencies exist between \texttt{maybe}
 statements, the overall configuration space may expand exponentially,
 complicating the process of determining the best alternatives described in
-Section~\ref{sec-certainty}. Compile-time analysis may be required to detect
+Section~\ref{sec-certainty}. (A similar problem exists with nested
+\texttt{maybe} statements.) Compile-time analysis may be required to detect
 dependencies between \texttt{maybe} statements and ensure that downstream
 optimization remains feasible.
 
diff --git a/include/start.tex b/include/start.tex
index 3f71968..835059a 100644
--- a/include/start.tex
+++ b/include/start.tex
@@ -27,8 +27,8 @@
 
 \usepackage[all]{hypcap}
 
-\setlist[itemize]{leftmargin=*,partopsep=5pt}
-\setlist[enumerate]{leftmargin=*,partopsep=5pt}
+\setlist[itemize]{leftmargin=*,topsep=2pt,itemsep=-0.5ex,partopsep=1ex,parsep=1ex}
+\setlist[enumerate]{leftmargin=*,topsep=2pt,itemsep=-0.5ex,partopsep=1ex,parsep=1ex}
 
 \paperheight 11in
 \paperwidth 8.5in
diff --git a/introduction.tex b/introduction.tex
index 3ee0f1c..958b016 100644
--- a/introduction.tex
+++ b/introduction.tex
@@ -47,15 +47,15 @@ if (plugged == false && batteryLevel < 10) {
 }
 \end{minted}
 
-\vspace*{-0.1in}
+\vspace*{-0.2in}
 
-\caption{\textbf{Typical Error-Prone Energy Adaptation.} The threshold is
-arbitrary and the attempt to conserve energy succeed only at certain times,
+\caption{\small\textbf{Typical Error-Prone Energy Adaptation.} The threshold is
+arbitrary and the attempt to conserve energy may succeed only at certain times,
 only for certain users, only on certain devices, or never.}
 
 \label{fig-example-if}
 
-\vspace*{-0.1in}
+\vspace*{-0.2in}
 
 \end{figure}
 
@@ -87,7 +87,7 @@ maybe {
 
 \vspace*{-0.1in}
 
-\caption{\textbf{Example \texttt{maybe} Statement.} The programmer provides
+\caption{\small\textbf{Example \texttt{maybe} Statement.} The programmer provides
 multiple equivalent alternatives. The system determines how to choose between
 them at runtime.}
 
diff --git a/maybe.tex b/maybe.tex
index fb2d66f..0cec744 100644
--- a/maybe.tex
+++ b/maybe.tex
@@ -30,13 +30,13 @@ maybe {
 
 \end{minted}
 
-\vspace*{-0.2in}
+\vspace*{-0.1in}
 
-\caption{\textbf{More \texttt{maybe} Statements}}
+\caption{\small\textbf{More \texttt{maybe} Statements}}
 
 \label{fig-maybeexamples}
 
-\vspace*{-0.2in}
+\vspace*{-0.1in}
 
 \end{figure}
 
@@ -67,12 +67,18 @@ statement providing syntactic sugar. \texttt{maybe} function annotations
 allow uncertainty to be expressed at the function level, with the
 alternatives consisting of multiple function definitions with identical
 signatures. Finally, \texttt{maybe} blocks that require custom evaluation
-logic can include an \texttt{evaluate} statement following the main
-\texttt{maybe} block, as shown in the final example. \texttt{evaluate} blocks
-provide app-specific \textit{a posteriori} logic to evaluate the selected
-alternative. The \texttt{evaluate} block must return a single JSON object
-with two components: (1) a positive integer \texttt{score}, with smaller
-being better; (2) and a boolean \texttt{repeat} indicating whether the system
-must use the same alternative next time. Hints and custom evaluation logic
-can also be applied to other types of \texttt{maybe} statements through
-annotations.
+logic can include an \texttt{evaluate} block as shown in the final example.
+\texttt{evaluate} blocks provide app-specific \textit{a posteriori} logic to
+evaluate the selected alternative. The \texttt{evaluate} block must return a
+single JSON object with two components: (1) a positive integer
+\texttt{score}, with smaller being better; (2) and a boolean \texttt{repeat}
+indicating whether the system must use the same alternative next time. Hints
+and custom evaluation logic can also be applied to other types of
+\texttt{maybe} statements through annotations.
+
+While it should be possible to nest \texttt{maybe} statements, it may require
+compiler support to provide guarantees about how \texttt{maybe} decisions are
+maintained across multiple code blocks. As we gain more experience with our
+rewrite-based prototype, described next in Section~\ref{sec-certainty}, we
+will revisit the question of nesting in future compiler-driven \texttt{maybe}
+systems.
diff --git a/paper.tex b/paper.tex
index 9803c4d..b3c01d6 100644
--- a/paper.tex
+++ b/paper.tex
@@ -30,7 +30,7 @@ Jinghao Shi, Guru Prasad Srinivasa, and Lukasz Ziarek}
 
 \date{}
 
-\title{\thetitle\\\vspace*{-0.15in}}
+\title{\thetitle}
 
 \toappear{\fontfamily{ptm}\selectfont\scriptsize
   Permission to make digital or hard