Improving interoperability of election technology with common data formats

Twitter Facebook


Throughout my career in election administration and technology, I’ve wanted election officials to be able to assemble the best election administration solutions based on what works best for them, their jurisdiction, and state. In the current marketplace, this kind of component interoperability—as it’s called—is more difficult to achieve than you might think. To help further this goal, last week I had the opportunity to present to the U.S. Election Assistance Commission (EAC) Technical Guidelines Development Committee (TGDC) about the work we do with National Institute of Standards and Technology (NIST) in voting system interoperability and Common Data Formats (CDFs).

As background, the NIST Voting Program performs technical research to support the development of standards and guidelines for current and future voting systems. The NIST Voting Program’s major efforts are the development of the Voluntary Voting Systems Guidelines (VVSG) through the TGDC (which NIST chairs), and research in the areas of accessibility and human factors, cybersecurity, and interoperability. Separately, NIST accredits Voting System Test Labs (VSTLs) through the National Voluntary Laboratory Accreditation Program (NVLAP).

What are Common Data Formats (CDFs) and why do we need them? This is what NIST has to say on the topic:

The need for a common data format is analogous to the use of a common language for people and economies to share the best of ideas, products, and services. A language used exclusively by a few isolates people from the rest of what the world has to offer. As the demand and use of technology increases in elections, a variety of new products are being used by election officials that must be able to “talk” with each other (i.e., share data) or talk with a common host in order to integrate them into the entire election administration process. Since the "data language" used by these products tends to be proprietary and doesn’t communicate with products from another manufacturer, election officials can be limited to the voting systems product line available through the manufacturer with whom they already have a relationship.

Election officials struggle with integrating combinations of disparate systems such as electronic pollbooks, ballot marking devices (BMDs), blank ballot delivery solutions, and vote tabulation systems—sometimes from different providers—usually leading to many headaches. CDFs are a key part of the solution to this challenge as CDFs offer a common language across components, reducing redundant data entry and enabling componentization.

Now that several CDFs are published and required in the EAC’s latest VVSG 2.0, they need to be implemented into solutions under development and tested before being put to use by election officials. However, testing CDFs is new to the elections community and we need to provide tools to assist this process.

To that end, we’ve worked with NIST to develop a standardized test method for NIST Voting Common Data Formats aimed to assist VSTLs—and election technology providers conducting internal testing before the formal testing—in ensuring conformance to published specifications. This test method is built on standard, open-source validation infrastructure and I urge everyone to look at this new work.

Accompanying the CDF test method are much expanded test data sets. These data sets can help CDF implementers reason about the formats and provide standardized inputs during testing campaigns. Test data is offered for all VVSG 2.0 CDFs, plus ballot definition, and covers a wide variety of use cases, which is shown in the following table.

CDF GEN-01 GEN-02 GEN-03 PRIM-01 PRIM-02 PRIM-03 22 GEN 22 PRIM
Ballot Definition x x x x x x
Cast Vote Records x x x x x x
Election Event Logging x
Election Results Reporting v2 w/Counts x x x x x x x x
Pre-Election Election Results Reporting x x x x x x
Voter Record Interchange

Additionally, two new CDFs have been released this year:

  1. Ballot Definition CDF
  2. microCDF

Together, these CDFs bridge the gap between ballot making and scanning systems, thus opening doors for further innovation.

The Ballot Definition CDF adds comprehensive support for logical ballot definition by building on the sturdy foundation of Election Results Reporting 2.0 CDF. However, its support for physical ballot definition (e.g., how ballots are laid out) is what differentiates it from the others.

The Ballot Definition CDF supports “fill the oval” style ballots by describing where the contest option positions are located on a given ballot. The format also supports BMD-style ballot cards using a symbology neutral format called the Micro Common Data Format.

The microCDF is a lightweight messaging format for limited storage (i.e., think paper). It is not for general use, but crucial for specific scenarios. This micro format is used on interoperable ballots to identify ballot style or to encode selections when using a BMD-style ballot summary card.

Illustration of how an optical mark reader, like a ballot scanner, could read a ballot containing a microCDF
An example of Optical Mark Recognition (OMR) testing protocols

The road to interoperability continues and I look forward to more of this journey as do my colleagues at NIST, the EAC, The Turnout, and the broader election community. We are planning to develop a CDF Lifecycle Policy that provides clarity on how CDFs can evolve within the ecosystem in addition to providing best practices for CDF implementations. Watch this space as we share more on this important work into 2024.

Current page