Taking a break from news and commentary on election operations issues, I thought it would be an appropriate time to talk about current TrustTheVote project efforts that are very relevant to the activities of many election officials right now: tabulating election results, as part of the process of certifying results and finishing the operations for the 2 Nov. election. First of all, what is "tabulation"? The word can mean several things in the election context, but we use it to describe the final step of gathering vote data. At the end of election day, there are a number of counting devices that have counted votes on ballots, for example, optical scan counting machines that recorded votes from paper ballots, or DREs that directly recorded votes cast on a computer. Each of these devices has a blob of data that includes what some call "tallies" -- that is, for each ballot candidate or referendum choice, the total number of votes cast for that choice on that counting device. (Confusingly, some vendors call these counting machines "Tabulators" as well.)

"Tabulation" is the process of aggregating all that tally data, checking it for completeness and correctness, andcombining it into a larger tally of all votes cast in the election jurisdiction. In some cases, like a county commissioner contest, that combined tally represents the election results, the total number of votes for each candidate in the contest. In state and Federal contests and questions, the jurisdictional tally is only part of a total, e.g. one county's totals for a state or Federal Senate contest, that is then used by state level officials when they aggregate several count totals to create state-level election results.

With that in mind, the next question is: how is tabulation performed? Well, in the TTV system that we're building, tabulation is done by a dedicated system called (boringly enough) the "Tabulator" that does nothing but tabulation. However, in the proprietary voting systems in use today, there is no Tabulator per se. Tabulation is done as one of many functions of a larger body of software. Here are two examples.

• For some of the older DRE systems, one DRE can serve as an "aggregator" for a group of DREs. Election officials remove magnetic storage media from each DRE, to get the tally data out of the DRE; then one by one they insert the media into the aggregator, which combines all the tally data and writes it out to another storage media. Not a bad idea, aggregation, but not such a good idea for the aggregator to be one function of a device whose main job in life is sensing voters' fingers on a touch screen.

• For more recent voting systems, tabulation is one among many functions of a voting system component that is sometimes called the "election management system" or EMS. One definition of an EMS is: a software system that implements every voting system function that isn't done by a separate voting machine. Tabulation is just one of those functions, along with keeping a database of precincts, districts, splits, polling places, counting devices, candidates, contests, questions, ballot contest order, ballot candidate order, candidate rotations, ballot configurations, actual ballot documents, and of course lots of software and user interface for managing all of this election management data and generating reports from it.

Why is this a bad idea? Tabulation is among the most important functions of a voting system, and if the tabulation software doesn't work right, then the election results can be wrong. Lumping tabulation software in with a bunch of other related software means that errors elsewhere in the lump can effect tabulation; and every time the software in the lump is changed, it could effect the tabulation software even if the tabulation software hasn't changed. And worse, in today's proprietary closed system, it is just not feasible to know whether tabulation software has been effected by any other element of the total system.

And even worse, tabulation is so simple and so important that the software for it should rarely need modification at all! And further still, the larger and more complex you make a lump of software, the greater the odds that a bug somewhere in the lump (and all software has bugs) will effect the correct operation of one or more parts of the lump. In software engineering-speak, large monolithic systems, with code changes accreted over years, are much more likely to fail than a composite system of separate modules, each of which is largely insulated from changes to and errors in other modules.

Introducing the TTV Tabulator: a completely separate, hardened, single-purpose computing device for doing nothing but tabulation, and doing it in a completely transparent way where people can feasibly check on the correct operation of the software. We're at work now on getting the Tabulator ready for outside testing, so the timing of this introduction is doubly timely. In future breaks from other blog streams, I'll be saying more about this deceptively simple computing device, how it works, why it works that way, and how it delivers on the needed transparency and accountability.

-- EJS