P1622 Project Plan
Achieving the goal of device-to-device interoperability, using a CDF in part as the means, is complicated and requires the involvement and cooperation of many parties. Given this, P1622 has developed a project plan that consists of a series of small, focused standards that are limited in scope to "slices" of election data and that are modeled after typical use cases used in system design. This P1622 strategy for use case standard development involves addressing the “easier” aspects of a CDF that involve the least amount of device-to-device interoperability and that have the highest odds of early success, and then subsequently working towards those aspects that are more difficult but achieve more device-to-device interoperability. Addressing these standards in parallel as opposed to serially allows more flexibility and capability to take advantage of external assistance or collaboration with other interested parties or coalitions, most notably the Pew VIP effort.
There are four levels of use case standards, focusing on the endpoints of the voting system at level one and working towards greater aspects of device interoperability at levels 2, 3, and 4:
- Level One Use Case Standards - Voting System Endpoints
- Level Two Use Case Standards - Blank Ballots, Cast Vote Records, Event Logs
- Level Three Use Case Standards - Ballot Definition Files and Information
- Level Four Use Case Standards - Election Equipment Configuration Data
A separate, on-line glossary is under development in parallel so that terms and usage remain consistent throughout standards development. In terms of development priority, level one use case standards constitute the easier "low hanging fruit" and would come first, followed in general by the other levels.
Each IEEE standard first requires its specific Project Authorization Request (PAR), which identifies aspects of the standard to be developed including the scope and purpose of the standard. For the “umbrella” of P1622 standards envisioned, a series of PARs is being developed, one for each use case standard and named according to a numbering scheme, e.g.,
- P1622-1 Voter Registration Database Export Use Case Standard
- P1622-2 Election Results Reporting Use Case Standard
- P1622-3 Election Auditing Use Case Standard
Ultimately, a final comprehensive standard will be developed to tie the use case standards together. Work is currently underway on several level one use case standards.
(Note: The first P1622 standard, IEEE Std 1622-2011, the IEEE Standard for Electronic Distribution of Blank Ballots for Voting Systems, was named before the above numbering scheme went into effect. The levels of use case standards described in this work plan are based on this analysis.)
P1622 Use Case Strategy
P1622 has adopted a strategy of developing use cases standards for limited scopes of election data and election applications, with the goal being that the sum of use case standards will constitute a comprehensive interoperable CDF for election data and election equipment in general. Each use case involves analysis of the application involved, analysis of the data and the building of a data model, possible modifications to existing EML schemas to better support U.S. election needs, and development of worked examples in XML.
A P1622 use case standard includes the following information:
- Summary information about the election application and data being addressed by the standard,
- The associated stakeholders and system actors,
- A description of the use case(s) involved in the scope,
- A model of the data expressed in UML,
- Identification of requirements for the data elements involved in the application,
- Schemas and worked examples in XML, and
- Other associated issues as applicable.
Level One Use Case Standards - Voting System Endpoints
Level one focuses on inputs into the voting system and exports from the voting system and could be considered as to address the “low hanging fruit,” that is, data that does not necessarily require device interoperability and that is relatively straightforward to place in a CDF. The devices addressed are voter registration databases (VRDB) and election management systems (EMS), both of which generally permit imports/exports in a comma-separated value (CSV) format. Translators could thus be built from CSV to the CDF.
- VRDB Export - Registered voter data from VRDBs is currently exported into EMSs; VRDBs are also sometimes updated via exports from electronic poll books and other devices within the voting system. This use case standard would focus specifically on the data elements and schemas needed for registered voter information and other related information that may be stored, e.g., status information associated with a voter’s ballot.
- Election Results Reporting (AKA state roll-ups) - The EMS currently exports election results data that is reported to central offices and local jurisdictions and generally reported upward within a state (known as a state roll-up). From there, this information can be used nationally and by other organizations to analyze results of contests. This use case standard would focus specifically on data elements and schemas needed for election reporting.
- Election Auditing - An EMS can provide election results data, ballot cast records and audit event logs to facilitate the auditing, analysis and possible forensic investigation of an election. The information would be available through data exports provided in the EMS. Note: Current EMS already provide this audit information through either data exports and/or reports (electronic or printed), but the formats vary from system to system. This use case standard would focus specifically on the data elements and schemas needed for election auditing.
Level Two Use Case Standards - Blank Ballots, Cast Vote Records, Event Logs
Level two addresses data that is more complicated to export in some cases, e.g., event log data or cast vote record data, as well as data that may allow limited device interoperability, e.g., blank ballot information, minus state-specific formatting, that can be used by blank ballot distribution systems (BBDS).
- VRDB and EMS export of information to build electronic blank ballots minus formatting details - An EMS can export data which includes information such as election header, contest list, contest selections, contest ‘vote for’ quantity, and ballot/precinct IDs. This ballot information would not provide the contest order, rotation, layout or formatting information (those items are part of the Level 3 interoperability). With the information in the above list, ballots can be laid out on a display screen, marked electronically, and printed or printed on paper and marked manually.
- EMS and voting device export of event log and other auditing information - It will be beneficial to have a common lexicon for audit log entries through which an analysis of an audit log can be done more efficiently and effectively. This may require invention of new EML schemas..
- EMS export of cast vote records - An EMS can provide election results data (from Level One), ballot cast records and audit event logs to facilitate the auditing, analysis and possible forensic investigation of an election. The information would be available through data exports provided in the EMS.
Level Three Use Case Standards - Ballot Definition Files and Information
Level three focuses specifically on EMS export of information to dynamically build blank ballots with state-specific formatting, known as ballot definition data. This would permit voting devices to accept this information and display ballots according to state requirements. Practically speaking, the state-specific information might be contained in templates or configuration files that may work in tandem with a CDF, but if made part of the CDF specification, this would permit interoperability among EMSs and voting devices. Level three can be broken out into three segments.
The first segment would be the information required for generating an electronic ballot and would also be a portion of the data required for printing a physical paper ballot (note that some of this information is already covered in the level two use case standard for electronic blank ballot distribution). With this information, ballots can be laid out on a display screen and marked electronically or printed and marked manually. In either case, for the cast ballot selections to be entered into the EMS election results, they would have to be manually transferred to an actual scannable ballot (then scanned, tabulated and uploaded), or the selections could be manually entered into the EMS. The information would include:
- election header,
- contest list/order,
- contest selections/rotations,
- contest ‘vote for’ quantity,
- straight party/recall contest associations, and
- ballot/precinct IDs.
The second segment would be the information required for printing a scannable ballot. This information would include the first segment and also the:
- voting target shape/size/color/position,
- timing/control/special marks and their shape/size/color/position, and
- ballot/precinct ID coding and their shape/size/color/position.
The third segment is information that characterizes the appearance of the ballot. This information would include items such as:
- font types/sizes/color,
- background color/watermarks/color striping, and
- instructional text.
Some jurisdictions have state statutes and/or regulations that mandate some if not all of these characteristics. For those jurisdictions, the ballots presented to their voters (and returned to them for counting) would have to include this information, whether it be presented on paper and manually marked or presented on a display and electronically marked.
Level Four Use Case Standards - Election Equipment Configuration Data
Level four involves EMS export of other voting device configuration data (memory card configuration, other device initialization information) to achieve interoperability among voting devices in general. At the base level within the EMS, the machine configuration data that is downloaded to the vote capture devices (e.g., DREs) could be provided to vote capture devices from other voting systems.
This information would provide all the detail required for the machine’s operation, including:
- Memory media ID
- Election header information (title, date, version, poll center ID, copy number)
- Security and verification data (signatures, check counter values, serial numbers)
- Election Data (counter groups, voter groups, base precincts, district categories, languages,
- contests, candidates, rotations, relationships, endorsements, ‘vote for’ number, ballot style
- IDs, voting box type/size/position/justification, sequencing index, report format)
- Rejection criteria for overvotes, undervotes, blank voted contests, and blank voted ballots
- Ballot sorting options
- Cast vote records (data and/or images), tally results
- Modem upload phone number
- Audit logs
- For DRE display interface devices, the information would also include:
- Header/footer sizes, number of columns, scaling factors
- Button type/size/position/justification
- Flags for voting, rendering, text wrapping
- Background colors for page/labels/contests/candidates
- Instructional text, write-ins, audio, and default volumes
Although the downloaded memory devices would be interchangeable between VCDs, only those memory devices created by one EMS for an election would be allowed to upload to that EMS.