Ballot Reconciliation Procedure

From: Alan Dechert <alan_at_openvotingconsortium_dot_org>
Date: Wed Nov 26 2003 - 21:04:07 CST

About 3 years ago, I came up with a procedure that deals with how to ensure
that the physical paper ballots have one and only one matching electronic
record. It is a key part of the whole idea. I have described it in various
places and various times. I didn't think it needed to be part of this demo
project but since questions keep coming up over and over about how this is
done, I want to include it now. The demo WILL include a demonstration of
the ballot reconciliation procedure. Now that we will be taking a little
more time to get the demo ready, it should not be difficult to include this
piece of the puzzle.

This is not, of course, proposed as "all we need in terms of ballot
security" but it is an important part of how we ensure one person one vote
and one matching xml file for tabulation (previous descriptions of this
procedure may have referred to records or rows in a table... now we're
talking about an XML file for each ballot instead).

The voting machines will be booted from a CD that contains the OS, voting
machine software, and ballot data. When the polls close, the ballot images
are written to the CD during the voting machine shut down procedure. Each
ballot image will be one XML file named like


(minor detail: electiondate is not the date the ballot was cast, but the
date of the election. Even if the ballot is cast some days before, it would
have the election date not the current date)

Each physical paper ballot is deposited in the ballot box witnessed by the
voter and a pollworker while not exposing the printing on the ballot (the
bar code may be showing, of course). The ballot is to be slid out of the
privacy folder face down into the ballot box -- pollworker verifies there is
one and only one ballot. Voter signs out on the roster.

After the polls close, the ballot box is opened. The number of ballots is
counted. The number of signatures on the roster is counted. These numbers
must match (a procedure is developed to deal with scenarios where they don't
match -- they will match so long as people follow the procedures).

The barcode on each ballot is scanned and an XML ballot image is created
with the same format and file naming scheme as on the voting machine. These
files are recorded on a PC set up for administrative purposes. This PC has
(among others) 3 folders (directories) on disk (empty to start with) named
like so:




The XML files from the scanning process go into the BarCodeData directory.
The CDs from the voting machines are collected and their ballot image XML
files are copied to the VotingMachineData directory.

Things to notice:

1) There will always be more XML files in the VotingMachineData directory
than in the BarCodeData directory

2) The files in the BarCodeData directory do not contain write-in candidate
names; the XML files in the VotingMachineData directory will contain all the
same data as the corresponding files in the BarCodeData directory but will
include any write-in candidate names.

Once the XML ballot image files are copied to the appropriate directories, a
procedure is run that does the following:

For each file in the BarCodeData directory, a file with the same name in the
VotingMachineData directory is found. The vote data is verified to be the
same (except that write-in candidate names will not be in the files in the
BarCodeData directory). If the matching file is found and the contents
verified, the VotingMachineData file is copied to the result directory. If
the file is not found or the contents don't match, then we have a problem.
There must always be a matching file found or there has been an error (a
procedure must be developed to deal with possible errors). If no errors,
the Result directory will contain XML ballot images which have been verified
to match with the physical ballots one-to-one.

A report would be generated that would list the unmatched XML files from the
VotingMachineData directory. As best as possible, the unmatched XML ballot
images would be accounted for.

For example, let's say 501 physical paper ballots are in the ballot box and
531 XML ballot image files in the VotingmachineData directory. The
reconciliation procedure verifies that there are also 501 signatures on the
roster. The report on unmatched ballots will show 30 ballot numbers from
the VotingMachineData directory that do not correspond to any paper ballots
that were in the ballot box.

The list of 30 unmatched ballot numbers would be checked off against several
possible sources for these printouts.

1) Test ballots printed on each machine after boot up to verify they are
operating correctly (these copies would be saved in a folder along with
other precinct documents).

2) Numbers from destroyed ballots. Voters are instructed to go to a
pollworker in case they want to re-do the ballot. The pollworker clips a
corner from the ballot, shreds the rest of the ballot and places the number
in a box.

3) Printer jams. If a printer jams, no attempt is made to remove the
printout until after the polls close. There must be spare printer(s)
available to simply remove the printer with the jam or close that particular
voting booth. Any ballots in jammed printers would be removed and the
ballot number recorded if possible.

4) Ballots found laying around.

If all 30 unmatched ballot numbers can be account for, that's great. If
not, the ones not matched are noted. This could be useful information if a
voter turns up later with a ballot saying that they took it home by mistake.
It may or may not be allowed at that time, but it could be verified that,

1) It is an authentic ballot produced on one of the voting machines
2) It has a matching ballot image file previously unaccounted for
3) The number of ballots in the box may also match the signatures where
before it didn't (ask the voter, did you sign the roster? If s/he says yes
and there were 501 signatures but only 500 paper ballots then that might
resolve that discrepancy).

The software program to copy over the matching files and verify the data is
very simple. I want to have that for the demo. Some graphics and possibly
animation would be nice. Any takers?

-- Alan Dechert 916-791-0456
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Sun Nov 30 23:17:10 2003

This archive was generated by hypermail 2.1.8 : Sun Nov 30 2003 - 23:17:13 CST