History Repeats Itself, Almost

Well it seems the same programming mistake from September 12, 2006 happened again last night.

The programming mistake from September 12, 2006 and again last night involved polling locations with more than one ward serviced by a single scanner. So for example, the voting for wards A, B, and C are all at the same physical polling location, Johnny’s School, and are serviced by a single optical scanner. Here is an example of ballots for some hypothetical race in the location Johnny’s School for the three wards.

Here is a breakdown of the ballots as marked by voters in wards A, B, and C.

Actual Ballots Cast
Reporting unit	Total Ballots Cast	Ballots with votes for Jefferson	Ballots with votes for Hamilton	Ballots with no vote cast for this race
Ward A	100	74	21	5
Ward B	125	69	44	12
Ward C	150	89	58	3
Johnny's School	375	232	123	20

With the programming error this is how the scanner reported on those ballots when it created its end of day tape report and what the scanner uploaded to the central UNITY server.

What the Election Commission claims the machines reported.
Reporting unit	Total Ballots Cast	Ballots with votes for Jefferson	Ballots with votes for Hamilton	Ballots with no vote cast for this race
Ward A	375	74	21	5
Ward B	375	69	44	12
Ward C	375	89	58	3
Johnny's School	375	232	123	20

But, it should be noted this is what the Milwaukee City election Commission claim is the effect of the programming error.

In September, 2006, the City Election Commission only hand counted the total number of ballots for the affected wards. If the total, aggregate number of ballots matched, they declared the problem solved.

In our example above, that would mean that if the total number of ballots for Wards A, B, and C. Once you find that total numbers of physical ballots are 100, 125, 150 for wards A, B, and C; respectively, you claim the problem affected no individual races.

The problem is this. Once you discover one statistic from the location level (Johnny’s school) has contaminated the reporting for a ward-level statistic (e.g. ballots cast in Ward A), how do you know that no other ward-level statistics has been contaminated as well?

Here is an outrageous example. Assume the machine reported the following statistics on the end of day tape report and then subsequently uploaded those statistics to the central UNITY server.

What the machine could have mistakenly reported
Reporting unit	Total Ballots Cast	Ballots with votes for Jefferson	Ballots with votes for Hamilton	Ballots with no vote cast for this race
Ward A	375	232	21	5
Ward B	375	232	44	12
Ward C	375	232	58	3
Johnny's School	375	232	123	20

If the machine reported the ward level statistics this way, the City’s test from September 2006 would not have caught this error.

That is because the number of physical ballots cast is indeed 100, 125, and 150. In 2006 the City Election Commission never checked any of the candidate-level statistics to see if the machine-reported totals matched the votes actually found on the voter-marked ballots. They assumed the only statistic in error was the total ballots cast. What justified that assumption?

Did the machines mis-report the candidate vote totals in September 12, 2006 or last night?

I don't know about September, because no one botthered to check. But, for last night, the city election commission claims that every ballot line for every race on every ballot cast in every affected precinct were counted and tallied by hand. It is reported every single hand count ballot line agreed with every ballot line on every end of day reports printed last night by the scanners in the affect locations.

This is a substantial improvement over September 2006, because now there is evidence (instead of faith) that the programming error is indeed limited to the single ward-level statitstic.