commit 15f85fffc2a1e7064b07e2c650f1d3f16f000ae4
Author: Chris Jerdonek <chris.jerdonek@gmail.com>
Date:   Wed Dec 13 14:33:37 2017 -0800

    Add Ballot Layout Analyzer component.

diff --git a/_source/recommendations.md b/_source/recommendations.md
index b40f3d4..930718c 100644
--- a/_source/recommendations.md
+++ b/_source/recommendations.md
@@ -66,12 +66,13 @@ and deploying an open source voting system.
 
 The Committee suggests the following as components to start work on and
 deliver first (see the “Voting System” section for brief descriptions of
-these components):
+most of these components):
 
 1. Results Reporter (Software)
 2. Vote Totaler (Software)
 3. Ballot Picture Interpreter (Software)
 4. Central Ballot Scanner (Hardware & Software)
+5. Ballot Layout Analyzer (Software)
 
 Choosing the above as first components seems to mirror the approach that Los
 Angeles County is taking in its VSAP project. In particular, Los Angeles
@@ -389,6 +390,40 @@ proto-typing and testing. Samples of ballots from past elections and/or the
 interim voting system.
 
 
+##### 4.2.3.5. Ballot Layout Analyzer (Hardware & Software)
+
+**Complexity:** Medium
+
+**Description.** This is a software component to let one "reverse engineer"
+structured ballot layout data from existing paper ballots from another vendor.
+This component may be needed during a possible interim phase in which
+open-source components are used for scanning and interpreting ballots that are
+generated by a different vendor (i.e. the City's vendor during the time
+when the open-source system is being developed).  This component will be
+needed if that vendor is not able to provide structured ballot layout data
+along with the paper ballots.  It is likely that this component will
+not be completely automated, but rather will be semi-automated.
+
+**Interfaces / data formats.** Needs to accept as input:
+
+* the “election definition” data (e.g. contests, candidates, districts, etc.).
+
+* the digital ballot pictures.
+
+Needs to output for each ballot type:
+
+* the “ballot layout” data (e.g. where contests are located on each ballot
+card for each ballot type, etc.) that will be used as input to the Ballot
+Picture Interpreter component.
+
+**Other outcomes / deliverables.** The required input and output data and
+formats should be spelled out.
+
+**Possible dependencies / pre-requisites.** Real data from past elections for
+proto-typing and testing. Samples of ballots from past elections and/or the
+interim voting system.
+
+
 #### 4.2.4. Deployment Strategies
 
 The components listed above can be deployed and used in conjunction with a