Start Here
Donate

Case 11 — Fraction Magic, 2016

11.1 — Introduction

In May 2016, election integrity investigator Bennie Smith and journalist Bev Harris published a series of findings about GEMS — the Global Election Management System — one of the most widely deployed election tabulation platforms in the United States. What they found was not a bug. It was a feature.

GEMS stores and processes vote counts as floating-point decimal numbers rather than whole integers. A vote for a candidate can be recorded in the GEMS database as 1.0, or 0.7, or 1.3. The system’s source code explicitly converts the data type of vote-count fields from INT (integer — a whole number) to DOUBLE (double-precision floating point — a number that can carry many decimal places). This conversion appears in GEMS version 1.18 and is not present in version 1.17.

Smith and Harris called this discovery “Fraction Magic.” They demonstrated that the fractional architecture could be used to reallocate votes across an entire jurisdiction in seconds — shifting the outcome of a race without leaving an obvious trace in the system’s user interface. They did this not on a test system but on real GEMS election databases obtained from actual jurisdictions.

This piece describes what was found, how it works, what the vendor’s own documentation says about it, and what it means for independent election verification. The evidence is presented as it stands: the code exists, it does what Smith and Harris say it does, and the vendor documented aspects of the feature in its own user manual. Whether Fraction Magic was ever deliberately used to alter an election outcome is a separate question — one that the available evidence does not resolve and that this manual does not claim to answer.

11.2 — Background: GEMS and the Tabulation Layer

A modern election involves three layers of technology. At the voting layer, the voter makes selections — on a touchscreen, by filling in an optical scan ballot, or by some other mechanism. At the counting layer, the voting machine records and tallies those selections, typically onto an internal memory card. At the tabulation layer, a central server aggregates the counts from all the precinct-level machines across a jurisdiction and produces the official results.

GEMS operates at the tabulation layer. It is not a voting machine and it does not count individual ballots. It is the software that takes the numbers from every precinct in a county (or, in some cases, a state) and adds them up.

GEMS was developed by Global Election Systems, a company that was acquired by Diebold Election Systems in 2002. Diebold rebranded as Premier Election Solutions in 2007. In 2009, Premier’s voting systems division was acquired by Election Systems & Software (ES&S), and some product lines were later divested to Dominion Voting Systems. The vendor chain — Global Election Systems → Diebold → Premier → ES&S / Dominion — is relevant because it means the same underlying codebase passed through multiple corporate identities over more than a decade.

At peak deployment, GEMS was used to tabulate approximately 25% of all votes cast in the United States. It was deployed statewide in Alaska, Connecticut, Georgia, Mississippi, New Hampshire, Utah, and Vermont, and at the county level in more than twenty additional states. It was one of the dominant tabulation platforms in American elections for the better part of two decades.

The critical fact about the tabulation layer is that it sits between two things: the precinct-level count and the official result. Upstream of GEMS, each voting machine produces a printed summary — the poll tape — showing the total votes recorded at that machine or precinct. Downstream of GEMS, the official results are published, certified, and used to determine who wins. If GEMS reports the same numbers that the precinct machines counted, the official results are correct. If it doesn’t, they aren’t.

This is the layer that Actual Vote audits. AV volunteers photograph poll tapes at the precinct level — the upstream number — and compare them to the official results — the downstream number. Any manipulation at the tabulation layer would appear as a discrepancy between these two numbers.

11.3 — The Discovery

Bennie Smith’s investigation began in Memphis. In October 2015, he photographed a poll tape at precinct 07701 in Shelby County, Tennessee, and later compared it to the official results. The numbers didn’t match. The poll tape showed 546 votes; the official result for that precinct showed 330. (Bloomberg covered the broader Shelby County findings — describing more than 1,000 votes unaccounted for at the county level — in September 2016.) (This investigation is detailed in the Shelby County 2015 case study elsewhere in this manual.)

The Shelby County discrepancy turned out to be most likely caused by a different GEMS problem — a memory card upload bug, the same class of failure documented in the Butler County 2008 case study. But Smith didn’t stop there. He began examining GEMS at a deeper level, looking at the source code itself.

