There is a massive secret process in election vote counting. It’s invisible, so observers won’t help. It’s subject to error and fraud. Existing standards, even Virginia Governor Youngkin’s Executive Order 35 ignores it. It’s not a hard problem to solve. Standard practices in database and data warehousing software that have been proven and refined in decades of use can be applied. The fragmented group of semi-custom voting equipment, largely driven by software-ignorant bureaucrats and regulators ignores this technology, if they’re even aware of it – no one is asking for it, so why bother? The process is simple in principle; it’s just arithmetic. It’s the process of registering each vote as it’s made, accumulating them with strict transaction logging, and gathering the votes recorded by multiple machines in a location, summing and displaying them in real time, and further gathering the votes from multiple locations and doing the same – by County and then by State.
A version of this process takes place today. But no one will tell you exactly how it’s done. What software exactly is used? How do the votes get from a machine to totals for a location? How is the flow done up the line to larger groups: towns, counties and states? Does someone read a display on one machine and type it into another? What’s the machine that does the summing, using what software? What are the formats used for transmission? No one wants to spell it out, keeping the whole thing invisible.
You think this is trivial? Think about the fact that ballots are different in each town to handle local elections and issues. The ballots are designed and entered into the various machines from different makers that are used. When the votes are reported, exactly how is each vote identified – by the name of the person being voted for? Is the name exactly what appears on the ballot, which is always entered locally? When voting for president, is the president’s full first name used? Middle name or initial? Is the vice president named, and if so exactly how? If there is so much as a single character mis-match in the naming, the totals may not be correct, depending on how they’re done, by whom and/or by what software. The problem gets worse when the votes (and names) are passed up the line to a county, which could have scores of separately programmed machines. Apart from naming issues, the right amounts have to be added to the right places – how is this arranged exactly? Not only is this an opportunity for error, it’s a massive opportunity for corruption and fraud.
The real solution to this problem is to eliminate local machines and controls altogether. This may sound impossible, but it’s not. See this for a description of the approach, with links for more detail. But so long as paper ballot counting machines are used, this problem must be solved to assure election integrity. Fortunately, the problem is one that has been addressed and solved in the commercial computer industry. It’s been used for dozens of years in various forms. The fundamental technology is database (DBMS) technology, of the kind that all the major vendors provide and in open-source. It is available in every major cloud platform. A form of DBMS technology called data warehousing has long been used for accumulating the results of transactions in databases for reporting, display and analysis. Moreover, there are long-established technologies for performing the essential operation of ETL (Extract, Transform and Load). ETL first enables a programmer to view the schema (data definitions) of the source and target DBMS and easily define how the data from the source is transferred and transformed as needed to the destination.
The process starts with the information that goes onto each ballot in the state, each county and each jurisdiction. Each one has a list of candidates and questions that need to go on the ballots. The higher entities would define all the entries that are common to each small entity within it; for example, the state would define state-wide ballot entries, counties would add ones for the county, and so forth. While the ballots are designed, the schemas for the DBMS and Data Warehouse would also be defined. The exact names and descriptions that go onto each line of each ballot would be matched with corresponding data element definitions in the databases (for original recording) and data warehouses (for reporting, accumulating, and rolling up), along with ETL. This could all be tested prior to mail-in ballots and early voting. Moreover, everything about it could be made fully public – the ballot definitions, the schema definitions and the ETL. Multiple processes in multiple (for safety) clouds that implement it could be made visible.
There is no reason why the whole thing couldn’t be made public. The data warehouses could update and display publicly their totals with updates as frequently as desired: each second, every five seconds, whatever. The totals could be displayed simultaneously for each voting locations, precinct., town, county and state. Along with display in real time of the voters who arrive to vote and ballots that arrive in the mail for processing, you have a fully transparent system.
Can databases handle this? Amazon’s cloud database handles over 10,000 transactions per second. Multiple copies could be used, with full redundancy. Capacity is not an issue, nor is reliability or security.
This does not fully solve the problem of intense feelings in local officials and the desire to adjust results to suit their preferences. But it goes a long way to getting those people out of the loop and making the essential back-office operations of accumulating the votes counted by the ballot counting machines transparent, until the proprietary machines can finally be eliminated altogether.
Comments