What he found was a set of database commands that converted vote-count fields from whole numbers to decimals. The relevant code artifacts, taken from GEMS source code, are:

ALTER TABLE SumCandidateCounter
ALTER COLUMN TotalVotes DOUBLE


ALTER TABLE SumRaceCounter
ALTER COLUMN NumberOfUnderVotes DOUBLE

And in the table creation statements:

CREATE TABLE SumCandidateCounter (
  ReportunitId INT,
  VCenterId INT,
  CounterGroupId INT,
  CandVGroupId INT,
  TotalVotes DOUBLE
)


CREATE TABLE SumRaceCounter (
  ReportunitId INT,
  VCenterId INT,
  CounterGroupId INT,
  RaceId INT,
  TimesCounted INT,
  TimesBlankVoted INT,
  TimesOverVoted INT,
  NumberOfUnderVotes DOUBLE
)

The ALTER TABLE statements are particularly significant. They show that GEMS version 1.18 modified existing tables — tables that previously used INT for vote counts — to use DOUBLE instead. This was not the original design. It was a change.

For readers without a database background: INT means integer — a whole number like 1, 2, 150, or 10,432. An integer data type cannot store 1.5 or 0.7. DOUBLE means double-precision floating point — a number that can carry up to 15–17 significant decimal digits. A DOUBLE can store 1.0, but it can also store 0.999999, 1.000001, or 0.732847. When a database field that holds vote counts is defined as DOUBLE, the system can assign fractional values to what should be whole-number quantities. One vote can be counted as less than one vote or more than one vote.

The displayed results would still appear as whole numbers — GEMS’ user interface rounds for display purposes. But the underlying data, in the database, would carry the decimal values. The fractions would be invisible to anyone looking at the GEMS screen.

11.4 — The Vendor’s Own Documentation

The most striking corroboration comes from Diebold’s own user manual. The GEMS 1.18 User’s Guide, Revision 4.0, dated November 1, 2002, describes a race type called “Weighted.”

The guide explains that weighted races “are tallied by weights, assigned from the voter registration system.” It describes a system in which voters carry different weight values for different races, encoded in bar codes from the voter registration system. The guide provides an example: three voters vote on two propositions, each carrying different weight values (e.g., one voter has weight 25 for Proposition A and weight 50 for Proposition B). The results are tallied by multiplying each vote by its weight.

This is a legitimate use case. Some jurisdictions use weighted voting for certain types of propositions or special-district elections.

But the guide contains three statements that carry a different significance when read alongside the source code findings:

First: “results are reported with two decimal places.” This confirms that GEMS was designed to produce and display non-integer vote counts. The system expected fractional results.

Second: “totals are not verified when manually entering the results of weighted races.” The system does not check whether manually entered weighted results are consistent with underlying vote data.

Third: “Since GEMS does not contain weight information, it is not possible to perform verification of manually entered weighted results, so that it is critical that these results entered be verified independently both prior to and following manual entry.”

This last statement is worth reading carefully. The vendor is acknowledging that GEMS cannot verify its own results for weighted races — and that independent verification is “critical.” The vendor knew the system could not self-check in this mode.

The question that the User’s Guide does not address is the one that matters most: whether the DOUBLE data type is confined to the weighted-race feature or applies to all races in the database. The source code analyzed by Smith shows ALTER TABLE and CREATE TABLE commands applied to the summary counter tables — the tables that store aggregated vote totals for all races, not just weighted ones. The architecture does not appear to restrict fractional values to a subset of race types.

11.5 — The Demonstrations

Smith and Harris did not merely describe the vulnerability. They demonstrated it on real databases.

Alaska, 2004

The Alaska Democratic Party had obtained, through a court order, the actual GEMS database used to tabulate the 2004 presidential election in Alaska. Smith used this database — not a simulation, not a test environment, but the database from a real election — to demonstrate what the fractional architecture could do.

Using a utility he built to work within the existing GEMS data structures, Smith reassigned fractional weights across all candidates in the presidential race. The result: Bush and Kerry’s vote totals were switched across the entire state — more than 200,000 votes, hundreds of precincts — in four seconds. The official results were inverted. And the process was invisible to the GEMS user interface; displayed totals still appeared as whole numbers.

Smith did not hack the database. He did not exploit a bug. He used a capability that the database architecture already supported. The DOUBLE data type in the vote-count fields allowed fractional values; Smith’s utility simply assigned them.

Multi-State Replication

Harris, who is not a programmer, subsequently used Smith’s utility on GEMS databases from jurisdictions in Florida, California, and Tennessee. She was able to control election outcomes in each case. The tool did not require programming knowledge to operate.

In one demonstration, Harris showed that the fractional percentages could be set to encode arbitrary values — including letter-number cipher sequences that could serve as a kind of signature. This was presented as evidence of the precision available to anyone using the tool: you could not only control who won, but control the exact margin, down to multiple decimal places.

What the Demonstrations Prove

The demonstrations establish several things. The fractional architecture works on real election databases. It can be operated by a non-programmer. It can change the outcome of a statewide race in seconds. And the changes are not visible through the GEMS user interface.

What the demonstrations do not establish is that this capability was ever used in an actual election for the purpose of altering an outcome. The distinction between “this can be done” and “this was done” is important, and this manual maintains it.

11.6 — Independent Corroboration

The USENIX Paper

In 2007, before Smith’s Fraction Magic findings were published, Thomas P. Ryan and Candice Hoke presented a paper at the USENIX/ACCURATE Electronic Voting Technology Workshop examining the GEMS database architecture. Their analysis was independent of Smith and Harris’s work.

Ryan and Hoke found that GEMS “fails to conform to fundamental database design principles and software industry standards for ensuring accurate data.” The database did not satisfy even the First Normal Form — the most basic, entry-level requirement in database design. They further found that GEMS’ reliance on Microsoft’s JET technology “introduces additional risks to data accuracy and security.”

Their conclusion was not just that GEMS was poorly designed. It was that the federal certification standards themselves “structurally encourage and reward election system vendors for using less exacting database design standards.” The system that was supposed to prevent flawed software from being deployed in elections was instead creating incentives for exactly the kind of architecture that GEMS exhibited.

Despite all of this, GEMS received federal certification under the Voting System 2002 standards.

The Diebold FTP Discovery

In 2003 — years before Fraction Magic — journalist Bev Harris discovered approximately 40,000 GEMS files on an unsecured, publicly accessible Diebold FTP server. The files included election databases, source code, and configuration files. This discovery, later recounted in Harper’s Magazine and elsewhere, demonstrated that GEMS databases were not merely theoretically accessible — they had been left on a public server, downloadable by anyone.

This earlier finding provided the context for the Fraction Magic research. The question was not only whether GEMS could process fractional votes (it could), but whether GEMS databases were accessible to people who might want to modify them (they had been). These are separate vulnerabilities, but they compound each other.

Local Journalism

Following the publication of the Fraction Magic series, the River Cities’ Reader in the Quad Cities investigated whether the weighted voting feature was enabled in their local GEMS installation (Scott County, Iowa). The county auditor’s office did not confirm or deny whether the feature was active. This is a small data point, but it illustrates a larger reality: many local election officials did not know, and may still not know, whether the fractional architecture was enabled in the GEMS installations they relied on.

11.7 — Detection and Forensic Traces

Fraction Magic, by design, does not announce itself. The GEMS user interface displays vote totals as whole numbers. An election official looking at the screen would see 1,542 votes for Candidate A and 1,307 votes for Candidate B — not 1,542.3148 and 1,306.6852. The fractional values exist in the database but are rounded for display. No error message, no warning, no flag.

There is, however, one category of forensic trace: round-off residuals. When votes are divided fractionally and then rounded for display, the rounding produces small discrepancies. The displayed whole numbers may not add up to exactly the right totals. Smith identified patterns in real election data that he interpreted as consistent with fractional allocation — small, systematic discrepancies that would not be expected from ordinary counting.

These patterns are suggestive but not conclusive. Small discrepancies in vote totals can arise from many sources: data entry errors, legitimate rounding in aggregation, software bugs unrelated to Fraction Magic, and simple arithmetic mistakes. The presence of round-off patterns does not prove that Fraction Magic was used. Their absence does not prove it wasn’t. This is a forensic limitation that the manual acknowledges rather than papers over.

The definitive test would be to inspect the GEMS database directly — to examine whether vote-count fields contain non-integer values. If a candidate’s vote total is stored as 1,542.3148 rather than 1,542, that would be direct evidence of fractional allocation. But this requires access to the database file itself, which is typically not available to independent auditors, the press, or the public.

11.8 — Fraction Magic and Actual Vote

Actual Vote operates at the seam between the precinct count and the official result. Volunteers photograph poll tapes — the printed summary produced by the voting machine at the precinct, before any data reaches the central tabulator. These photographs are compared to the official results published after central tabulation. If the numbers match, the tabulation layer is functioning correctly. If they don’t, something happened between the precinct and the official result.

Fraction Magic, if used, would operate during central tabulation — the exact point in the process where AV’s upstream and downstream numbers would diverge. Fractional reallocation of votes in GEMS would change the official results without changing what was printed on the poll tape. The poll tape is printed before the data reaches GEMS. Whatever GEMS does to the numbers afterward, the poll tape records what the precinct machine counted.

This means AV does not need to know about Fraction Magic to detect its consequences. AV does not diagnose mechanisms — it detects discrepancies. If an AV volunteer’s poll tape photograph shows 546 votes for a candidate and the official result says 330, that discrepancy is visible regardless of whether it was caused by Fraction Magic, by the GEMS upload bug, by a data entry error, or by something else entirely.

This is the design philosophy of Actual Vote: don’t try to audit the software; audit the results against independent evidence.

It is worth noting that AV cannot detect manipulation that occurs at the counting layer — inside the voting machine, before the poll tape is printed. If a DRE touchscreen records a voter’s selection incorrectly, or an optical scanner misreads a ballot, the poll tape itself would reflect the error. Fraction Magic does not operate at the counting layer. It operates at the tabulation layer — downstream of the poll tape, within AV’s audit scope.

The Shelby County 2015 investigation, which prompted Smith’s deeper examination of GEMS and ultimately led to the Fraction Magic discovery, is itself a proof of concept for the AV workflow. Smith photographed a poll tape. He compared it to the official result. He found a discrepancy. Everything that followed — the county investigation, the lawsuit, the GEMS source code analysis — was triggered by that single comparison. AV systematizes and scales what Smith did by hand.

Transparency, deterrence, and the architecture problem

Fraction Magic is also, in a sense that goes beyond any individual election, the clearest illustration in this collection of why transparency and deterrence — not accuracy assurance alone — have to sit at the center of the case for Actual Vote. The Fraction Magic architecture is a vulnerability that has been documented to exist in production tabulation software, that has been confirmed by the vendor’s own training materials, and that has never, to anyone’s public knowledge, been shown to have been used to alter an election outcome. In the current state of public evidence, there is no specific election we can point to and say “Fraction Magic was used here.” But that is precisely the point. In a world where broadly distributed, citizen-held, precinct-level tape evidence exists, any actor contemplating the use of Fraction Magic — or of any functional equivalent in a successor tabulation system — must assume that the precinct-level truth has already been photographed before any fractional reallocation could occur, and that a discrepancy between tapes and official results will be visible in a public dataset held outside the tabulation system entirely. The manipulation is not just detectable after the fact; it is detectable in a way that cannot be defeated by tampering with the tabulator, the central database, the audit logs, or the officials conducting the audit. That asymmetry — the attacker has to evade a distributed, redundantly held, citizen-produced record — is what produces the deterrent effect. It is why the transparency case for AV does not depend on catching any specific instance of Fraction Magic being used. It depends on the corpus existing and being known to exist. In the same way, for any election in which an AV corpus does exist and no tape-to-official discrepancy is found, that corpus functions as an affirmative, publicly available rebuttal to any subsequent accusation that Fraction Magic — or any other tabulation-layer attack — changed the result. The evidence is there whether accuracy turns out to have been in question or not; whether fraud occurred or not; whether anyone ever actually deploys the attack architecture or not. That is transparency functioning as an independent value.

11.9 — Current Status: Is GEMS Still in Use?

GEMS appears to have been largely phased out of active deployment. The vendor chain that produced it — Global Election Systems → Diebold → Premier — ended when ES&S acquired Premier’s voting systems division in 2009 and subsequently divested some product lines to Dominion Voting Systems. Both companies have since introduced successor platforms: ES&S markets ElectionWare; Dominion markets Democracy Suite. Jurisdictions that once ran GEMS have generally migrated to these newer systems.

However, “phased out” is not the same as “gone.” No comprehensive public accounting exists of which jurisdictions still run GEMS and which have migrated. Election technology transitions happen county by county, often driven by equipment age and budget cycles rather than by any coordinated sunset process. It is possible that some jurisdictions — particularly smaller ones with tight budgets — continued to run GEMS installations well past the point when the vendor chain dissolved.

More importantly, the question of whether the DOUBLE data type persists in modern tabulation software is unanswered. When Dominion acquired Premier’s assets, it acquired the intellectual property — including the codebase. The DOJ antitrust settlement required ES&S to divest “all versions” of Premier’s hardware, software, and firmware to Dominion; GEMS was Premier’s core tabulation software. Whether the successor systems inherited the fractional vote architecture, remediated it, or redesigned from scratch is not documented in any publicly available source. No independent audit of ElectionWare or Democracy Suite’s database schema has been published that confirms or denies the presence of floating-point vote-count fields. This is a significant gap in public knowledge.

11.10 — What We Know and What We Don’t

The evidence supports the following statements:

The code exists. GEMS source code contains ALTER TABLE commands converting vote-count fields from INT to DOUBLE. This is a verifiable code artifact, not an allegation.

The vendor documented aspects of the feature. The GEMS 1.18 User’s Guide describes weighted races, decimal results, and explicitly states that GEMS cannot verify results in this mode.

The architecture supports fractional vote manipulation. Smith and Harris demonstrated this on real GEMS databases from real elections, across multiple states, in controlled conditions.

The tool requires no programming expertise. Harris, a non-programmer, operated Smith’s utility successfully.

The manipulation is invisible through normal use. The GEMS user interface displays rounded whole numbers. The fractional values exist only in the underlying database.

GEMS was widely deployed. Approximately 25% of US votes during peak deployment, across seven states statewide and twenty or more states at the county level.

The database architecture has independent, confirmed flaws. The Ryan/Hoke USENIX paper, researched independently of Smith and Harris, found that GEMS fails fundamental database design standards and that federal certification standards incentivize these failures. (Ryan and Hoke’s independent confirmation covers the architectural deficiency — GEMS’s failure to meet basic database design standards — not the specific fractional vote-allocation mechanism described by Smith and Harris. The latter has not been independently replicated by security researchers outside BBV.)

The evidence does not support the following claim:

That any specific election was altered using Fraction Magic. The demonstrations prove capability, not deployment. Smith’s forensic patterns are consistent with fractional allocation but are not conclusive proof. The distinction between “this vulnerability exists and works” and “this vulnerability was used to steal an election” is the difference between a documented security finding and an allegation. This manual stays on the documented side of that line.

This epistemological boundary is not a weakness. It is the appropriate posture for a technical manual. The fact that the most widely deployed tabulation software in the United States was architecturally capable of processing votes as fractions — and that the vendor knew its results could not be self-verified in this mode — is significant on its own terms. It is precisely the kind of finding that makes independent verification not merely useful but necessary.

11.11 — Further Reading

Primary investigation

Independent academic analysis

Vendor documentation

News reporting and context

Bennie Smith — additional materials

Cross-references in this collection