United States Election Assistance Comittee

Register to Vote!

Use the National Mail Voter Registration Form to register to vote, update your registration information with a new name or address, or register with a political party.

Note: If you wish to vote absentee and are a uniformed service member or family member or a citizen living outside the U.S., contact the Federal Voting Assistance Program to register to vote.

EAC Newsletters
and Updates

Sign up to receive information about EAC activities including public meetings, webcasts, reports and grants.

Give Us Your Feedback

Share your feedback on EAC policy proposalsElection Resource Library materials, and OpenEAC activities. Give feedback on general issues, including the Web site, through our Contact Us page.

Military and Overseas Voters

EAC has several projects under way to assist states in serving military and overseas citizens who register and vote absentee under the Uniformed and Overseas Citizens Absentee Voting Act. Learn more

Chapter 7: Requirements by Voting Activity

7.1 Election Programming

Election programming is the process by which central election officials use election databases and manufacturer system software to logically define the voter choices associated with the contents of the ballots.

There are significant variations among the election laws of the 50 states with respect to permissible ballot contents, voting options, and the associated ballot counting logic.

 

4 Comments

Comment by Harry VanSickle (State Election Official)

We have a positive impression of the requirements in this chapter. The requirements for election programming and ballot preparation are fairly inclusive. It appears that these standards will guarantee that local election officials have more control over the formatting and definition of ballots.

Comment by E Smith/P Terwilliger (Manufacturer)

7.1-C. Why is this a requirement? Small jurisdictions may only have a single election district? Perhaps this should be a voting variation? 7.1-D.2. "All systems" is not defined. 7.1-D.3. How is this requirement, for "all systems", different than the cross-party endorsement voting variation? 7.1-D.3. "all systems" is not defined. 7.1-E. "Exactly" is untestable. 7.1-F. "Exactly" is untestable. 7.1-G. "Verify" and "correct" are untestable. How is this different from "exactlY" in 7.1-E and 7.1-F? Is this less stringent than being "exact"? 7.1-H. "The system" is not defined. 7.2-A.1. "political subdivision" is not defined. How does it differ from "election district", "ballot style" and "reporting context"? 7.2-A.4. "perceives" is untestable. 7.2-A.4. To apply this requirement to each contest is inappropriate and probably in conflict with State election laws; the ordering and presentation of contests is usually fixed. 7.2-A.5. Why is this single requirement specifying "central election officials"? Why not the rest? 7.2-A.8. How is a "ballot configuration" different from a "ballot style"? 7.2-D. "precent" and "unauthorized" are untestable. 7.2.1. This section mystifies. 7.3.1-A. "all systems" is not defined. 7.3.1-A. "properly", "correct", "verify" and "segregate" are not testable. 7.3.1-C. Why is this restricted to 'central election officials"? 7.3.1-D. How does the "programmed device" ensure that the notification (ie error indication) it generates actually notifies an "election official"? The best any programmed device can do is provide a clear indication of its status, not who is viewing such. 7.3.1-E. How does the "programmed device" ensure that the notification (ie error indication) it generates actually notifies an "election official"? The best any programmed device can do is provide a clear indication of its status, not who is viewing such. 7.3.1-F. "Programmed tabulators" is undefined. Is there such a thing as an unprogrammed tabulator? 7.3.1-F. Shouldn't this requirement be specific to paper-based tabulators? 7.3.1-I. As the discussion indicates, this requirement is borderline silly. (The discussion crosses that border.) Suggest restricting it to EBMs. 7.3.1-J. This contradicts 7.3.1-A(d). Segregated test data introduces changes beyond "status changes". 7.3.1-J.1. This contradicts 7.3.1-A(d). Is test data to be isolated (which preserves it for post election audit) or expunged (so that no record of the test is retained)? 7.3.1-J.1. Why is this specific to the undefined "programmed tabulator" when the parent requirement applies to no device type? 7.4-A. This should be applied to vote capture devices and tabulators, not programmed devices. 7.4-B. This should be applied to vote capture devices and tabulators, not programmed devices. 7.4-C. How is a tabulator different from the undefined "ballot counting device". 7.4-D. How is a tabulator different from the undefined "ballot counting device". 7.4-E. How is a function determined to be "designated"? How is this tested? 7.4-E.1. What is a "data code"? A "recognition capability"? Why are locks/keys not permitted? 7.5.1. The intro implies that "issuance of voting credentials" and "ballot activation" are used in different ways elsewhere. Why would this be? This section also provides a duplicate definition for "voting credentials" which is inappropriate. Further, the definition given here for "voting credentials" differs from Appendix A. The definition here includes options such as a magnified ballot. Such options potentially violate the voter's privacy in the same way that specifying the voter's preferred language would. 7.5.1. What is "fair game for OEVT"? 7.5.1.1-B. "MAY" appears to change to "SHALL" in the discussion. 7.5.1.2-A.1. Needs to be changed to "SHALL". 7.5.1.2-A.2. Since 7.5.1 suggests that an ePollbook is a form of activation device, this requirement cannot be met. Also, the voter does not use the voting system, but a vote-capture device. 7.5.1.2-A.3. "SSN" is not defined. 7.5.1.3-A. This requirement is too limiting. For example, a DRE can place a "voted" indication along with other information (such as the DRE serial number and timestamp) to allow the pollworker to determine if a vote was successfully cast (versus perhaps a voter claiming the token doesn't work and trying obtain a replacement after actually voting sucessfully). 7.5.1.3-A.1. This section is moot; unless the vendor is required to build a custom device, the capacity of devices such as smart cards is constrained by market forces. COTS tokens with "several bytes or less" capacity do not exist. 7.5.1.3-A.2. The state information proposed in the discussion violates 7.5.1.3-A. 7.5.1.3-A.3. Even as a "SHOULD", this is an unrealistic suggestion, and is incompatible with the suggestion in 7.5.1.3-A.2 of rewriting the token's state during a voting session. 7.5.1.4-A.2. "so authorized" is undefined and untestable. 7.5.1.4-B. "free of vulnerabilities" is untestable. 7.5.2-A. "ballot presented to the voter" is a new term. "link to" is not defined. "advertising or commercial logos" is not defined. 7.5.3-A. This would seem to be redundant and should be deleted. 7.5.3-A.7. The discussion, which permits declaring two aliases (why not three or more?) to be the same, implies a manual process. Such manual process makes a voting system not part of the write-in class. 7.5.3-A.9. This is inconsistent with state laws governing rotation. It applies an Ivory-Tower view to a process that is per state laws deterministic and decidedly non-equal. 7.5.3-A.16. Please detail how this requirement is not equivalent to "manual intervention", which disqualifies a voting system from claiming support of the provisional voting class. 7.5.3-A.17. "Categorize" is untestable. 7.5.3-A.18. "Flagged" and "separated" are not defined and are untestable. 7.5.4-A. "precisely" is vague and untestable. 7.5.4-A.1. "consistent" is vague and untestable. "Feedback" is not defined. 7.5.4-B. The definition for verify in parens here needs to be moved to Appendix A. "correct is vague and untestable. 7.5.4-B. Why is this only a requirement for DRE? Why not all tabulators? 7.5.4-C. "All systems" is not defined. 7.5.4-C.1. "Make it possible" is a new and undefined term. "All systems" is undefined. 7.5.4-C.2. "Systems" is undefined. "Secure receptacles" is undefined. 7.5.4-D. Why is this specific to DRE? "Prevent" is vague and untestable. "After" needs definition: At some point post-election, ALL vote data is destroyed. 7.5.5-A. How is a "ballot image", as used in other sections, different from a CVR? "retain" is untestable - for what period does this apply? "machine-countable" is undefined. 7.5.6-A. If the counter is defined as 32 bits, it is absurd to claim this is not adequate, as such a counter is an order of magnitude beyond the population of the entire US. 7.5.6-A versus 7.5.6-A.1. How does "notify the user or operator" contrast with ""emit appropriate warnings"? 7.5.6-A. "user" is not a defined voting system role. "operator" is not a defined voting system role. 7.5.7. "Early voting" is not mentioned elsewhere in the VVSG. "suspended state" is not explained. 7.6. Many subsections use the "programmed vote capture device" term, which either is redundant with "vote capture device" or needs a definition in Appendix A. 7.6-A. Why is this requirement limited to DRE? How can ANY vote capture device prevent such access (ie if power is removed)? THe best ANY such device can do is provide indications that access has occurred. 7.6-B. What is a "designated function"? 7.6-B.2. Why is this only a DRE requirement? PCOS and BMDs must also have the capability to close polls an prevent further ballot marking/casting. 7.6-B.3. Why is this not also a requirement for opening polls? What is "normal"? 7.6-B.4. What does it mean for a "poll closing sequence" to have been "activated"? This phrasing is confusing with respect to "ballot activation". 7.6-B.4 and 7.6-B.5. How is "activating" polls closing differ from "completing" polls closing? 7.6-C. What is a "designated function"? 7.7. This entire section is very problematic as it makes unwarranted assumptions about the boundary between a vote capture device, whether DRE or PCOS or even central count, and a tabulator. There is no reason that a vote capture device must also tabulate at any level; this distinction needs to be made clear here and in Appendix A. 7.7.1-B. Not also a paper based vote capture device such as PCOS? 7.7.2-A.1. ALthough this section is aligned with HAVA in allowing overvotes, other sections of the VVSG conflict. 7.7.2-A.9. How is "gathering and recording" a tabulator function and not a vote capture device one? 7.7.2-A.17. There is only ever one round of voting. Ranked order voting can have multiple rounds of tabulation/resolution of ballots. 7.7.2.5. Why not require the documentation to describe the approach, as in 7.7.2.3? 7.7.3-A. Section (c) introduces an "election official designee". This appears to be prohibited by earlier discussions of security, roles, etc. Please define this designee and why it is special to this section. 7.7.3-A.1. "this action" is not defined. If it is referring to 7.7.3-A, then the requirement is redundant. 7.7.3-C. There is no way for the machine to know that an actual election official is receiving any alert. 7.7.3-C. This presumes that ALL ballots being tabulated are from the EBM. If the EBM is only being used for handicap access, this special behavior would constitute discrimination. 7.7.4-A. "the operator" is not a defined role. 7.7.5-A. "ignore" is not the same as "not record as votes". 7.7.5-D. "as dark as can practically be made" is untestable. 7.7.5-F. The discussion refers to 2006 technology. Since multiple requirements in the VVSG render ALL existing voting technology obsolete, why is this important in this single section? The requirement must be changed to SHALL. 7.7.5-G. The discussion refers to 2006 technology. Since multiple requirements in the VVSG render ALL existing voting technology obsolete, why is this important in this single section? The requirement must be changed to SHALL. 7.7.6-A. What is a "Precinct EMS"? The requirement sounds more fit for a tabulator; there is no such thing as a "precinct EMS" assuming the definition of EMS in Appendix A, where the EMS defines the ballot. 7.7.6-A.1. Why is this only a DRE requirement? ANY vote-capture device should be subject to this requirement. 7.7.7 This section needs not be in a VVSG. 7.8.1-C. The discussion relaxes the requirement. Why not change the requirement to include the caveat in the discussion? 7.8.2-A. "All systems" is not defined. Suggest "programmable devices". 7.8.2-B. How is "obtain" different from "generate" or "produce"? 7.8.2-B.b. "voting patterns" is undefined. 7.8.2-B.c. "multiple districting" is undefined. 7.8.2-B.d. "peculiar" is undefined. 7.8.2-C. Does this include programmed devices that are only used as a peripheral to a vote-capture device (VVPAT, for instance)? Suggest "voting devices". 7.8.2-C. How is "obtain" different from "generate" or "produce"? 7.8.2-E.d. What is an "active contest choice register"? Is there such a thing as an "inactive contest choice register"? How would one be at "all storage locations"? 7.8.2-F.d. What is an "active contest choice register"? Is there such a thing as an "inactive contest choice register"? How would one be at "all storage locations"? 7.8.2-G. "systems" is undefined. 7.8.3.1-A. "devices" is undefined. 7.8.3.1-A.b. What is an "election, office or issue label"? 7.8.3.1-B. "systems" is undefined. 7.8.3.1-C. "systems" is undefined. 7.8.3.1-D. "completely consistent" is untestable. 7.8.3.1-D.1 and 7.8.3.1-D.2. It is contradictory and rather bizarre to include requirements that only apply if the voting system does not meet a higher-level requirement. 7.8.3.1-D.1. "the system" is undefined. "flagged" is undefined. 7.8.3.1-D.1. The last sentence of the discussion is irrelevant. 7.8.3.1-F. "official close of polls" is outside the scope of the voting system. If a properly authorized official closes polls, there is no way for the device or voting system to know if polls are "officially" closed. Recall perhaps the emergency extension of polling hours in Florida in November 2004. Even if each device had an accurate clock and was programmed with the "official" close time, that time changed when it was too late to update any device. 7.8.3.2. Subsections are using "systems", not "voting systems". 7.8.3.2. Some subsections call for reports in each reporting context, others do not. 7.8.3.3. Subsections are using "systems", not "voting systems". 7.8.3.3. Some subsections call for reports in each reporting context, others do not. 7.8.4. How is a report deemed "official" or "unofficial"? 7.8.4. "Current best practices" is not explained or referenced.

Comment by E Smith/P Terwilliger (Manufacturer)

7.1. The requirements listed here, 7.1-A through 7.1-H use an incomprehensible hodgepodge of: "SHALL provide for" "SHALL be capable of" "SHALL enable" "SHALL allow" "SHALL support" Are these identical terms? If not, please provide exact definitions and highlight the differences. (Note that later sections exhibit the same inconsistent hodgepodge.)

Comment by m. edmund howse (Academic)

Any voting system that does not maintain the highest degree possible of voting results count and recount integrity cannot be considered one of a democracy. Any state that does not conform to a standard of the highest integrity should not be allowed to participate in a democratic election as they are actually a communist or dictator state and any election results which are counted in this manner are either tainted or pre-established and consequently meaningless as well as not the will of the people.
7.1-A EMS, ballot definition

The EMS SHALL provide for the logical definition of the ballot, including the definition of the number of allowable votes for each contest.

Applies To: EMS

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.3.2.a

 

1 Comment

Comment by Verified Voting Foundation (Advocacy Group)

Part 1, Section 6.6 notes that "Common formats for specifying election programming data such as ballot definition files promotes greater accuracy and reduces duplication" as well as reducing barriers to interoperability. Yet the section that deals specifically with ballot definition (7.1), does not mention the need for a common ballot definition language. Requiring EML (which is a dialect and extension of XML) for ballot definition could go a long way toward improving ballot design in the United States, where poor ballot design has been the source of a number of notorious voting problems (e.g., the "butterfly ballot" in 2000). One of the primary strengths of XML is for formatting documents and text. In the case of ballots, a single underlying XML document could be used to specify and generate paper ballots, sample ballots, touch-screen displays, etc. simply by using different XML Style Sheets. Because there are a large number of software programs that can render XML using style sheets, and because there are many people familiar with using different variants of XML, election officials would have a much broader base of people and resources to help with ballot preparation. And having a single underlying standard for ballot components would facilitate adoption of best practices for ballot design, definition, and implementation.
7.1-A.1 EMS, ballot definition details

The EMS SHALL be capable of collecting and maintaining

  1. Offices and their associated labels and instructions;
  2. Candidate names and their associated labels; and
  3. Ballot questions and their associated text.

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.3.1.1.1.b

 

1 Comment

Comment by Carl Hage (General Public)

The EMS must be able to maintain all names-- offices, jurisdictions, subdivisions, candidates, etc. in the correctly spelled, capitalized, and punctuated full legal form without abbreviations. When any data field requires a limitation in length or conversion to capital lettering, the EMS must produce a mapping table giving the correct name for each alteration. The EMS must not have any reasonable limit on name length. The EMS must be able to maintain a set of equivalent names, e.g. aliases, former names, or set of optional words in a name, e.g. in the name, "Loma Prieta Joint Union Elementary School District", the words "Joint", "Union", and "Elementary" are optional when matching the name. Note: Converting or comparing election information across systems is currently very difficult because names cannot be matched by computer-- mainly due to abbreviations, sometimes due to truncations. This inhibits the ability for independent organizations to validate electronic election data.
7.1-B EMS, political and administrative subdivisions

The EMS SHALL provide for the logical definition of political and administrative subdivisions, where the list of contest choices or contests varies between precincts.

Applies To: EMS

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.2.6.a and I.2.3.2.b

 
7.1-C EMS, election districts

The EMS SHALL enable central election officials to define multiple election districts.

Applies To: EMS

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.2.6.a

 
7.1-D EMS, voting variations

The EMS SHALL enable central election officials to define and identify contests, contest choices, candidates, and ballot questions using all voting variations indicated in the implementation statement.

Applies To: EMS

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.2.6.b, I.2.2.8.2, I.2.3.2.d

 
7.1-D.1 EMS, 1-of-M

In all systems, the EMS SHALL allow the definition of contests where the voter is allowed to choose at most one contest choice from a list of contest choices.

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Implicit in [VSS2002]

 

1 Comment

Comment by Premier Election Solutions (Manufacturer)

This is just a special case of the N of M variation which is already defined in 7.1-D.9. Proposed Change: Remove this requirement.
7.1-D.2 EMS, yes/no question

In all systems, the EMS SHALL allow the definition of contests where the voter is allowed to vote yes or no on a question.

Test Reference: Part 3: 5.2 "Functional Testing"

Source: New requirement / clarification of [VSS2002] intent

 
7.1-D.3 EMS, indicate party affiliations and endorsements

In all systems, the EMS SHALL allow the definition of political parties and the indication of the affiliation and/or endorsements of each contest choice.

Test Reference:Part 3: 5.2 "Functional Testing"

Source: Implicit in [VSS2002]

 
7.1-D.4 EMS, primary elections, party-specific and non-party-specific contests

EMSs of the primary elections device class SHALL support the definition of both party-specific and non-party-specific contests.

Applies To: EMS Λ Primary elections device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.2 and glossary

 
7.1-D.5 EMS, write-ins

EMSs of the Write-ins device class SHALL support the definition of contests that include ballot positions for write-in opportunities.

Applies To: EMS Λ Write-ins device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.4.3.1.d

 
7.1-D.6 EMS, straight party voting

EMSs of the Straight party voting device class SHALL be capable of defining the necessary straight party contest and associated metadata to support the gathering and recording of votes for the slate of contest choices endorsed by a given political party.

Applies To: EMS Λ Straight party voting device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.2 and glossary

 

3 Comments

Comment by Carolyn Coggins (Voting System Test Laboratory)

The use of "contest choice" is incorrect because it includes Y/N questions and non-partisan contests. Parties endorse positions on questions.

Comment by Carolyn Coggins (Voting System Test Laboratory)

Is the VVSG dictating a specific design for Straight Party to be handled as a contest? This is inconsistent with some current voting systems

Comment by Carolyn Coggins (Voting System Test Laboratory)

"Associate Metadata" is broad. Either define it or delete it.
7.1-D.7 EMS, cross-party endorsement

EMSs of the Cross-party endorsement device class SHALL be capable of defining the necessary straight party contest and associated metadata to support the gathering and recording of votes for the slate of contest choices endorsed by a given political party when a given contest choice is endorsed by two or more different political parties.

Applies To: EMS Λ Cross-party endorsement device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Clarification or extension of existing requirements

 

1 Comment

Comment by Carolyn Coggins (Voting System Test Laboratory)

Is the VVSG dictating that straight party voting must be supported if a voting system supports cross party endorsement?
7.1-D.8 EMS, split precincts, define precincts and election districts

EMSs of the Split precincts device class SHALL support the definition of election districts and precincts in such a way that a given polling place may serve two or more election districts.

Applies To: EMS Λ Split precincts device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.2 and glossary

 
7.1-D.9 EMS, N-of-M voting

EMSs of the N-of-M voting device class SHALL be capable of defining contests where the voter is allowed to choose up to a specified number of contest choices (N(r) > 1, per Part 1: 8.3 "Logic Model (normative)") from a list of contest choices.

Applies To: EMS Λ N-of-M voting device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.2, I.2.3.2.a and glossary

 

1 Comment

Comment by Premier Election Solutions (Manufacturer)

In this requirement, the explanation of N of M seems complex. Simpler terms can be used to define N of M. Proposed Change: Change the requirement to read as follows: EMSs of the N-of-M voting device class SHALL be capable of defining contests where the voter is allowed to choose N selections from M options.
7.1-D.10 EMS, cumulative voting

EMSs of the Cumulative voting device class SHALL be capable of defining contests where the voter is allowed to allocate up to a specified number of votes (N(r) > 1, per Part 1:8.3 "Logic Model (normative)") over a list of contest choices, possibly giving more than one vote to a given contest choice.

Applies To: EMS Λ Cumulative voting device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.2, I.2.3.2.a and glossary

 
7.1-D.11 EMS, ranked order voting

EMSs of the Ranked order voting device class SHALL be capable of defining contests where the voter is allowed to rank contest choices in a contest in order of preference, as first choice, second choice, etc.

Applies To: EMS Λ Ranked order voting device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.2 and glossary

 
7.1-E Election definition accuracy

The EMS SHALL record the election contests, contest choices, issues, and political and administrative subdivisions exactly as defined by central election officials.

Applies To: EMS

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.2.2.1.a / [VVSG2005] I.2.1.2.a

 

1 Comment

Comment by Carl Hage (General Public)

This is inadequate. The election definition must be recorded with full legal names, correctly spelled, capitalized, and punctuated without abbreviation-- independent of election officals. The EMS should support verification by the an official within each jurisdiction for names used on contests, and candidates should verify name and labels within the EMS. To support verification of names, the content must be made public and the solicitations made to each candidate and official within each jurisdiction to validate the public EMS content.
7.1-F Voting options accuracy

The EMS SHALL record the options for casting and recording votes exactly as defined by central election officials.

Applies To: EMS

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Reworded from [VSS2002] I.2.2.2.1.b / [VVSG2005] I.2.1.2.b

 
7.1-G EMS, confirm recording of election definition

The EMS SHALL verify (i.e., actively check and confirm) the correct recording of election definition data to the persistent storage of the device.

Applies To: EMS

Test Reference: Part 3: 4.3 "Verification of Design Requirements"

DISCUSSION

"Persistent storage" includes nonvolatile memory, hard disks, optical disks, etc.

Source: [VSS2002] I.3.2.3.1.c and e ([VVSG2005] I.4.1.3.1.c and e), expanded to include persistent storage

 

2 Comments

Comment by Carolyn Coggins (Voting System Test Laboratory)

It would be a more effective document if all code review requirements like this were included in the code review section?

Comment by Gail Audette (Voting System Test Laboratory)

"Please define the pass/fail criteria and/or the test methodology for a static design review that will ""verify (i.e., actively check and confirm) the correct recording of election definition data to the persistent storage of the device"". "
7.1-H EMS, election definition distribution

The EMS SHALL provide for the generation of master and distributed copies of election definitions as needed to configure each voting device in the system.

Applies To: EMS

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Reworded from [VSS2002] I.2.3.2.e

 

7.2 Ballot Preparation, Formatting, and Production

7.2-A EMS, define ballot styles

The EMS SHALL enable central election officials to define ballot styles.

Applies To: EMS

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.2.6.c

 
7.2-A.1 EMS, auto-format

The EMS SHALL be capable of automatically formatting ballots in accordance with the requirements for offices and contest choices qualified to be placed on the ballot for each political subdivision and election district.

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.3.1.1.1.a

 
7.2-A.2 EMS, include votable contests

The EMS SHALL provide for the inclusion in a given ballot style of any contest in which the voter would be entitled to vote.

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Extrapolated from relevant requirements in [VSS2002]

 
7.2-A.3 EMS, exclude nonvotable contests

The EMS SHALL provide for the exclusion from a given ballot style of any contest in which the voter would be prohibited from voting because of place of residence or other such administrative or geographical criteria.

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

In systems supporting primary elections, this would include the exclusion of party-specific contests that are not votable by the selected political party.

Source: [VSS2002] I.2.3.2.c

 
7.2-A.4 EMS, nonpartisan formatting

The EMS SHALL uniformly allocate space and fonts used for each office, contest choice, and contest such that the voter perceives no contest choice to be preferred to any other.

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.3.1.2.c

 
7.2-A.5 EMS, jurisdiction-dependent content

The EMS SHALL enable central election officials to add jurisdiction-dependent text, line art, logos and images to ballot styles.

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Reworded from [VSS2002] I.3.2.3.1.d

 

1 Comment

Comment by Carolyn Coggins (Voting System Test Laboratory)

This requirement has been changed so that voting systems are required to accommodate logos, images and line art in contest choice displays? These have been previously optional. This is also grouped within contests. Why would there be line art, logos or images in a contest? (Organizationally 7.2 A seems to be all over the map)
7.2-A.6 EMS, primary elections, associate configurations with parties

EMSs of the primary elections device class SHALL support the association of different ballot configurations with different political parties.

Applies To: EMS Λ Primary elections device

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

In paper-based systems, open primaries have sometimes been handled by printing a single ballot style that merges the contests from all parties, instructing the voter to vote only in the contests applicable to a single party, and rejecting or discarding votes that violate this instruction. To satisfy the requirements for primary elections device, the EMS must be capable of associating different ballot configurations with different political parties.

Source: Reworded from [VSS2002] I.2.3.1.1.1.d

 
7.2-A.7 EMS, ballot rotation

EMSs of the Ballot rotation device class SHALL support the production of rotated ballots and/or the activation of ballot rotation functions in vote-capture devices through the inclusion of relevant metadata in distributed election definitions and ballot styles.

Applies To: EMS Λ Ballot rotation device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.2 and glossary

 

1 Comment

Comment by Carolyn Coggins (Voting System Test Laboratory)

What precision has been added? Provide clarification of the specific methods of rotation. Specify the types of rotation .... by precinct? By machine? By other methods? Should the EMS let you define if only candidates rotate or should questions?
7.2-A.8 EMS, split precincts, associate ballot configurations

EMSs of the Split precincts device class SHALL support the definition of distinct ballot configurations for voters from two or more election districts that are served by a given polling place.

Applies To: EMS Λ Split precincts device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.2 and glossary

 
7.2-B EMS, ballot style distribution

The EMS SHALL provide for the generation of master and distributed copies of ballot styles as needed to configure each voting device in the system.

Applies To: EMS

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Reworded from [VSS2002] I.2.2.6.d

 
7.2-B.1 EMS, ballot style identification

The EMS SHALL generate codes or marks as needed to uniquely identify the ballot style associated with any ballot.

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

In paper-based systems, identifying marks would appear on the actual ballots. DREs would make internal use of unique identifiers for ballot styles but would not necessarily present these where the voter would see them.

When different precincts share a common ballot style in a paper-based system, typically it is assumed that the ballots from the two precincts will be kept physically separate, tabulated separately, and attributed to the correct precinct at the time of reporting—even in combined precincts where this imposes procedural overhead.

Source: [VSS2002] I.2.3.1.1.1.e

 
7.2-C EMS, ballot style reuse

The EMS SHALL support retention, modification, and reuse of ballot styles within the same election and from one election to the next.

Applies To: EMS

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.3.1.2.e and g

 

1 Comment

Comment by Premier Election Solutions (Manufacturer)

Although general districting/precinct data and general ballot formatting parameters can be re-used from election to election, it is not possible to re-use ballot styles which will always change from election to election. It was mentioned in the VVSG introduction that the term "ballot style" was chosen to replace the term "ballot format" due to the common acceptance of the former term. However, as "ballot style" is defined in the VVSG, it is now used to describe everything on the ballot, including the contests, candidates and its finished image, which, for security purposes, should not be re-used from election to election, nor would it practically be used from election to election as contests and candidates should change. It would seem that intent of this requirement actually pertains to the format used for ballot styles and not the ballot style directly as it is currently defined. Proposed Change: Change the requirement to the following: "The EMS SHALL support retention, modification, and reuse of the format used for ballot styles within the same election and from one election to the next."
7.2-D EMS, ballot style protection

The EMS SHALL prevent unauthorized modification of any ballot styles.

Applies To: EMS

Test Reference: Part 3: 4.5.2 "Security", 5.4 "Open-Ended Vulnerability Testing"

Source: [VSS2002] I.2.3.1.2.f

 

7.2.1 Procedures required for correct system functioning

The requirements for voting systems are written assuming that these procedures will be followed.

Paper ballot production: central election officials must verify that paper ballots are produced in accordance with manufacturer specifications.

Paper ballot production quality: central election officials must ensure that paper ballots conform to manufacturer specifications for type of paper stock, weight, size, shape, size and location of field used to record votes, folding, bleed through, and ink for printing. ([VSS2002] I.2.3.1.3.1.c)

Paper ballot field alignment: Central election officials must ensure that the vote response fields can be properly aligned with respect to any ballot marking devices used. ([VSS2002] I.2.3.1.1.2.b)

Paper ballot timing mark alignment: central election officials must ensure that timing marks align properly with the vote response fields. ([VSS2002] I.2.3.1.1.2.c)

 

7.3 Equipment Setup for Security and Integrity

7.3.1 Logic and accuracy testing

The purpose of logic and accuracy testing is to detect malfunctioning and misconfigured devices before polls are opened. It is not a defense against fraud.[9]

Election personnel conduct equipment and system readiness tests prior to the start of an election to ensure that the voting system functions properly, to confirm that system equipment has been properly integrated, and to obtain equipment status and readiness reports. The content of those reports is defined in Part 1: 7.8 "Reporting".

 

2 Comments

Comment by Carl Hage (General Public)

The "Logic and accuracy testing" should include public access and inspection as an integral part of the process. Data files produced by an EMS to be loaded into vote collection or counting equipment should be digitally signed by the election official and make with electronic access public (e.g. copied to a web server and/or distributed via email list). The voting equipment should only support loading of data files co-signed by a higher election authority, e.g. the secretary of state or FEC. All content and digital signatures made to co-sign election data files should be public, collected and audited by the FEC. (Inside the US.) To facilitate verification of ballot styles and election districts, the election officials must make a digitally signed data file available (with public electronic access), containing a mapping between street address ranges and election districts, and a mapping between election districts and jurisdictions and political and administrative subdivisions. To facilitate computer checking, names of contests, elected offices, jurisdictions, and subsivisions must use the full legal name, properly spelled, capitalized, and punctuated. Each election official must define a process to collect errors in spelling, abbreviations, or missing words. Any EMS data file that contains abbreviations or truncations must also produce a mapping file containing the complete correct spelling for any truncated or abbreviated name. [Note: current ballot counting systems often limit the number of characters in contest or candidate names, so candidate names are truncated and contests abbreviated-- sometimes in a human unreadable manner. To allow electronic validation, these errors need to be removed in an automatic manner.]

Comment by David Beirne, Executive Director, Election Technology Council (Manufacturer)

Strike "It is not a defense against fraud." This is a subjective statement and should be stricken and is not relevant to the section.
7.3.1-A Support L&A testing

All systems SHALL provide the capabilities to:

  1. Verify that all voting devices are properly prepared for an election and collect data that verify equipment readiness;
  2. Verify the correct installation and interface of all system equipment;
  3. Verify that hardware and software function correctly; and
  4. Segregate test data from actual voting data, either procedurally or by hardware/software features.

Applies To: Voting system

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.3.4.1, I.2.3.5.a2 and b2 (the second a and b, respectively), I.4.4.2.a

 
7.3.1-B Built-in self-test and diagnostics

All programmed devices SHALL include built-in measurement, self-test, and diagnostic software and hardware for monitoring and reporting the system's status and degree of operability.

Applies To: Programmed device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.2.4.1.j, I.2.2.8.1.a

 
7.3.1-C Verify proper preparation of ballot styles

The EMS SHALL enable central election officials to test that ballot styles and programs have been properly prepared and installed.

Applies To: EMS

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.2.6.f, I.4.4.2.c

 
7.3.1-D Verify proper installation of ballot styles

Programmed devices SHALL include a capability to automatically verify that the software and ballot styles have been properly selected and installed in the equipment and immediately notify an election official of any errors.

Applies To: Programmed device

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

Examples of detectable errors include use of software or data intended for a different type of device and operational failures in transferring the software or data.

Source: [VSS2002] I.2.3.3.b, I.4.4.2.c

 

1 Comment

Comment by Carolyn Coggins (Voting System Test Laboratory)

Clarify "notify an election official of errors"
7.3.1-E Verify compatibility between software and ballot styles

Programmed devices SHALL include a capability to automatically verify that software correctly matches the ballot styles that it is intended to process and immediately notify an election official of any errors.

Applies To: Programmed device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.3.3.c, I.4.4.2.c

 
7.3.1-F Test ballots

Programmed tabulators SHALL provide the capability for central election officials or election judges to submit test ballots for use in verifying the integrity of the system.

Applies To: Programmed device Λ Tabulator

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.4.3.3.s, generalized from DREs; I.4.4.2.d and f

 

1 Comment

Comment by Premier Election Solutions (Manufacturer)

It is unclear as to why election judges have been included under this requirement. Testing of the programmed devices should have been completed before an election judge takes possession of the unit for use on Election Day. Please clarify why election judges are included under this requirement.
7.3.1-G Test all ballot positions

Paper-based tabulators SHALL support testing that uses all potential ballot positions as active positions.

Applies To: Paper-based device Λ Tabulator

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.3.4.2.a, I.4.4.2.f

 
7.3.1-H Paper-based tabulators, testing calibration

Paper-based tabulators SHALL support the use of test ballots to test the calibration of the paper-to-digital conversion (i.e., the calibration of optical sensors, the density threshold, and/or the logical reduction of scanned images to binary values, as applicable).

Applies To: Paper-based device Λ Tabulator

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Interpretation of [VSS2002] I.2.3.4.2.b

 
7.3.1-I Ballot marker readiness

Paper-based vote-capture devices SHALL include a means of verifying that the ballot marking mechanism is properly prepared and ready to use.

Applies To: Vote-capture device Λ Paper-based device

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

In the case of manually-marked paper ballots this requirement is mostly moot. (Sharpen the pencils.)

Source: [VSS2002] I.2.4.1.2.1.a

 
7.3.1-J L&A testing, no side-effects

Logic and accuracy testing functions SHALL introduce no residual side-effects other than audit log entries and status changes to note that the tests have been run with a successful or failed result.

Applies To: Voting device

Test Reference: Part 3: 4.3 "Verification of Design Requirements", 5.2 "Functional Testing"

DISCUSSION

Status changes required to satisfy Requirement Part 1: 7.4-A and Requirement Part 1: 7.4-B.

Source: [VSS2002] I.2.3.4.1.b2 (the second b), significantly revised

 

1 Comment

Comment by Premier Election Solutions (Manufacturer)

This requirement is ambiguous. Proposed Change: Change the requirement ot read as follows: Logic and accuracy testing functions SHALL introduce no effects on the election mode operation other than audit log entries, status changes to note that the tests have been run with a successful or failed result, separate storage of test results, changes in the system counter, and normal wear and tear.
7.3.1-J.1 Isolate test ballots

Programmed tabulators SHALL ensure that all test data have been expunged before the logic and accuracy test is logged as successful. If the test data have not been expunged the logic and accuracy test SHALL log as failed.

Applies To: Programmed device Λ Tabulator

Test Reference: Part 3: 4.3 "Verification of Design Requirements", 5.2 "Functional Testing"

DISCUSSION

Test data must never be reflected in official vote counts for specific contest choices.

Source: [VSS2002] I.2.4.3.3.t / [VVSG2005] I.2.3.3.3.v, generalized from DREs; I.4.4.2.e / [VVSG2005] I.5.4.2.e

 

1 Comment

Comment by Premier Election Solutions (Manufacturer)

This condition means the system must know that it is in an L&A test mode for a wide range of operations. If the concern is that test results, not just L&A test results, are on the system during voting it would be better to phrase this as requiring all test results to be purged from the system prior to being prepared for election counting. Alternatively, simply require that test data be isolated from election results. Proposed Change: Change the requirement to read as follows: Programmed tabulators SHALL ensure that all test data have been expunged prior to being prepared for capturing election results or that the test data is isolated from the election results. If the test data have not been expunged or isolated, then the logic and accuracy test SHALL log as failed.

7.4 Opening Polls

7.4-A Programmed device, verify L&A performed

Programmed devices SHALL provide an internal test or diagnostic capability to verify that all of the tests specified in Part 1: 7.3 "Equipment Setup for Security and Integrity" have been successfully completed.

Applies To: Programmed device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.4.1.1.a

 
7.4-B Programmed device, disable untested devices

Programmed devices SHALL provide for automatic disabling of an untested device until it has been tested.

Applies To: Programmed device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.4.1.1.b

 
7.4-C Paper-based tabulator activation

Paper-based tabulators SHALL include a means of activating the ballot counting device.

Applies To: Paper-based device Λ Tabulator

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.4.1.2.2.a

 
7.4-D Paper-based tabulator, verify activation

Paper-based tabulators SHALL include a means of verifying that the ballot counting device has been correctly activated and is functioning properly.

Applies To: Paper-based device Λ Tabulator

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.4.1.2.2.b

 
7.4-E Programmed vote-capture device, open poll function

Programmed vote-capture devices SHALL provide designated functions for opening the poll.

Applies To: Vote-capture device Λ Programmed device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.4.1.3, generalized

 
7.4-E.1 Programmed vote-capture device, protect open poll function

Programmed vote-capture devices SHALL include a security seal, a password, or a data code recognition capability to prevent the inadvertent or unauthorized actuation of the poll-opening function.

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.4.1.3.a

 

1 Comment

Comment by Premier Election Solutions (Manufacturer)

This requirement might be construed to mean that the device must make itself completely inoperable if it has not been tested, rather than what is believed to be the intent of not allowing the unit to continue onto a live election mode mode unless it has been tested. Proposed Change: Change the requirement to read as follows: Programmed devices SHALL not allow the unit to proceed to the election mode unless the logic and accuracy test has been performed successfully.
7.4-E.2 Programmed vote-capture device, enforce correct poll opening process

Programmed vote-capture devices SHALL include a means of enforcing the execution of poll-opening steps in the proper sequence if more than one step is required.

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.4.1.3.b

 
7.4-E.3 Programmed vote-capture device, verify activation

Programmed vote-capture devices SHALL include a means of verifying that the system has been correctly activated.

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.4.1.3.c

 

7.5 Casting

These functional capabilities include all operations conducted at the polling place by voters and officials while polls are open.

 

7.5.1 Issuance of voting credentials and ballot activation

The term "ballot activation" is sometimes used in a broad sense to cover the general activities of (1) determining what type of ballot must be presented to the voter, and (2) activating the voting system to present the ballot style that is appropriate for that voter. In this section, "issuance of voting credentials" is used for the first activity, and "ballot activation" is used exclusively for the second activity.

Voting credentials are those data items sufficient for the voting system to activate the appropriate ballot for the voter. The credentials consist of an indication of the ballot style and ballot configuration as well as any additional ballot options that the voting system may be capable of presenting if selected by the voter, such as a magnified ballot for a voter with low vision. If the voting system is used for provisional voting, the credentials may also include an identifier that effectively would link the voter's identity with the voter’s cast ballot. The credentials must also indicate the election for which the credentials are valid. Lastly, there is usually a code calculated on the credentials so that the voting system can verify their integrity and verify that an authorized activation device issued the credentials.

An activation device (e.g., an epollbook) stores the credentials on a token (e.g., a memory card) so that the voter can carry them to the vote-capture device – a DRE or EBP. Thus, there is typically an "air gap" required between the activation device and the vote-capture device. The requirements in this section do not prohibit, however, the activation device from being connected to a network of DREs or EBPs. In this case, the credentials and token would be represented by whatever signaling and data is exchanged across the network between the activation device and the DREs/EBPs. Credential issuance also may be performed pre-election by a DRE or EBP in a ballot activation mode (for example, a series of memory cards could be activated for certain ballot styles and ballot configurations in advance of opening the polls).

Preserving privacy of the ballot is a paramount consideration in issuance of voter credentials and ballot activation because knowledge of the voter’s identity is involved. The requirements in this section mandate that privacy of the ballot be protected throughout the entire process of Credential issuance and ballot activation, and that no information be maintained in reports or logs that could assist in identifying a voter’s cast ballot (except for provisional voting on a DRE).

Provisional voting using a DRE must, however, "violate" voter privacy because it is necessary to link the DRE’s CVR with the voter’s identity. If an epollbook or other programmable activation device is used also for provisional voting, then it is possible that the epollbook could keep a record of provisional voters and include, with the voting credentials, an identifier associated with each provisional voter’s identification. The DRE might then associate that identifier with that voter’s CVR. This should only happen if the activation device and the vote-capture device are in a "provisional voting" mode; no linkage of voter identity to voter CVRs should be possible otherwise. While this may be an acceptable method for associating a voter’s identity with the voter’s CVR for provisional voting, at the same time this privacy violation is cause for special concern when implemented in software, and the source code associated with these activities on the activation device and the vote-capture device should receive extra scrutiny. As well, this general process should be considered fair game for OEVT.

This section also contains requirements that permit a ballot activation device to connect to an external voter registration database via a network. Network connectivity is inherently difficult to secure and make reliable, therefore the requirements in this section mandate that the external connectivity must be enabled/disabled by an authorized election official, and that a backup mechanism be in place if the connectivity fails. A ballot activation device or DRE/EBP used as an activation device cannot be connected simultaneously to both an internal (to the voting site) network of DREs or EBPs, and an external network. (The ballot activation device cannot include more than one network interface.) Any external network connectivity should be considered fair game for OEVT and, in particular, network vulnerability and penetration testing.

For provisional voting, if the linkage between the voter’s identity and the voter’s CVR is recorded in the external voter registration database, this may also be considered as fair game for OEVT.

 

4 Comments

Comment by Brian V. Jarvis (Local Election Official)

Regarding external network connectivity. Given the serious concerns stated regarding this feature, I would recommend that verification of this functionality not wait until OEVT and network vulnerability and penetration testing. Long before OEVT, the functionality of the modules implementing this feature should be verified and validated during the design, coding, and unit/integration testing phases of the development lifecycle. (And, documentation submitted in the TDP should indicate this verification was performed.) Waiting until OEVT to identify deficiencies in the system would require the systems/software to have to be opened-up, patched, and then re-verified (including regression testing, etc.). A basic premise of software/system development is that you catch defects as early in the development lifecycle as is possible -- and certainly not wait until system qualification testing.

Comment by George Gilbert (Local Election Official)

7.5.1—Paragraphs 4 and 5 discuss the restriction of CVR identification with a voter to "provisional" voting. North Carolina (not uniquely), however, requires that all "absentee" ballots be "identifiable and retrievable." Ballot secrecy, in our case, is, by law, the responsibility of the local Board of Elections not of the voting system used. The proposed language should be modified to accommodate the unique feature of state law and widely varying procedures employed among the states to protect voter secrecy rather than dictate a single, uniform technical standards that precludes state flexibility.

Comment by David Beirne, Executive Director, Election Technology Council (Manufacturer)

"An activation device (e.g., an epollbook) stores the credentials on a token (e.g., a memory card)" Strike the reference to an epollbook as not all epollbooks may be used during the ballot activiation process.

Comment by Cem Kaner (Academic)

A majority of respondents, in a poll of the IEEE SCC38 Voting Standards committee, supported the recommendation that: "The use of electronic poll books be banned in polling locations and that printed poll books be required." .......... The underlying concern is that in past cases in which fraud has been detected, printed poll books with voters' actual signatures have been important records. .......... VVSG does not take a comprehensive look at the auditability of election records and therefore it is difficult to assess the impact of substitution of printed poll books with electronic ones. Given that there have been so many problems with electronic voting equipment, the addition of more electronic components is bound to be met with appropriate mistrust. .......... (Affiliation Note: IEEE representative to TGDC)

7.5.1.1 Credential issuance and ballot activation

7.5.1.1-A Activation device, DRE, EBP, ballot activation

DREs and EBPs SHALL support ballot activation.

Applies To: DRE, EBP

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

All DREs and EBPs, in addition to ballot activators, must support ballot activation, as defined in the following subrequirements.

Source: [VSS2002] I.2.4

 
7.5.1.1-A.1 Activation device, DRE, EBP, credential issuance

DREs or EBPs MAY function exclusively as an activation device and issue ballot activation credentials.

Applies To: DRE, EBP

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

A DRE or EBP could be configured, pre-election, to function exclusively as an activation device. During elections, a DRE or EBP cannot be used as both an activation device and a vote-capture device.

Source: New requirement but existing practice

 
7.5.1.1-A.2 Activation device, DRE, EBP, at most one cast ballot per session

Activation devices, DREs, and EBPs SHALL enable poll workers either to initiate, or to provide the voter with the credentials sufficient to initiate, a voting session in which the voter may cast or print at most one ballot.

Applies To: Activation device, DRE, EBP

Test Reference: Part 3: 4.5 "Source Code Review", 5.2 "Functional Testing"

DISCUSSION

A voting session on an EBP may culminate with the printing of the ballot. Activation devices, DREs, and EBPs must prevent re-use of the credentials, e.g., by erasing a memory token used to carry ballot activation information.

Source: [VSS2002] I.2.4.2.d, rewritten to respect the limits of what the system can do

 
7.5.1.1-B Activation device, contemporaneous record

Activation devices MAY create contemporaneous records of credential issuance to a voter. The record, once made, SHALL NOT be able to be modified by the voting system.

Applies To: Activation device

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

The voting system must create a record at the time when credentials are issued to voters so that the collection of records can be compared to the number of ballots voted. This may be done if the activation device prints a record, or by using a paper pollbook.

Source: New requirement

 
7.5.1.1-C Activation device, DRE, EBP, control ballot configuration

Activation devices, DREs, and EBPs SHALL enable poll workers to control the ballot configuration(s) made available to the voter, whether presented in printed form or electronic display, such that each voter is permitted to record votes only in contests in which that voter is authorized to vote.

Applies To: Activation device, DRE, EBP

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

For an electronic display, poll workers control the ballot configuration using an activation device and issuing credentials. See also Requirement Part 1: 7.2-A.2, Requirement Part 1: 7.2-A.3.

Source: [VSS2002] I.2.4.2.a

 
7.5.1.1-C.1 Activation device, DRE, EBP, enable only applicable contests

DREs and EBPs SHALL activate all portions of the ballot upon which the voter is entitled to vote and SHALL disable all portions of the ballot upon which the voter is not entitled to vote.

Applies To: DRE, EBP

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

In paper-based systems, open primaries have sometimes been handled by printing a single ballot style that merges the contests from all parties, instructing the voter to vote only in the contests applicable to a single party, and rejecting or discarding votes that violate this instruction. To use that approach on a DRE or EBP would violate this requirement.

Source: [VSS2002] I.2.4.2.g., [VSS2002] I.2.4.2.h

 
7.5.1.1-C.2 Activation device, DRE, EBP, select ballot configuration for party in primary elections

DREs and EBPs SHALL enable the selection of the ballot configuration that is appropriate to a party affiliation declared by the voter in a primary election.

Applies To: DRE Λ Primary elections device, EBP Λ Primary elections device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.4.2.f

 

7.5.1.2 Secrecy of the ballot

7.5.1.2-A Activation device, ballot secrecy

Activation devices, DREs, EBPs SHALL preserve secrecy of the ballot throughout the process of issuing credentials and activating the ballot and the keeping of records associated with ballot activation.

Applies To: Activation device, DRE, EBP

Test Reference: Part 3: 4.5 "Source Code Review", 5.2 "Functional Testing", 5.4 "Open-Ended Vulnerability Testing"

DISCUSSION

Secrecy of the ballot must be preserved during all operations associated with activation of the ballot, including during the creation of the ballot activation credential and information, during the process of activating the ballot, and in all keeping of associated records, reports, and logs. It must not be possible to identify a voter’s ballot or in some way violate secrecy of the ballot by aggregating records from different devices.

For example, an epollbook cannot retain and associate any information written to a ballot activation token with the voter’s identification information, and a vote-capture device cannot retain information from the token and associate it with the CVR – or else it would be possible to link the sets of records and identify the voter.

Note that Requirement Part 1: 7.5.1.2-A.3 modifies this requirement if the activation device is used with provisional voting on a DRE.

Source: New requirement

 
7.5.1.2-A.1 DRE and EBP, open primaries, party selection should be private

In an open primary on a DRE or EBP, the voter SHOULD be allowed to choose a party affiliation in private at the start of the voting session and vote the appropriate ballot configuration (i.e., the choice of affiliation SHOULD be private as well as the selection of votes on the ballot).

Applies To: DRE Λ Open primaries device, EBP Λ Open primaries device

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

In an open primary, the voter may be able to choose a party affiliation at the start of the voting session, therefore more than one ballot configuration may be available to the voter. The voter should be able to select the ballot configuration corresponding to the voter's chosen party affiliation in privacy.

Source: New requirement

 

2 Comments

Comment by Carolyn Coggins (Voting System Test Laboratory)

The definition of an Open Primary in the Glossary does not match the requirement of a private selection. If the VVSG is using Open Primary to mean a primary where party selection is made in private then it should be clearly indicated that the standard uses the term to define the ballot selection process and not the various political definitions used by states. The VVSG should either use Open & Closed primaries to describe system functions of private and non-private selection of a party ballot or create specific terms that identify the selection process. Closed and Open primaries are being used inconsistently in the standard.

Comment by George Gilbert (Local Election Official)

The definition of "Open Primary" points out that state rule differ regarding the "privacy" allowed a voter in selecting a party affiliation in an "open primary." The way this provision is worded makes it sound as if voter privacy in selecting party is prefered. Section should read that the DRE or EPB should have the capability to allow private selection leaving the options of which is prefered to the states.
7.5.1.2-A.2 Activation device, records preserve secrecy of the ballot

Activation devices SHALL NoT create or retain information that can be used to identify a voter’s ballot, including the order and time at which a voter uses the voting system.

Applies To: Activation device, DRE, EBP

Test Reference: Part 3: 5.2 "Functional Testing", 5.4 "Open-Ended Vulnerability Testing"

DISCUSSION

The activation device must not create or retain any information that could be used for the purposes of identifying a voter’s ballot, or the time at which the voter arrived at the polls, or the specific vote-capture device used by the voter.

Source: New requirement

 
7.5.1.2-A.3 Activation device, ballot activation provisional voting

Credential issuance, only when used during provisional voting, MAY permit the voter’s name to be associated with the voter’s ballot for the purposes of deciding whether to count the ballot. The mechanism used for this association SHALL itself not identify the voter.

Applies To: Activation device, DRE, EBP

Test Reference: Part 3: 5.2 "Functional Testing", 5.4 "Open-Ended Vulnerability Testing"

DISCUSSION

For provisional voting, the voter’s identity is associated with the voter’s ballot so as to permit a subsequent decision whether to count the ballot. As an example, the activation device may create an identifier and associate it with the provisional voter’s identity, and then include this identifier with other information necessary to activate the ballot. The vote-capture device may store this identifier with the ballot so as to trace the ballot back to the voter’s identity for the purposes of deciding whether the count the ballot. The identifier must not itself identify the voter. For example, it must not include the voter’s identity or other information associated with the voter such as an SSN or other identifying information.

Source: New requirement

 

2 Comments

Comment by George Gilbert (Local Election Official)

7.5.1.2-A.3-- North Carolina (not uniquely) requires that all "absentee" ballots, in addition to "provisional" ballots, be "identifiable and retrievable." Ballot secrecy, in our case, is, by law, the responsibility of the local Board of Elections not of the voting system used. The proposed language should be modified to accommodate the unique feature of state law and widely varying procedures employed among the states to protect voter secrecy rather than dictate a single, uniform technical standards that precludes state flexibility.

Comment by Robert Ferraro, SAVEourVotes.org (Advocacy Group)

There should be no exception allowing a vote to be associated with a unique number identifying the voter, even for early or provisional voting. The risk of losing the privacy of the vote is way too great compared to the efficiency gained. Provisional voters can vote on paper provisional ballots. The best way to avoid a possible breakdown in privacy is to prohibit the vendors from building the capability of associating a vote to a voter in the voting system. Certification should require both testing the voting units and the ballot activation devices and examination of their source code, to verify that they do not have this capability. If the proposed guideline 7.5.1.2-A.3 is implemented as written, and voting systems are permitted to accomodate this dangerous capability, it would require that each and every county, that is concerned about the secrecy of the ballot, perform the necessary testing to ensure that it is not being used. Most counties do not have sufficient expertise to accomplish this task. Moreover, such testing would be prohibitively expensive.

7.5.1.3 Credentials and tokens

7.5.1.3-A Activation device, credentials and tokens

The sole purpose and use of the ballot activation credentials and token SHALL be for the purpose of activating the ballot.

Applies To: Voting device

Test Reference: Part 3: 5.2 "Functional Testing", 5.4 "Open-Ended Vulnerability Testing"

DISCUSSION

The credentials and associated token are to be used only for ballot activation and not for other purposes. For example, the token or credentials cannot be used to convey additional information to the vote-capture device or other devices, or to convey information from the vote-capture device to other devices in the case of re-usable tokens.

Source: New requirement

 

1 Comment

Comment by Premier Election Solutions (Manufacturer)

This requirement should allow for the token to record the fact that the voter did cast their ballot by de-activating the token. If tokens are not de-activated after the ballot is cast, then they could be used to cast additional ballots. Proposed Change: Change the requriement to read as follows: The sole purpose and use of the ballot activation credentials and token SHALL be for the purpose of activating the ballot and then de-activating the token once the ballot has been cast.
7.5.1.3-A.1 Activation device, token limited in capacity

The token SHOULD have the capacity to contain only the information sufficient to activate the ballot.

Applies To: Activation device

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

The token should be limited to containing only the necessary information and nothing more – on memory card, possibly several bytes or less. This requirement addresses the threat of the token being used to pass other information to and from the vote-capture device, which should be considered especially if the activation device is connected to an external network (to connect to a registration database).

Source: New requirement

 
7.5.1.3-A.2 Activation device, DRE, EPB, token de-activated after casting

DREs and EBPs SHALL de-activate ballot activation credentials on the token after the voter has successfully cast the ballot.

Applies To: DRE, EBP

Test Reference: Part 3: 4.5 "Source Code Review", 5.2 "Functional Testing"

DISCUSSION

The token and credentials are considered as authorization to cast a ballot and therefore must be de-activated after that ballot has been cast (and not before). It may be useful for the token to carry state information, such as:

  1. Inactive - ready to be used in an activation device;
  2. Active - loaded with credentials and able to activate the ballot;
  3. In use - has been used to activate the ballot but the ballot has not yet been cast;
  4. Closed successfully - has been used to activate the ballot and the ballot has been cast successfully; and
  5. Closed unsuccessfully - has been used to activate the ballot but the ballot was not successfully cast for some reason.

Source: New requirement

 
7.5.1.3-A.3 Activation device, token should be non-reusable

The ballot activation token SHOULD be non-reusable by activation devices.

Applies To: Activation device

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

The token should be one-way in that it is used only once to activate the ballot and cannot be recycled and used again by an activation device to activate a subsequent ballot. This eliminates the threat of passing other information from the vote-capture device back to the activation device, which should be considered especially if the activation device is connected to an external network (to connect to a registration database).

Source: New requirement

 

1 Comment

Comment by Carolyn Coggins (Voting System Test Laboratory)

It appears that this requirement only permits the use of a voter smart card one time in an election. Isn't there an huge cost to jurisdictions to have thousands, tens of thousands or hundreds of thousands of smart cards in the polls ? Isn't there a greater risk of voters being unable to vote because precincts run out of cards?
7.5.1.3-A.4 Activation device, integrity and authenticity of ballot activation information

Ballot activation credentials SHALL be created in such a manner that the vote-capture device can verify their integrity and authenticity for the current election and for that vote-capture device.

Applies To: Activation device, DRE, EBP

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

The vote-capture device must verify the integrity of the credentials and their validity for the election, but also must verify whether they were created from a trusted activation device and for use on the vote-capture device. This means essentially that some trust relationship must exist between the vote-capture device and the ballot activator. One approach for implementing this cryptographically is for each ballot activator to calculate, for each credential issued, a keyed-hash message authentication code, or HMAC, on the credentials, and for the vote-capture device to verify the HMAC. If cryptography is used, key sizes are determined by cryptography requirements in Part 1: 5.1 "Cryptography".

Source: New requirement

 

7.5.1.4 Activation devices connected to remote registration databases

7.5.1.4-A Activation device, may access remote registration database

The activation device MAY connect to an external network for the purposes of accessing and updating information from a remote voter registration database.

Applies To: Activation device ^ Electronic device

Test Reference: Part 3: 5.2 "Functional Testing", 5.4 "Open-Ended Vulnerability Testing"

DISCUSSION

External is used here to mean "a public or private network extending beyond the voting site." An activation device may include the capability to access an external network for the purposes of accessing voter identification information in a remote voter registration database. Note that this is the only remote access permitted; network access cannot be used for other purposes such as for accessing web sites, email, etc. See also related requirements in Part 1: 5.5 "System Integrity Management" and 5.6 "Communication Security" pertaining to secure system and network configurations for the ballot activation device.

Source: New requirement

 

1 Comment

Comment by Ariel J. Feldman, Harlan Yu, Joseph A. Calandrino (Princeton University) (Academic)

This allows devices at polling places to connect to public communication networks to interface with voter registration databases. Connecting these devices to the public networks provides adversaries with yet another interface to attack, and one that can be exploited remotely on many devices simultaneously. In addition, networks, even private networks, provide a means for viruses to propagate quickly. Thus, although networks can be useful to elections (e.g. quickly reporting unofficial results and checking voter registration in real-time), we believe that their security risks outweigh their benefits. Voting machines should never be networked to each other or to any other device, and, if possible, neither should election management systems (EMSs), polling place accumulators, or pollbook devices. We also suggest that voting systems adopt a "segregated dual-EMS architecture," where devices used to initialize an election are distinct from devices used to tabulate election results (see: J.A. Calandrino, A.J. Feldman, J.A. Halderman, D. Wagner, H. Yu, B. Zeller. Source Code Review of the Diebold Voting System. July 2007. Section 6.10.) This architecture hinders the spread of viruses and reduces the possibility that viruses could persist from one election to the next.
7.5.1.4-A.1 Activation device, cannot connect to multiple networks

The activation device SHALL connect to at most one network; either a network connection to vote-capture devices or an external network for the purposes of accessing information in a remote voter registration database, but not both.

Applies To: Activation device ^ Electronic device

Test Reference: Part 3: 5.2 "Functional Testing", 5.4 "Open-Ended Vulnerability Testing"

Source: New requirement

 
7.5.1.4-A.2 Activation device, access to remote registration database configurable

The activation device SHALL have the capability to access an external network only if so authorized by an administrator.

Applies To: Activation device ^ Electronic device

Test Reference: Part 3: 5.2 "Functional Testing", 5.4 "Open-Ended Vulnerability Testing"

DISCUSSION

An election official must have the ability to enable or disable the remote access capability, i.e., its network interface and associated logic.

Source: New requirement

 
7.5.1.4-A.3 Activation device, notification of access to remote registration database

The activation device SHALL display a continuous indication to the poll worker during the period it is enabled to access an external network.

Applies To: Activation device ^ Electronic device

Test Reference: Part 3: 5.2 "Functional Testing", 5.4 "Open-Ended Vulnerability Testing"

DISCUSSION

The notification must be continuous and obvious to the poll worker.

Source: New requirement

 
7.5.1.4-A.4 Activation device, remote access failure backup capability

The voting system SHALL include a backup capability to activate ballots if access to a remote registration database fails.

Applies To: Voting system

Test Reference: Part 3: 5.2 "Functional Testing", 5.4 "Open-Ended Vulnerability Testing"

DISCUSSION

If the remote database is unavailable, the voting system must include some backup capability so that it may continue to activate ballots, e.g., a cached local copy of the voter registration database or a paper pollbook.

Source: New requirement

 
7.5.1.4-A.5 Activation device, connects to router/firewall

If externally networked, the activation device SHALL connect to a router with network firewall capabilities using a wired connection and the TCP/IP communications protocol.

Applies To: Activation device ^ Electronic device

Test Reference: Part 3: 5.2 "Functional Testing", 5.4 "Open-Ended Vulnerability Testing"

DISCUSSION

This requirement prohibits the activation device from connecting directly to the external network and possibly using a wireless connection. The device must connect to a router over a wire (e.g., Ethernet). The router must have firewall capability and be configured to block or filter unneeded services and protocols. See [NIST02] for suggested firewall configuration information.

Source: New requirement

 

1 Comment

Comment by Gail Audette (Voting System Test Laboratory)

This design requirement limits innovation by requiring TCP/IP and wired connections. Is it the intent of this requirement to impede use of current and emerging technologies?
7.5.1.4-B Activation device, source code reviews

Activation devices SHALL be free of vulnerabilities that may be exploited by remote attackers over the network.

Applies To: Activation device ^ Electronic device

Test Reference: Part 3: 4.5 "Source Code Review" and 5.2 "Functional Testing", 5.4 "Open-Ended Vulnerability Testing"

DISCUSSION

The source code review must consider that the activation device may be accessed via an external network. Certain aspects of the software may be significantly more vulnerable to attack than if there were no external network connectivity. The test lab must review the source code of activation device software and inspect COTS configuration data to search for vulnerabilities that might be exploitable through the external network.

Source: New requirement

 

2 Comments

Comment by Gail Audette (Voting System Test Laboratory)

The discussion implies that this requirement applies to all activation devices, even those that do not have the capability of being networked (the preceding requirements do not require that a card activation device be attached to a network). Is this a design requirement forcing a component to be designed to support a capability that is not that system's functional requirement?

Comment by Premier Election Solutions (Manufacturer)

This requirement should only be required if the device is connected to an external network. Proposed Change: Change the requirement to read as follows: Activation devices SHALL be free of vulnerabilities that may be exploited by remote attackers over the network, if the activation device is capable of being connected to a network.

7.5.2 General voting functionality

7.5.2-A No advertising

The ballot presented to the voter SHALL NOT display or link to any advertising or commercial logos of any kind, whether public service, commercial, or political, unless added by central election officials using the functionality described in Requirement part1: 7.2-A.5.

Applies To: Vote-capture device

Test Reference: Part 3: 4.3 "Verification of Design Requirements", 5.2 "Functional Testing"

Source: Clarification of [VSS2002] I.2.3.1.3.1.b

 

2 Comments

Comment by George Gilbert (Local Election Official)

7.5.2-A--While I agree entirely with this restriction, it does not seem germaine to this section. If the concern is security, it should appear there rather than here.

Comment by Premier Election Solutions (Manufacturer)

As the ballot content is under the control of the jurisdiction, such a requirement is not relevant to vote capture device. In respect to compliance with legal requirements and copyright notices, a manufacturer is required to provide identification on the unit and certain software displays. Please clarify whether this requirement prevents a manufacturer from providing their identification in respect to compliance with legal requirements and copyright notices.
7.5.2-B Capture votes

All vote-capture devices SHALL record the selection and non-selection of individual contest choices for each contest.

Applies To: Vote-capture device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.4.3.1.c

 

7.5.3 Voting variations

7.5.3-A Vote-capture device, voting variations

All vote-capture devices SHALL support the gathering of votes using all voting variations indicated for them in the implementation statement.

Applies To: Vote-capture device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Extrapolated from [VSS2002] I.2.2.8.2 and I.2.4

 

1 Comment

Comment by Premier Election Solutions (Manufacturer)

This section clearly defines the requirements and having all of the sub-sections does not add any extra information or value and should therefore be removed. Proposed Change: Remove all sub-sections to this requirement.
7.5.3-A.1 Vote-capture device, 1-of-M

All vote-capture devices SHALL be capable of gathering and recording votes in contests where the voter is allowed to choose at most one contest choice from a list of contest choices.

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.4. Extended [VSS2002] I.2.4.2.e to all systems

 

1 Comment

Comment by Premier Election Solutions (Manufacturer)

This requirement is redundant since it is already defined in the election programming section. If necessary have section 7.5.3-A just refer to the election programming section. Also this is just a special case of the N-of-M case. Proposed Change: Remove this requirement.
7.5.3-A.2 Vote-capture device, yes/no question

All vote-capture devices SHALL be capable of gathering and recording votes in contests where the voter is allowed to vote yes or no on a question.

Test Reference: Part 3: 5.2 "Functional Testing"

Source: New requirement / clarification of [VSS2002] intent

 

1 Comment

Comment by Premier Election Solutions (Manufacturer)

This requirement is redundant since it is already defined in the election programming section. If necessary have section 7.5.3-A just refer to the election programming section. Also this is just a special case of the N-of-M case. Proposed Change: Remove this requirement.
7.5.3-A.3 Vote-capture device, indicate party affiliations and endorsements

All vote-capture devices SHALL be capable of indicating the affiliation and/or endorsements of each contest choice.

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision

 

1 Comment

Comment by Premier Election Solutions (Manufacturer)

This requirement is redundant since it is already defined in the election programming section. If necessary have section 7.5.3-A just refer to the election programming section. Also this is just a special case of the N-of-M case. Proposed Change: Remove this requirement.
7.5.3-A.4 Vote-capture device, closed primaries

Vote-capture devices of the closed primaries device class SHALL be capable of gathering and recording votes within a voting process that assigns different ballot styles depending on the registered political party affiliation of the voter and supports both party-specific and non-party-specific contests.

Applies To: Vote-capture device Λ Closed primaries device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.2 and glossary

 

1 Comment

Comment by Carolyn Coggins (Voting System Test Laboratory)

The registration of the voter does not generate system functionality that selects the primary ballot, unless an e-pollbook provides this function via network or token writing. The selection is made by the poll worker either through direct selection on the voting system or programming of a token. In some states this may occur in Open Primaries that permit voters to cross over to another party's primary. The VVSG should either use Open & Closed primaries to describe system functions of private and non-private selection of a party ballot or create specific terms that identify the selection process. Closed and Open primaries are being used inconsistently in the standard.
7.5.3-A.5 Vote-capture device, open primaries

Vote-capture devices of the open primaries device class SHALL be capable of gathering and recording votes within a voting process that assigns different ballot styles depending on the political party chosen by the voter at the time of voting and supports both party-specific and non-party-specific contests.

Applies To: Vote-capture device Λ Open primaries device

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

In paper-based systems, open primaries have sometimes been handled by printing a single ballot style that merges the contests from all parties, instructing the voter to vote only in the contests applicable to a single party, and rejecting or discarding votes that violate this instruction. To satisfy the requirements for open primaries device, the vote-capture device must be capable of handling the case where different ballot configurations are associated with different political parties.

Source: Added precision, based on [VSS2002] I.2.2.8.2 and glossary

 
7.5.3-A.6 Vote-capture device, write-ins

Vote-capture devices of the write-ins device class SHALL record the voter's selection of candidates whose names do not appear on the ballot and record as many write-in votes as the voter is allowed, per the definition of N(r) in Part 1: 8.3 "Logic Model (normative)".

Applies To: Vote-capture device Λ Write-ins device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.4.3.1.d

 
7.5.3-A.7 Vote-capture device, support write-in reconciliation

Vote-capture devices of the write-ins device class SHALL be capable of gathering and recording votes within a voting process that allows for reconciliation of aliases and double votes.

Applies To: Vote-capture device Λ Write-ins device

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

Reconciliation of aliases means allowing central election officials to declare two different spellings of a candidate's name to be equivalent (or not). Reconciliation of double votes means handling the case where, in an N-of-M contest, a voter has attempted to cast multiple votes for the same candidate using the write-in mechanism. See Part 1: 7.7.2.4 "Logic for reconciling write-in double votes" for details.

Source: Added precision based on clarification of write-in reconciliation process

 
7.5.3-A.8 Vote-capture device, ballot rotation

Vote-capture devices of the ballot rotation device class SHALL be capable of gathering and recording votes when the ordering of contest choices in ballot positions within each contest is variable.

Applies To: Vote-capture device Λ Ballot rotation device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.2 and glossary

 
7.5.3-A.9 Ballot rotation, equal time for each contest choice

Programmed vote-capture devices that enable ballot rotation in a given contest SHALL alter the ordering of contest choices in such a manner that no contest choice SHALL ever have appeared in any particular ballot position two or more times more often than any other.

Applies To: Vote-capture device Λ Programmed device Λ Ballot rotation device

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

This is less restrictive than requiring sequential rotation. For a contest of M contest choices, the order may be shuffled randomly after each batch of M ballots and rotated sequentially within each batch.

Source: Clarification or extension of existing requirements

 

1 Comment

Comment by Premier Election Solutions (Manufacturer)

This requirement is ambiguous. There are many variations in rotation algorythms that attempt to achieve this result since rotation is usually done on a precinct by precinct basis and not within a precinct on with a voting device. Rotation algorythms are dictated by State Law. A voting system may have the ability to provide rotation, but this standard should not attempt to dictate the numerous variations mandated by laws of various States. Proposed Change: Change this requirement to the following: Voting systems that enable ballot rotation in a given contest SHALL alter the ordering of contest choices in a manner consistent with the documented rotation algorythms. Applies to: Voting system
7.5.3-A.10 Vote-capture device, straight party voting

Vote-capture devices of the straight party voting device class SHALL be capable of gathering and recording votes for a special contest in which the selection of a political party implies votes for the contest choices endorsed by that party in all straight-party-votable contests on the ballot.

Applies To: Vote-capture device Λ Straight party voting device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.2 and glossary

 

1 Comment

Comment by Carolyn Coggins (Voting System Test Laboratory)

"What should be the behavior in a straight party selection: - to cross over and select a candidate in another party in one or more contests - what is the behavior of a cross over when the vote for is a 1 of M and an N of M; - with no affiliated candidates; < than the vote for; = to the vote for; > than the vote for - non-partisan contests or questions? "
7.5.3-A.11 Vote-capture device, cross-party endorsement

Vote-capture devices of the cross-party endorsement device class SHALL be capable of gathering and recording straight-party votes when a given contest choice is endorsed by two or more different political parties.

Applies To: Vote-capture device Λ Cross-party endorsement device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Clarification or extension of existing requirements

 

2 Comments

Comment by Carolyn Coggins (Voting System Test Laboratory)

What is the required functionality of a Cross Party Endorsement in N of M contests.? Can 1 candidate get 2 votes, 1 for each party?

Comment by Premier Election Solutions (Manufacturer)

This requirement does not take into account the action required when conflicts arise between the straight party vote and the specific candidate vote. Further define this requirement to provide required actions by the vote-capture device when conflicts occur between the straight party vote and the specific candidate vote.
7.5.3-A.12 Vote-capture device, split precincts

Vote-capture devices of the split precincts device class SHALL be capable of gathering and recording votes in a precinct where there are distinct ballot styles for voters from two or more election districts.

Applies To: Vote-capture device Λ Split precincts device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.2 and glossary

 
7.5.3-A.13 Vote-capture device, N-of-M voting

Vote-capture devices of the N-of-M voting device class SHALL be capable of gathering and recording votes in contests where the voter is allowed to choose up to a specified number of contest choices (N(r) > 1, per Part 1 8.3 "Logic Model (normative)") from a list of contest choices.

Applies To: Vote-capture device Λ N-of-M voting device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.2 and glossary

 
7.5.3-A.14 Vote-capture device, cumulative voting

Vote-capture devices of the cumulative voting device class SHALL be capable of gathering and recording votes in contests where the voter is allowed to allocate up to a specified number of votes (N(r) > 1, per Part 1 per Part 1: 8.3 "Logic Model (normative)") over a list of contest choices, possibly giving more than one vote to a given contest choice.

Applies To: Vote-capture device Λ Cumulative voting device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.2 and glossary

 

1 Comment

Comment by Carolyn Coggins (Voting System Test Laboratory)

Insufficient detail: No precision has been added. This is the same vague requirement as the 2005 standard. If there are multiple ways to handle cumulative votes identify them and provide detailed requirements so they can be consistently tested. How does the voting system record a cumulative vote in the selection of 2 in a vote for 3? Does each candidate get 1.5 votes? Does the voter select one candidate's name twice & another candidate's name once?
7.5.3-A.15 Vote-capture device, ranked order voting

Vote-capture devices of the ranked order voting device class SHALL be capable of gathering and recording votes in contests where the voter is allowed to rank contest choices in a contest in order of preference, as first choice, second choice, etc.

Applies To: Vote-capture device Λ Ranked order voting device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.2 and glossary

 

1 Comment

Comment by Carolyn Coggins (Voting System Test Laboratory)

No precision has been added from the 2005 standard. Should the voting system have to support ranking of all contest choices? Is there a minimum acceptable number that must be ranked?
7.5.3-A.16 Vote-capture device, provisional-challenged ballots

Vote-capture devices of the provisional-challenged ballots device class SHALL be capable of gathering and recording votes within a voting process that allows the decision whether to count a particular ballot to be deferred until after election day.

Applies To: Vote-capture device Λ Provisional-challenged ballots device

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

Unique identification of each provisional/challenged ballot is required. See Requirement Part 1: 7.7.2-A.5.

Source: Added precision, based on [VSS2002] I.2.2.8.2 and glossary

 

1 Comment

Comment by Carolyn Coggins (Voting System Test Laboratory)

Poorly stated requirement. It appears that this can be defined in the polling place. The requirement should address this in terms of the totals being included or excluded from the polling place totals when the polls are closed. Also this should be an EMS requirement.
7.5.3-A.17 DRE, categorize provisional ballots

DREs of the provisional-challenged ballots device class SHALL provide the capability to categorize each provisional/challenged ballot.

Applies To: DRE Λ Provisional-challenged ballots device

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

Categories (e.g., "regular provisional," "extended hours provisional," "regular extended hours") would be jurisdiction-dependent.

Source: [P1583] 5.6.5.2.s.2[5]

 

1 Comment

Comment by Carolyn Coggins (Voting System Test Laboratory)

What are the specific provisional categories that the voting system must support? If these are defined by the election official then this requirements also needs to be addressed in the EMS.
7.5.3-A.18 Vote-capture device, review-required ballots

Vote-capture devices of the review-required ballots device class SHALL be capable of gathering and recording votes within a voting process that requires certain ballots to be flagged or separated for review.

Applies To: Vote-capture device Λ Review-required ballots device

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

In some systems and jurisdictions, all ballots containing write-in votes require flagging or separation for review. Support for the class indicates that the system can flag or separate ballots in this manner and include the results of the review in the reported totals (see Part 1: 2.5.3.1 "Supported voting variations (system-level)"). Other reasons for which ballots are flagged or separated are jurisdiction-dependent. It is assumed that ballot presentation is unchanged for Review-required ballots.

Source: Extrapolated from [VSS2002] I.2.5.2

 

7.5.4 Recording votes

7.5.4-A Record votes as voted

Vote-capture devices SHALL record each vote precisely as indicated by the voter.

Applies To: Vote-capture device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.2.2.1.c / [VVSG2005] I.2.1.2.c

 
7.5.4-A.1 Records consistent with feedback to voter

All CVRs and logs SHALL be consistent with the feedback given to the voter.

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision

 

2 Comments

Comment by Carolyn Coggins (Voting System Test Laboratory)

Assuming that this requirement includes the audit log, the requirement should be clarified to exclude feedback provided to the voter during the voting session.

Comment by Craig Burton, CTO, EveryoneCounts.com (Manufacturer)

There is no specification of how voting- and system- messages are specified via the EMS, nor how they are provided if there are multiple languages. L&A testing should also seek to cause all such messages to display. That is, "ballot style proofs" do not show system messages.
7.5.4-B DRE, confirm votes recorded

DREs SHALL verify (i.e., actively check and confirm) the correct addition of votes to the persistent storage of the device.

Applies To: DRE

Test Reference: Part 3: 4.3 "Verification of Design Requirements", 4.5 "Source Code Review"

DISCUSSION

"Persistent storage" includes nonvolatile memory, hard disks, optical disks, etc.

Source: [VSS2002] I.3.2.4.3.3.c, expanded to include persistent storage

 

1 Comment

Comment by Christopher (None)

It is also of PARAMOUNT importance that the voter receive some kind of receipt for the transaction that has been made. This receipt should include an anonymous unique transaction ID, time, date and each vote cast. This way a user (or official) can, at the request of any voter in possession of this receipt, verify any vote cast by it's Transaction ID.
7.5.4-C Casting

All systems SHALL support the casting of a ballot.

Applies To: Voting system

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

This does not entail retaining a ballot image. DREs are required to retain ballot images (see Part 1: 4.3 "Electronic Records") but other devices might not.

Source: [VSS2002] I.2.4. Extended [VSS2002] I.2.4.2.e to all systems

 
7.5.4-C.1 Equipment allows each eligible voter to vote

All systems SHALL make it possible for each eligible voter to cast a ballot, provided that the limits declared in the implementation statement for each device are not exceeded.

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

See also Requirement Part 1:7.5.7.

Source: [VSS2002] I.2.4.2.b, generalized to all systems

 

1 Comment

Comment by Carolyn Coggins (Voting System Test Laboratory)

Clarify what the implementation statement limits might be.
7.5.4-C.2 Paper-based, must have secure ballot boxes

Systems that include paper-based vote-capture devices SHALL include secure receptacles for holding voted ballots.

Applies To: Paper-based device Λ Vote-capture device

Test Reference: Part 3: 4.2 "Physical Configuration Audit"

Source: [VSS2002] I.2.4.1.2.1.c

 

1 Comment

Comment by Premier Election Solutions (Manufacturer)

The definition of "secure" is ambiguous and should be more clearly defined. Further define the term "secure" to a testable requirement.
7.5.4-D DRE, cast is committed

DREs SHALL prevent modification of the voter's vote after the ballot is cast.

Applies To: DRE

Test Reference: Part 3: 4.5.2 "Security", 5.4 "Open-Ended Vulnerability Testing"

DISCUSSION

See also Part 1: Section 7.5.7, cast ballot.

Source: [VSS2002] I.2.4.3.3.n

 

7.5.5 Redundant records

This section contains design requirements to enhance the recoverability of DRE devices. This is a separate concern from auditability, which is addressed in Part 1: Chapter 4: "Security and Audit Architecture". However, in some systems, the same records might satisfy both these requirements and auditability requirements.

 
7.5.5-A DRE, at least two separate copies of CVR

DREs SHALL record and retain at least two machine-countable copies of each CVR.

Applies To: DRE

Test Reference: Part 3: 4.3 "Verification of Design Requirements"

DISCUSSION

Besides data stored in electronic memory, a paper record with barcodes or EBM-style markings or a paper record printed in a machine-readable font would qualify as machine-countable.

Source: [VSS2002] I.2.2.2.2, I.2.2.4.2 and I.3.2.4.3.2.c

 

1 Comment

Comment by George Gilbert (Local Election Official)

7.5.5-A--It should be clarified whether a machine countable IVVR would qualify as one of these copies.
7.5.5-A.1 DRE, redundant CVRs on physically separate media

These redundant records SHALL be written to media that are physically separate from one another (e.g., two separate memory cards or one electronic record and one paper record).

Test Reference: Part 3: 4.3 "Verification of Design Requirements"

DISCUSSION

For improved auditability, it is preferable for the processes and paths used to record separate records to themselves to be as separate as possible, so that the opportunities for a single error to corrupt multiple records in the same way are minimized.

Source: [VSS2002] I.2.2.4.2 and I.3.2.4.3.2.c

 

1 Comment

Comment by George Gilbert (Local Election Official)

7.5.5-A.1—This section should specify that this redundancy requirement should be executed contemporaneously and that multiple memory chips within a DRE does not constitute compliance with this provision. My experience has been that, if one of the redundant memories in a DRE machine becomes corrupted, the reliability of all memory records becomes suspect….at least the way most DRE systems I have administered in the past (4 of them) have been designed….because of the interaction between these memory locations. Most DRE systems provide a separate, removable, medium for redundant capture of CVRs but some systems do not write these CVRs to this separate medium until the close of polls when all records are then written to the redundant medium. In this case, no sufficiently separate copy of the CVRs can be retrieved if the internal memory locations become corrupted.

7.5.6 Respecting limits

7.5.6-A Tabulator, prevent counter overflow

When a tabulator can no longer accept another ballot without the potential of overflowing a vote counter or otherwise compromising the integrity of the counts, it SHALL notify the user or operator and cease to accept new ballots.

Applies To: Tabulator

Test Reference: Part 3: 4.5 "Source Code Review", 5.2 "Functional Testing"

DISCUSSION

Assuming that the counter size is large enough such that the value will never be reached is not adequate. Systems are required to detect and prevent an impending overflow condition.

Source: Clarification of [VSS2002] II.5.4.2.g

 
7.5.6-A.1 DRE, stop when full

When a DRE can no longer accept another ballot without the potential of overflowing a vote counter or otherwise compromising the integrity of the counts, it SHALL emit appropriate warnings and audit events and cease to activate new ballots.

Applies To: DRE

Test Reference: Part 3: 4.3 "Verification of Design Requirements", 4.5 "Source Code Review", 5.2 "Functional Testing", Requirement Part 3: 4.6-B

DISCUSSION

A DRE must not initiate a voting session if there is the possibility that the next ballot could not be properly cast and recorded. If there exists a way of voting the ballot that would exceed one of the limits, then the ballot must not be activated.

Source: Clarification of [VSS2002] II.5.4.2.g

 

1 Comment

Comment by Premier Election Solutions (Manufacturer)

This requirement is redundant as it is already covered in 7.6.6-A. Proposed Change: Remove this requirement.

7.5.7 Procedures required for correct system functioning

The requirements for voting systems are written assuming that these procedures will be followed.

Process allows each eligible voter to vote: The voting process must allow each eligible voter to cast a ballot. ([VSS2002] I.2.4.2.b, generalized from DRE systems to the voting process.) See also Requirement Part 1: 7.5.4-C.1.

At most one cast ballot per voter: The voting process must prevent a voter from casting more than one ballot in the same election. ([VSS2002] I.2.4.2.d, generalized from DRE systems to the voting process.) See also Requirement Part 1: 7.5.1.1-A.2.

Process ensures correct ballot style: The voting process must prevent a voter from voting a ballot style to which he or she is not entitled. ([VSS2002] I.2.4.2.c, generalized from DRE systems to the voting process.) See also Requirement Part 1: 7.2-A.2, Requirement Part 1: 7.2-A.3 and Requirement Part 1: 7.5.1.1-C.

Process prevents vote tampering: The voting process must prevent modification of the voter's vote after the ballot is cast. ([VSS2002] I.2.4.3.3.n, generalized.) See also Requirement Part 1: 7.5.4-D, cast ballot.

Early voting, ballot accounting: In the presence of a witness, election judges must record the value of the ballot counter from each tabulator at the end of each active period. (Issue #1366, Issue #2143) See Part 1: 8.2 "Vote-Capture Device State Model (informative)". This procedure might be facilitated by designated functions of the voting equipment (i.e., printing of special early-voting end-of-day reports that include the timestamp, the value of the ballot counter, and little else).

Early voting, resumption practices: election judges returning equipment to the ready state after it has been placed in the suspended state must perform this operation in the presence of a witness, confirm that the equipment recorded no activity, and confirm that the ballot counter is unchanged from the value that was recorded when voting was suspended. See Part 1: 8.2 "Vote-Capture Device State Model (informative)". This procedure might be facilitated by designated functions of the voting equipment (i.e., printing of special early-voting resumption reports that include the timestamp, the value of the ballot counter, confirmation that nothing happened overnight, and little else).

 

1 Comment

Comment by David Beirne, Executive Director, Election Technology Council (Manufacturer)

The last two paragraphs of this section contain language that can be considered requirements for election practices not subject to the VVSG. If the intent is to provide a recommendation, the language should be amended to reflect this. See below for suggested edits: Early voting, ballot accounting: Election judges should record the value of the ballot counter from each tabulator at the end of each active period. (Issue #1366, Issue #2143) See Part 1: 8.2 "Vote-Capture Device State Model (informative)". This procedure might be facilitated by designated functions of the voting equipment (i.e., printing of special early-voting end-of-day reports that include the timestamp, the value of the ballot counter, and little else). Early voting, resumption practices: election judges returning equipment to the ready state after it has been placed in the suspended state should confirm that the equipment recorded no activity, and confirm that the ballot counter is unchanged from the value that was recorded when voting was suspended. See Part 1: 8.2 "Vote-Capture Device State Model (informative)". This procedure might be facilitated by designated functions of the voting equipment.

7.6 Closing Polls

7.6-A DRE, no CVRs before close of polls

DREs SHALL prevent access to CVRs until after the close of polls.

Applies To: DRE

Test Reference: Part 3: 4.5.2 "Security", 5.4 "Open-Ended Vulnerability Testing"

DISCUSSION

This does not apply to paper-based devices because the ballot is subject to handling beyond their control; however, a locked ballot box (per Requirement Part 1: 7.5.4-C.2 and Requirement Part 1: 6.1-F) serves the same purpose. See also Requirement Part 1: 7.7.1-A.

Source: [VSS2002] I.2.4.3.3.r

 

1 Comment

Comment by George Gilbert (Local Election Official)

7.6-A—This restriction could be problematic for early voting on DRE machines. During early voting, the polls are "open" for as much as several weeks. This leaves the CVRs on the machines vulnerable to mishap throughout this extended time if no backup of the records is retrieved and secured in a separate location. Procedures in my jurisdiction provide for a nightly backup of all early voting CRVs to a removable medium and secure storage of such backup throughout the voting, auditing and canvassing period. Such capability, which is vital in my view, to the security of early voting CRVs, would be prohibited by the current provision as written. Your discussion acknowledges that, for paper based voting systems, the voting equipment itself cannot meet this rigid restriction. Ballot security for such systems must be handled procedurally by each local jurisdiction. If this is permissible for paper based voting jurisdictions, there appears to be no justification, and the risk of catastrophic unintended consequences, of not treating DRE systems by the same standard.
7.6-B Programmed vote-capture devices, poll-closing function

Programmed vote-capture devices SHALL provide designated functions for closing the polls.

Applies To: Vote-capture device Λ Programmed device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Reworded from [VSS2002] I.2.5

 
7.6-B.1 Programmed vote-capture devices, no voting when polls are closed

Programmed vote-capture devices SHALL prevent the further enabling, activation or marking of ballots by those devices once the polls have closed.

Test Reference: Part 3: 4.5.2 "Security", 5.4 "Open-Ended Vulnerability Testing"

DISCUSSION

An EBM cannot prevent a voter from marking a paper ballot with a writing utensil after polls have closed. This must be prevented through procedures.

Source: Reworded from [VSS2002] I.2.5.1.a

 
7.6-B.2 DRE, no ballot casting when polls are closed

DREs SHALL prevent the further casting of ballots once the polls have closed.

Applies To: DRE

Test Reference: Part 3: 4.5.2 "Security", 5.4 "Open-Ended Vulnerability Testing"

Source: Reworded from [VSS2002] I.2.5.1.a

 
7.6-B.3 Programmed vote-capture devices, poll closing integrity check

Programmed vote-capture devices SHALL provide an internal test that verifies that the prescribed closing procedure has been followed and that the device status is normal.

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Reworded from [VSS2002] I.2.5.1.b

 
7.6-B.4 Programmed vote-capture devices, report on poll closing process

Programmed vote-capture devices SHALL provide a means to produce a diagnostic test record that verifies the sequence of events and indicates that the poll closing process has been activated.

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Reworded from [VSS2002] I.2.5.1.d

 
7.6-B.5 Programmed vote-capture devices, prevent reopening polls

Programmed vote-capture devices SHALL prevent reopening of the polls once the poll closing has been completed for that election.

Test Reference: Part 3: 4.5.2 "Security", 5.4 "Open-Ended Vulnerability Testing"

Source: Revised from [VSS2002] I.2.5.1.e; made consistent with [GPO90] 2.2.3.1

 
7.6-C Precinct EMS, post-election reports

Precinct EMSs SHALL provide designated functions for generating precinct post-election reports.

Applies To: Precinct tabulator Λ EMS

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Reworded from [VSS2002] I.2.5

 

1 Comment

Comment by Carolyn Coggins (Voting System Test Laboratory)

What is meant by "Precinct EMSs"? EMS is expected to be at the election office, not in the precinct or polling place.

7.6.1 Procedures required for correct system functioning

The requirements for voting systems are written assuming that these procedures will be followed.

Process, no early reporting: The voting process must prevent access to voted ballots until after the close of polls. ([VSS2002] I.2.4.3.3.r, generalized.) See also Requirement Part 1: 7.6-A.

 

7.7 Counting

7.7.1 Integrity

7.7.1-A Detect and prevent ballot style mismatches

All voting systems SHALL detect ballot style mismatches and prevent votes from being tabulated or reported incorrectly due to such a mismatch.

Applies To: Voting system

Test Reference: Requirement Part 3: 5.2.3-F.1

DISCUSSION

For example, if the ballot styles loaded on a tabulator disagree with the ballot styles that were used by vote-capture devices, the system must raise an alarm and prevent the incorrect ballot styles from being used during tabulation. Otherwise, votes could be ascribed to the wrong contest choices.

Such a mismatch should have been detected and prevented in L&A testing (see Requirement Part 1: 7.3.1-C, Requirement Part 1: 7.3.1-D and Requirement Part 1: 7.3.1-E), but if it was not, it must be detected and prevented before tabulation commences.

Source: Amplification of existing requirements

 

1 Comment

Comment by George Gilbert (Local Election Official)

7.7.1-A—A further variation on this theme is to prevent ballot style/precinct mismatched votes from being cast. Preventing their tabulation is a good feature, however, it leaves one with a partial ballot and no easy way to include the valid contests while excluding the invalid contests. (I speak from experience.) A DRE system should be designed to prevent the activation of the unit is there are conflicts in the "credentials" (precinct & ballot style)recorded on the "token" and the precinct/ballot style configuration programmed on the voting unit. Such conflicts can arise where the precinct/ballot style configuration in an electronic pollbook designed to activate the voter’s "token" does not match the precinct/ballot style configuration of the EMS. This can occur, and has, due to human error. Catching such errors in pre-election testing requires that all testing be executed in the same manner as voting occurs, ie., that activation of the voting units incorporate the ePollbook activation of tokens in carrying out L&A testing.
7.7.1-B Detect and reject ballots that are oriented incorrectly

Paper-based tabulators SHALL either:

  1. Correctly count ballots regardless of whether they are fed upside down, right side up, forward, or reversed; or
  2. Detect and reject ballots that are oriented incorrectly.

Applies To: Paper-based device Λ Tabulator

Test Reference: Requirement Part 3: 5.2.3-F.1

Source: New requirement

 

7.7.2 Voting variations

7.7.2-A Tabulator, voting variations

All tabulators SHALL support all voting variations indicated in the implementation statement.

Applies To: Tabulator

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.2.8.1 plus I.2.2.8.2

 

1 Comment

Comment by Premier Election Solutions (Manufacturer)

This section clearly defines the requirements and having all of the sub-sections does not add any extra information or value and should therefore be removed. Proposed Change: Remove all sub-sections to this requirement.
7.7.2-A.1 Tabulator, 1-of-M

All tabulators SHALL be capable of tabulating votes, overvotes, and undervotes in contests where the voter is allowed to choose at most one contest choice from a list of contest choices.

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Implicit in [VSS2002]

 

2 Comments

Comment by Carolyn Coggins (Voting System Test Laboratory)

DREs are tabulators. There is no overvoting on DREs. As such they cannot report overvotes.

Comment by Premier Election Solutions (Manufacturer)

This requirement is redundant since it is already defined in the election programming section. If necessary have section 7.7.2-A just refer to the election programming section. Also this is just a special case of the N-of-M case. Proposed Change: Remove this requirement.
7.7.2-A.2 Tabulator, yes/no question

All tabulators SHALL be capable of tabulating votes, overvotes, and undervotes in contests where the voter is allowed to vote yes or no on a question.

Test Reference: Part 3: 5.2 "Functional Testing"

Source: New requirement / clarification of [VSS2002] intent

 

1 Comment

Comment by Premier Election Solutions (Manufacturer)

This requirement is redundant since it is already defined in the election programming section. If necessary have section 7.7.2-A just refer to the election programming section. Also this is just a special case of the N-of-M case. Proposed Change: Remove this requirement.
7.7.2-A.3 Tabulator, absentee voting

Tabulators of the absentee voting device class SHALL be capable of tabulating votes, overvotes, and undervotes from absentee ballots.

Applies To: Tabulator Λ Absentee voting device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.1, I.2.2.8.2 and glossary

 

2 Comments

Comment by Carolyn Coggins (Voting System Test Laboratory)

The approach of classifying voting variations is convoluted and unworkable. This is about supported and unsupported functionality that can be turned off and on. Saying a system function is a type of device an unworkable description because whether it is turned on or off, its the same device. This comment is applicable to ALL 7.7.2 requirements.

Comment by Carolyn Coggins (Voting System Test Laboratory)

The approach of classifying Voting Variations is convoluted and unworkable. This is about supported and unsupported functionality that can be turned off and on. Hence saying absentee ballot functionality is a type of device doesn't work because whether it is turned on or off, its the same device. The implementation statement would need to describe the equipment as atabulator of the absentee and non-absentee ballot device class.
7.7.2-A.4 Tabulator, provisional-challenged ballots

Tabulators of the provisional-challenged ballots device class SHALL be capable of tabulating votes, overvotes, and undervotes in contests where the decision whether to count a particular ballot is deferred until after election day.

Applies To: Tabulator Λ Provisional-challenged ballots device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.1, I.2.2.8.2 and glossary

 

3 Comments

Comment by Carolyn Coggins (Voting System Test Laboratory)

When provisional ballots are on paper the process is to accept or reject the voter prior to counting the ballot. Is it correct to identify a requirement for paper based voting systems with provisional ballot functionality?

Comment by George Gilbert (Local Election Official)

7.7.2-A.4—As noted elsewhere, "provisional" and "challenged" ballots are not the only types of ballots that states require to be identifiable and retrievable, eg., North Carolina absentee ballots. The terminology we use to identify such ballots is "coded ballots." Recommend adopting this or a similar, general, designation rather that the restrictive reference to "provisional-challenged ballots."

Comment by Premier Election Solutions (Manufacturer)

The handling of overvotes, undervotes, etc. is not the definition of provisional-challenged ballots. A tabulator should be able to handle those conditions regardless as to whether the ballot is provisional, regularly cast, or an extended hours provisional ballot. Therefore this requirement needs to be changed to clarify what is being requested. Please clarify the intent of this requirement.
7.7.2-A.5 Tabulator, accept or reject provisional-challenged ballots individually

Tabulators of the provisional-challenged ballots device class SHALL support the independent acceptance and rejection of individual provisional/challenged ballots.

Applies To: Tabulator Λ Provisional-challenged ballots device

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

This is meant to rule out the mode of failure in which the IDs assigned to provisional ballots fail to be unique, rendering the system incapable of accepting one without also accepting the others with the same ID.

Source: Added precision, based on [VSS2002] I.2.2.8.1, I.2.2.8.2 and glossary

 

1 Comment

Comment by George Gilbert (Local Election Official)

7.7.2-A.5—As noted elsewhere, "provisional" and "challenged" ballots are not the only types of ballots that states require to be identifiable and retrievable, eg., North Carolina absentee ballots. The terminology we use to identify such ballots is "coded ballots." Recommend adopting this or a similar, general, designation rather that the restrictive reference to "provisional-challenged ballots."
7.7.2-A.6 Tabulator, accept or reject provisional-challenged ballots by category

Tabulators of the provisional-challenged ballots device class SHALL support the acceptance and rejection of provisional/challenged ballots by category.

Applies To: Tabulator Λ Provisional-challenged ballots device

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

For "category," see Requirement Part 1: 7.5.3-A.17. The behavior when an individual acceptance/rejection conflicts with a categorical acceptance/rejection is system-dependent and should be documented by the manufacturer.

Source: [P1583] 5.6.5.2.s.3[5]

 

3 Comments

Comment by Carolyn Coggins (Voting System Test Laboratory)

When provisional ballots are on paper the process is to accept or reject the voter prior to counting the ballot. Is it correct to identify a requirement for paper based voting systems with provisional ballot functionality?

Comment by George Gilbert (Local Election Official)

7.7.2-A.6—As noted elsewhere, "provisional" and "challenged" ballots are not the only types of ballots that states require to be identifiable and retrievable, eg., North Carolina absentee ballots. The terminology we use to identify such ballots is "coded ballots." Recommend adopting this or a similar, general, designation rather that the restrictive reference to "provisional-challenged ballots."

Comment by Premier Election Solutions (Manufacturer)

If this requirement is trying to state that overvoted, undervoted, etc ballots should be able to be accepted as a group then that definition needs to be clearer. Again the definition of provisional-challenged seems to be incorrect in this context. Please clarify the categories for which the tabulator must accept or reject a provisional-challenged ballot.
7.7.2-A.7 Tabulator, primary elections

Tabulators of the primary elections device class SHALL be capable of keeping separate totals for each political party for the number of ballots read and counted.

Applies To: Tabulator Λ Primary elections device

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

In paper-based systems, open primaries have sometimes been handled by printing a single ballot style that merges the contests from all parties and instructing the voter to vote only in the contests applicable to a single party. This approach requires additional logic in the tabulator to support the rejection or discarding of votes that violate these special instructions, while the approach of assigning different ballot configurations to different parties does not. Support for the merged ballot approach is not required for a tabulator to satisfy the requirements for primary elections device. See Part 1: 7.7.2.1 "Merged ballot approach to open primaries".

This requirement to separate by party applies only to the number of read ballots and counted ballots. It does not apply to contest choice vote totals.

Source: Added precision, based on [VSS2002] reporting requirements

 
7.7.2-A.8 Tabulator, write-ins

Tabulators of the write-ins device class SHALL be capable of tabulating votes for write-in candidates, with separate totals for each candidate.

Applies To: Tabulator Λ Write-ins device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.1, I.2.2.8.2 and glossary

 

2 Comments

Comment by Carolyn Coggins (Voting System Test Laboratory)

A write in is functionality that is either included or excluded from a contest, therefore the same system is write in voting device class and a non-write in voting device class. This approach is convoluted and unworkable.

Comment by Premier Election Solutions (Manufacturer)

If this requirement is to automatically tabluate votes for each of the write-in candidates then this assumes that the name of the write-in can be determined and is valid (note that some jurisdictions do not permit the reporting of write-in votes cast for candidates who have not met certain requirements.) For paper based systems, OCRing the write-in is not viable and is very error prone. Even for DRE systems voters mis-type or use variations of the names, so even those systems need a manual review. Proposed Change: Change this requirement to refer to the device class as "Automated Write-ins".
7.7.2-A.9 Tabulator, support write-in reconciliation

Tabulators of the write-ins device class SHALL be capable of gathering and recording votes within a voting process that allows for reconciliation of aliases and double votes.

Applies To: Tabulator Λ Write-ins device

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

Reconciliation of aliases means allowing central election officials to declare two different spellings of a candidate's name to be equivalent (or not). Reconciliation of double votes means handling the case where, in an N-of-M contest, a voter has attempted to cast multiple votes for the same candidate using the write-in mechanism. See Part 1: 7.7.2.4 "Logic for reconciling write-in double votes" for details.

Source: Added precision based on clarification of write-in reconciliation process

 
7.7.2-A.10 Tabulator, ballot rotation

Tabulators of the ballot rotation device class SHALL be capable of tabulating votes when the ordering of contest choices in ballot positions within each contest is variable.

Applies To: Tabulator Λ Ballot rotation device

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

This simply means that ballot rotation must not impact the correctness of the count. A mode of failure would be getting confused about the mapping from ballot positions to contest choices.

Source: Added precision, based on [VSS2002] I.2.2.8.1, I.2.2.8.2 and glossary

 

2 Comments

Comment by Carolyn Coggins (Voting System Test Laboratory)

Provide detailed pass/fail criteria for the various methods of rotation

Comment by Premier Election Solutions (Manufacturer)

This requirement is redundant since it is already defined in the election programming section. If necessary have section 7.7.2-A just refer to the election programming section. Proposed Change: Remove this requirement.
7.7.2-A.11 Tabulator, straight party voting

Tabulators of the straight party voting device class SHALL be capable of tabulating straight party votes.

Applies To: Tabulator Λ Straight party voting device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.1, I.2.2.8.2 and glossary

 

1 Comment

Comment by Premier Election Solutions (Manufacturer)

This requirement is redundant since it is already defined in the election programming section. If necessary have section 7.7.2-A just refer to the election programming section. Proposed Change: Remove this requirement.
7.7.2-A.12 Tabulating straight party votes

A straight party vote SHALL be counted as a vote in favor of all contest choices endorsed by the chosen party in each straight-party-votable contest in which the voter does not cast an explicit vote.

Applies To: Tabulator Λ Straight party voting device

Test Reference: Part 3: 4.6 "Logic Verification", 5.2 "Functional Testing"

DISCUSSION

This requirement intentionally says nothing about what happens when there is both a straight party endorsed contest choice and an explicit vote in a given contest (a straight party override). See Part 1: 7.7.2.3 "Logic for counting straight party overrides".

Source: Added precision, based on [VSS2002] I.2.2.8.1, I.2.2.8.2 and glossary

1 Comment

Comment by Premier Election Solutions (Manufacturer)

This requirement is redundant since it is already defined in the election programming section. If necessary have section 7.7.2-A just refer to the election programming section. Proposed Change: Remove this requirement.
7.7.2-A.13 Tabulator, cross-party endorsement

Tabulators of the cross-party endorsement device class SHALL be capable of tabulating straight-party votes when a given contest choice is endorsed by two or more different political parties.

Applies To: Tabulator Λ Cross-party endorsement device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.1, I.2.2.8.2 and glossary

 
7.7.2-A.14 Tabulator, split precincts

Tabulators of the split precincts device class SHALL be capable of tabulating votes for two or more election districts within the same precinct.

Applies To: Tabulator Λ Split precincts device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.1, I.2.2.8.2 and glossary

 
7.7.2-A.15 Tabulator, N-of-M voting

Tabulators of the N-of-M voting device class SHALL be capable of tabulating votes, overvotes, and undervotes in contests where the voter is allowed to choose up to a specified number of contest choices (N(r) > 1, per Part 1: 8.3 "Logic Model (normative)") from a list of contest choices.

Applies To: Tabulator Λ N-of-M voting device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.1, I.2.2.8.2 and glossary

 
7.7.2-A.16 Tabulator, cumulative voting

Tabulators of the cumulative voting device class SHALL be capable of tabulating votes, overvotes, and undervotes in contests where the voter is allowed to allocate up to a specified number of votes (N(r) > 1, per Part 1: 8.3 "Logic Model (normative)") over a list of contest choices however he or she chooses, possibly giving more than one vote to a given contest choice.

Applies To: Tabulator Λ Cumulative voting device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: Added precision, based on [VSS2002] I.2.2.8.1, I.2.2.8.2 and glossary

 
7.7.2-A.17 Tabulator, ranked order voting

Tabulators of the ranked order voting device class SHALL be capable of determining the results of a ranked order contest for each round of voting.

Applies To: Tabulator Λ Ranked order voting device

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

This requirement is minimal. Since ranked order voting is not currently in wide use, it is not clear what, other than the final result, must be computed. See Part 1: 7.7.2.5 "Logic for ranked order voting".

Source: [VSS2002] I.2.2.8.1 plus I.2.2.8.2

The following subsections discuss cases for which tabulation logic is not specified in the VVSG.

 

5 Comments

Comment by Carolyn Coggins (Voting System Test Laboratory)

Define testable pass/fail criteria for this functionality

Comment by Terrill Bouricius, FairVote: the Center for Voting and Democracy (Advocacy Group)

This should read at the end…"for each round of vote tabulation." or some such words, rather than "voting," as there is only a single round of VOTING in a ranked order voting election.

Comment by David Cary, Californian's for Electoral Reform (Advocacy Group)

It can be inappropriate to apply this requirement to all devices in the tabulator class. For example, in common configurations, it should not be required of a DRE or a precinct scanner.

Comment by Dave Kadlecek (Advocacy Group)

There are two separate but related processes in tabulating an instant runoff voting or single transferable vote election: counting the votes in each round of tabulation (using ballot information and information such as which candidates have been eliminated or elected in previous rounds) and using the count from a round of tabulation to elect or eliminate candidates, both determining whether another round is necessary and what will be counted in it if it is. One way of designing a voting system for ranked voting, used in most or all systems used to this date in the US, is for precinct level devices to simply capture ballot images which are later loaded into a central tabulator that conducts both related processes. In some systems for instant runoff voting, the precinct devices also tabulate the first round of voting, and the consolidated tallies used to determine whether the full ranked voting tabulation is necessary. Another way of designing a voting system for ranked voting, which I understand is used in presidential elections in the Republic of Ireland, separates the two processes. There, all rounds of counting are tabulated in regional counting centers that then report totals to a central headquarters. The headquarters consolidates the regional totals to determine what is needed for the next round and sends instructions to the regional counting centers. The guidelines should allow for ranked voting tabulators that cannot determine the results of a round of counting but only tabulate the ballots available to it following external instructions for a given round.

Comment by Premier Election Solutions (Manufacturer)

This requirement is redundant since it is already defined in the election programming section. If necessary have section 7.7.2-A just refer to the election programming section. Proposed Change: Remove this requirement.

7.7.2.1 Merged ballot approach to open primaries

In paper-based systems, open primaries have sometimes been handled by printing a single ballot style that merges the contests from all parties and instructing the voter to vote only in the contests applicable to a single party. This approach requires additional logic in the tabulator to support the rejection or discarding of votes that violate these special instructions, while the approach of assigning different ballot configurations to different parties does not.

Support for the merged ballot approach is not required for a tabulator to satisfy the requirements in these Guidelines for support of open primaries. Voting systems may provide this option as an extension to the Guidelines without breaking conformance.

 

1 Comment

Comment by Carolyn Coggins (Voting System Test Laboratory)

Define testable pass/fail criteria

7.7.2.2 Recall candidacy linked to recall question

In some jurisdictions, a vote for a candidate to replace a recalled official is counted only if the recall question on the same ballot was voted, and sometimes only if it was voted in the affirmative. Voting systems may provide this option as an extension to the Guidelines without breaking conformance.

 

1 Comment

Comment by Carolyn Coggins (Voting System Test Laboratory)

Define testable pass/fail criteria

7.7.2.3 Logic for counting straight party overrides

Although initially it seems obvious that a straight party override in a 1-of-M race should take precedence over a straight party vote, it is less obvious after considering the generalized case of an N-of-M race in which the number of candidates endorsed by the selected party might be less than N. Approaches supported by commercially available technology include (1) all straight party votes are cancelled when an explicit vote exists; (2) both straight party and explicit votes are counted; (3) both straight party and explicit votes are counted unless this exceeds N, in which case only the explicit votes are counted; (4) both straight party and explicit votes are counted unless this exceeds N, in which case straight party votes from the bottom of the list are dropped until the number of votes is reduced to N.

These Guidelines do not specify any particular approach to resolving straight party overrides, but the approach(es) supported are required to be described in the Voting Equipment User Documentation. See Requirement Part 2: 4.4.4-B.

 

3 Comments

Comment by Carolyn Coggins (Voting System Test Laboratory)

After half a dozen repetative empty requirements we find a woefully inadequate discussion that provides no guidance or pass/fail criteria on straight party functionality. (Is there a requirement that says you can only have straight party voting in a general election?) This document needs to provide real testable requirements with pass/fail criteria that define and address the functionality. Here's an example: 1) A straight party mark selects all candidates of the chosen party in a general election; non partisan and questions are not selected 2) Straight party selections can be by-passed; partisan and non-partisan candidates can be individually selected 3) After a straight party selection marks candidates of one party voters can cross over and change their vote to one or more candidates of another party. 4) If there is no candidate for a selected party in a contest no candidate is automatically selected 5) If the number of candidates is < or = to N in a contest all of the chosen party's candidates are automatically selected; if N in a contest the chosen party's candidates are not automatically selected

Comment by Terrill Bouricius, FairVote: the Center for Voting and Democracy (Advocacy Group)

While it may be premature in this round to standardize algorithms, etc. the time is overdue to convene an advisory group to begin the process of developing them. Major voting machine vendors such as ES&S and Sequoia already have, or are currently having, voting systems for ranked voting tested and certified by the labs. The absence of federal guidelines in this area is a major problem for both vendors and jurisdictions that have adopted ranked voting methods. It would be appropriate to have a two step set of guidelines; containing both minimum standards for retro-fitting legacy equipment, and best-practices guidelines for future products. Premier Election Systems (Diebold), ES&S, and Sequoia have all produced firmware to handle ranked voting on some of their existing machines. However, none of these machines are using what the advocacy community consider to be best practices. For example, ideally the output from the vote capture device should be a true representation of all voter choices made, regardless of validity (e.g. rather than inserting a generic "over-vote" code the output should show exactly what choices the voter made), and leave it to the subsequent step of vote tallying software to interpret those voter "marks." All three of these vendors have produced firmware for their optical scan machines that somewhat "cleans" the data that it outputs (such as skipped rankings or duplicate rankings, etc.). This makes auditing a ranked ballot election problematic, as there is no longer a one-to-one match up of ballot to data record. Thus a best practice for future systems would require that the vote capture device store anonymous uninterpreted ballot images from each voter. Also the output file should be in a common record format, such as a comma delimited text file rather than a proprietary format, to allow double checking algorithms by running the ranked ballot election through software other than just that provided by the vendor.

Comment by David Cary, Californians for Electoral Reform (Advocacy Group)

The first paragraph should reflect the option that the system will produce reportable results up to the point that a tie-breaking situation occurs, in order to facilitate an tie-breaking procedure that is external to the voting system. The section confuses the concepts of single-winner (IRV) and multi-winner (STV / choice voting) contests with the concepts of 1-of-M and N-of-M. The former are latter varieties of ranked order voting, while the latter are separate voting variations that are not relevant to ranked order voting. The lack of specific requirements is wrongly attributed to a lack of wide-spread use. Greater use of ranked order voting may simply further diversify the variety of options in use. The lack of specific requirements should instead be attributed to a combination of the options usable by local jurisdictions and to the unmet need for well-developed federal requirements that are specific to ranked order voting. In general, an effort is needed to provide better guidelines for vendors of ranked order voting systems. In lieu of or in addition to the development of those guidelines, there should be an process for acknowledging extensions or other enhancements to the standards, similar to the vendor-initiated innovation class. Such a process could, for example, allow a state to specify extensions that could then become testable at the federal level.

7.7.2.4 Logic for reconciling write-in double votes

Reconciliation of double votes means handling the case where, in an N-of-M contest, a voter has attempted to cast multiple votes for the same candidate using the write-in mechanism. If the voter has selected a ballot position for a given candidate but also written in that candidate's name, or if the voter has written in the same candidate twice using the same spelling or different legal spellings, some corrective action is required—possibly counting only one of the votes, possibly considering the contest to be overvoted. Which action should be specified by jurisdiction election law.

Given a sufficiently robust mechanism for reconciliation of aliases, the reconciliation of double votes can be automated. Once it is known that the name written in identifies the same candidate as the previous ballot position, the tabulator can take whatever action is specified by election law.

These Guidelines do not specify any particular approach to reconciling double votes, but the approach(es) supported are required to be described in the Voting Equipment User Documentation. See Requirement Part 2: 4.4.4-C.

 

1 Comments

Comment by Carolyn Coggins (Voting System Test Laboratory)

Define testable pass/fail criteria for this functionality

7.7.2.5 Logic for ranked order voting

The 1-of-M case of ranked order voting, known by various names including instant runoff voting, requires the definition of criteria for breaking ties. Whereas in plurality voting the voting system need only report the vote totals, a voting system supporting ranked order voting must implement tie-breaking logic in order to be certain of reaching a reportable result.

It is also necessary to decide whether voters may assign equal rankings to two contest choices, whether voters are required to rank every choice, and how to compute a result in the case where they do not.

The N-of-M generalization, called single transferable vote, has two additional adjustable parameters: the vote quota (the number of votes required to declare a candidate elected) and the weighting or distribution of votes transferred from contest choices that exceed the quota.

Finally, to the extent that a particular ranked order variant defines certain voter responses to be partly or wholly invalid, the manner in which the votes from the affected ballots are to be accounted for and reported (analogous to the reporting of overvotes in plurality contents) must be decided.

Ranked order voting has had insufficient use in the United States to establish clear precedent on how these questions are to be answered; consequently, it would be premature to standardize any particular algorithm or set of algorithms, or attempt to accommodate every possible interpretation.

 

7.7.3 Ballot separation

See also Part 1: 3.2.2.2 "Non-Editable interfaces" and Requirement Part 1: 6.3.3-A.

 
7.7.3-A Central paper tabulator, ballot separation

In response to designated conditions, paper-based central tabulators SHALL (a) outstack the ballot (i.e., divert to a stack separate from the ballots that were normally processed), (b) stop the ballot reader and display a message prompting the election official or designee to remove the ballot, or (c) mark the ballot with an identifying mark to facilitate its later identification.

Applies To: Central tabulator Λ Paper-based device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.3.2.5.1.2

 
7.7.3-A.1 Central paper tabulator, unreadable ballots

All paper-based central tabulators SHALL perform this action in response to an unreadable ballot.

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.3.2.5.1.2

 
7.7.3-A.2 Central paper tabulator, write-ins

Paper-based central tabulators of the review-required ballots device class SHALL be able to perform this action in response to a ballot containing write-in votes.

Applies To: Central tabulator Λ Paper-based device Λ Review-required ballots device

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

The requirement to separate ballots containing write-in votes is not applicable in systems in which an EBM encodes write-in votes in machine-readable form and an optical scanner generates individual tallies for all written-in candidates automatically. Separation of ballots containing write-in votes is only necessary in systems that require the allocation of write-in votes to specific candidates to be performed manually. Such systems do not conform to the write-ins class. See Part 1: 2.5.3.1 "Supported voting variations (system-level)".

Source: [VSS2002] I.3.2.5.1.2

 
7.7.3-A.3 Central paper tabulator, overvotes, undervotes, blank ballots

All paper-based central tabulators SHALL provide a capability that can be activated by central election officials to perform this action in response to ballots containing overvotes, blank ballots, and ballots containing undervotes in a designated race.

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.3.2.5.1.2

 
7.7.3-B Precinct paper tabulator, write-ins

Paper-based precinct tabulators of the review-required ballots device class SHALL have the capability, when presented with a ballot containing a write-in vote, to segregate the ballot or mark the ballot with an identifying mark to facilitate its later identification.

Applies To: Precinct tabulator Λ Paper-based device Λ Review-required ballots device

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

The requirement to separate ballots containing write-in votes is not applicable in systems in which an EBM encodes write-in votes in machine-readable form and an optical scanner generates individual tallies for all written-in candidates automatically. Separation of ballots containing write-in votes is only necessary in systems that require the allocation of write-in votes to specific candidates to be performed manually. Such systems do not conform to the write-ins class. See Part 1: 2.5.3.1 "Supported voting variations (system-level)".

Source: [VSS2002] I.3.2.5.1.3.b

 
7.7.3-C ECOS, react to marginal marks and overvotes

ECOS SHOULD provide a capability to alert an election official when a ballot that is scanned appears to contain marginal marks or overvotes.

Applies To: ECOS

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

If an EMPB appears to contain marginal marks or overvotes, either the EBM is broken or the scanner is broken. Either way, an election official should be notified immediately. (It is possible that the voter simply disregarded instructions and marked the ballot manually.)

Source: New requirement

 

7.7.4 Misfed ballots

7.7.4-A Paper-based tabulator, ability to clear misfeed

If multiple feed or misfeed (jamming) occurs, a paper-based tabulator SHALL halt in a manner that permits the operator to remove the ballot(s) causing the error and reinsert them in the input hopper (if unread) or insert them in the ballot box (if read).

Applies To: Paper-based device Λ Tabulator

Test Reference: Part 3: 4.3 "Verification of Design Requirements", 5.2 "Functional Testing"

DISCUSSION

See also Requirement Part 1: 7.7.4-B and Part 1 Section 7.7.7.

Source: [VSS2002] I.3.2.5.1.4.a, expanded to include jamming and ballots that were read

 
7.7.4-B Paper-based tabulator, indicate status of misfed ballot

If multiple feed or misfeed (jamming) occurs, a paper-based tabulator SHALL clearly indicate whether or not the ballot(s) causing the error have been read.

Applies To: Paper-based device Λ Tabulator

Test Reference: Part 3: 4.3 "Verification of Design Requirements", 5.2 "Functional Testing"

DISCUSSION

A similar issue arises with DREs that hang just as the voter presses the "cast ballot" button. See Requirement Part 1: 3.2.2.1-F. See also Requirement Part 1: 7.7.4-A and Part 1: 7.7.7 "Procedures required for correct system functioning".

Source: [MS05] 14.2.5.3 (page 46)

 

7.7.5 Accuracy

Requirement Part 1: 6.3.2-B applies to all voting systems and need not be repeated here. The following requirements elaborate the general requirement with respect to issues that are unique to paper-based systems.

 
7.7.5-A Optical scanner, ignore unmarked voting targets

Optical scanners SHALL ignore (i.e., not record as votes) unmarked voting targets to the satisfaction of Requirement Part 1: 6.3.2-B.

Applies To: Optical scanner

Test Reference: Part 3: 5.3.3 "Reliability"

DISCUSSION

"Unmarked" in this requirement means containing no marks of any kind other than those designed to be present as part of the ballot style. This includes extraneous perforations, smudges, folds, and blemishes in the ballot stock. See Requirement Part 1: 7.7.5-E, Requirement Part 1: 7.7.5-F and Requirement Part 1: 7.7.5-G.

Source: [VSS2002] I.3.2.5.2, "Recognize vote punches or marks, or the absence thereof"

 
7.7.5-B ECOS, accurately detect marks

ECOS SHALL detect EBM-generated vote indications to the satisfaction of Requirement Part 1: 6.3.2-B.

Applies To: ECOS

Test Reference: Part 3: 5.3.3 "Reliability"

DISCUSSION

Reading of marginal marks should be a non-issue if EBMs are used.

Source: Narrowed from [VSS2002] I.3.2.5.2.a and I.3.2.6.1.1

 
7.7.5-C MCOS, accurately detect perfect marks

MCOS SHALL detect marks that conform to manufacturer specifications to the satisfaction of Requirement Part 1: 6.3.2-B.

Applies To: MCOS

Test Reference: Part 3: 5.3.3 "Reliability"

Source: [VSS2002] I.3.2.5.2.a and I.3.2.6.1.1

 
7.7.5-D MCOS, accurately detect imperfect marks

MCOS SHALL detect a 1 mm thick line that is made with a #2 pencil that crosses the entirety of the voting target on its long axis, that is centered on the voting target, and that is as dark as can practically be made with a #2 pencil, to the satisfaction of Requirement Part 1: 6.3.2-B.

Applies To: MCOS

Test Reference: Part 3: 5.3.3 "Reliability"

DISCUSSION

Different optical scanning technologies will register imperfect marks in different ways. Variables include the size, shape, orientation, and darkness of the mark; the location of the mark within the voting target; the wavelength of light used by the scanner; the size and shape of the scanner's aperture; the color of the ink; the sensed background-white and maximum-dark levels; and of course the calibration of the scanner. The mark specified in this requirement is intended to be less than 100 % perfect, but reliably detectable, i.e., not so marginal as to bring the uncontrolled variables to the forefront. In plain language: scanning technologies may vary, but as a minimum requirement, all of them should be capable of reliably reading this mark.

Source: Many issues and public comments. Specification of mark originated with recommendation in Issue #1322, changed to reduce ambiguity.

 
7.7.5-E Paper-based tabulators, ignore extraneous outside voting targets

Paper-based tabulators SHALL NOT record as votes any marks, perforations, smudges, or folds appearing outside the boundaries of voting targets.

Applies To: Paper-based device Λ Tabulator

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

In previous iterations of these VVSG it was unclear whether "extraneous perforations, smudges, and folds" included perforations, smudges and folds appearing within voting targets. Those appearing within voting targets are now discussed in Requirement Part 1: 7.7.5-F and Requirement Part 1: 7.7.5-G. Those other requirements are "should" not "shall"—technology in wide use as of 2006 cannot reliably distinguish extraneous marks within voting targets from deliberate marks.

Marks that conflict with timing marks may cause a tabulator to reject a ballot. This is conforming behavior, as it does not result in the recording of bogus votes.

Source: Clarified from [VSS2002] I.3.2.5.2.b

 
7.7.5-F Optical scanner, ignore extraneous inside voting targets

Optical scanners SHOULD NOT record as votes imperfections in the ballot stock and similar insignificant marks appearing inside voting targets.

Applies To: Optical scanner

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

With technology that is in wide use as of 2006, insignificant marks appearing inside voting targets can be detected as votes. This problem should be minimized.

Source: Clarified from [VSS2002] I.3.2.5.2.b

7.7.5-G MCOS, ignore hesitation marks

MCOS SHOULD NOT record as votes hesitation marks and similar insignificant marks.

Applies To: MCOS

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

With technology that is in wide use as of 2006, it may be possible to reliably detect reasonable marks and reliably ignore hesitation marks if the scanner is calibrated to a specific marking utensil. Unfortunately, in practice, optical scanners are required to tolerate the variations caused by the use of unapproved marking utensils. Thus, lighter marks of a significant size are detected at the cost of possibly detecting especially dark hesitation marks. Emerging technologies for context-sensitive ballot scanning may solve this problem. It is also solvable through procedures that ensure that all voters use only the approved marking utensil.

Source: Clarified from [VSS2002] I.3.2.5.2.b

 

7.7.5.1 Marginal marks

A marginal mark is a mark within a voting target that does not conform to manufacturer specifications for a reliably detectable vote. The word "marginal" refers to the limit of what is detectable by an optical scanner, not the margin of the page. Marks that are outside of voting targets are called extraneous marks.

A marginal mark is neither clearly countable as a vote nor clearly countable as a non-vote. It is an ambiguous vote, analogous to dimpled chad on a punchcard.

The voter should always be instructed to make an ideal mark, which in a typical optical scan system means completely filling the oval with a #2 pencil. To allow for variations in the marks that diligent voters actually make when trying to follow this instruction, the accidental use of non-approved marking utensils, et cetera, optical scanners are configured to accept a relatively wide range of marks as votes (Requirement Part 1: 7.7.5-D). Marginal marks are below this range. They happen when voters do not follow instructions or the instructions are inadequate.

Although the criteria are not necessarily simple, manufacturers are required to specify what constitutes a reliably detectable mark versus a marginal mark (Requirement Part 2: 4.1.2-A.2). If this cannot be accomplished, then the voting system is counting votes using a mystery algorithm. Such a system cannot be found compliant.

A ballot that was marked with an EBM should never contain marginal marks. If it does, an equipment malfunction has occurred, and it should be handled as such (Requirement Part 1: 7.7.3-C).

In the case of precinct counting of manually-marked paper ballots, the precinct count scanner should be configured to reject ballots containing marginal marks (Requirement Part 1: 3.2.2.2-E). For example, a hypothetical optical scanner that detected marks based only on overall darkness could be configured so that a mark that was more than (30 ± 2) % dark would count as a vote, a mark that was less than (10 ± 2) % dark would count as a non-vote, and anything in between would be rejected as marginal. (These numbers are just examples to clarify the general intent, and are not necessarily fit for use in an any given election.)

The uncertainty at both ends of the marginal zone is of no consequence. A mark that was exactly 30 % dark would either be accepted as a vote or rejected as marginal and returned to the voter for clarification. Either way, it would not be mistaken for a non-vote. Similarly, a mark that was exactly 10 % dark would either be accepted as a non-vote or rejected as marginal and returned to the voter for clarification. Either way, it would not be mistaken for a vote. (Detectable marks in the lower range are typically hesitation marks, accidental smudges, or damage to the paper.)

In the central count case, rejection of marginal marks is only helpful if someone is going to examine each affected ballot and judge the intent of the voter. If this is not going to occur, then it is preferable to disable the detection of marginal marks so that every mark is counted either as a vote or as a non-vote. Unfortunately, it is not technically possible to do this without creating the potential for irreproducible tabulation results. For example, if a hypothetical optical scanner that detected marks based only on overall darkness were calibrated to distinguish votes from non-votes using a threshold of (25 ± 2) % darkness, the detection of marks that were between 23 % and 27 % dark would not reproduce on a different scanner of the same kind. Moreover, the detection of marks that happened to fall very close to the actual detection threshold of the scanner as calibrated would not repeat on the same scanner. As the darkness of a mark (or whatever the scanner is measuring) approaches the detection threshold, the signal-to-noise ratio approaches zero. At some point, the noise determines the result that is tabulated.

Short of banning the use of manually-marked paper ballots, which would create a crisis for absentee voting, the best that can be done for this central count case is to prohibit bias in the detection of marginal marks (Requirement Part 1: 7.7.5.1-A) and advise that the detection of marginal marks be made as repeatable as possible (Requirement Part 1: 7.7.5.1-B).

 

2 Comments

Comment by E Smith/J Homewood (Manufacturer)

Comment There shall NOT be a bias, the not was left out.

Comment by E Smith/J Homewood (Manufacturer)

This says that detection of marginal marks should be repeatable and yet in the previous page it notes that marks near the edge of the marginal limits may or may not read. This should be changed to account for this condition.
7.7.5.1-A MCOS, marginal marks, no bias

The detection of marginal marks from manually-marked paper ballots SHALL show a bias.

Applies To: MCOS

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

Bias errors are not permissible in any system ([GPO90] 7.3.3.3). An example of bias would be if marginal marks in the first ballot position were detected differently than marginal marks in the second ballot position.

Source: New requirement

 

1 Comment

Comment by Kevin Wilson (Voting System Test Laboratory)

The detection … SHALL not show a bias, instead of SHALL show a bias?
7.7.5.1-B MCOS, marginal marks, repeatability

The detection of marginal marks from manually-marked paper ballots SHOULD be repeatable.

Applies To: MCOS

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

It is difficult to have confidence in the equipment if consecutive readings of the same ballots on the same equipment yield dramatically different results. However, it is technically impossible to achieve repeatable reading of ballots containing marks that fall precisely on the sensing threshold. See Part 1: 7.7.5.1 "Marginal marks".

Source: New requirement

 

7.7.6 Consolidation

7.7.6-A Precinct EMS consolidation

Precinct EMSs SHALL consolidate the data contained in each unit into a single report for the polling place when more than one vote-capture device or precinct tabulator is used.

Applies To: Precinct tabulator Λ EMS

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

For requirements on report content see Part 1: 7.8 "Reporting".

Source: Reworded from [VSS2002] I.2.5.3.2

 
7.7.6-A.1 DRE, consolidate in 5 minutes

DREs SHALL, if the consolidation of polling place data is done locally, perform this consolidation in a time not to exceed 5 minutes per DRE.

Applies To: Precinct tabulator Λ EMS Λ DRE

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

This requirement assumes that the precinct is operating using DREs exclusively and that one of those DREs fills the role of EMS.

Source: Reworded from [VSS2002] I.3.2.6.2.1

 

7.7.7 Procedures required for correct system functioning

The requirements for voting systems are written assuming that these procedures will be followed.

Paper-based tabulator, clearing misfeeds when ballot was read: If it is necessary to clear a misfed ballot that was read by a paper-based tabulator but became stuck on its way to the ballot box, election judges or central election officials must perform this task in the presence of a witness. If an audit found that the contents of the ballot box and the records from the tabulator did not match, one would want to be able to rule out the possibility that something made its way into the ballot box while the tabulator was disconnected.

 

7.8 Reporting

Although reporting is typically an EMS function, most of the requirements in this section are scoped to the entire system because any given EMS might not generate all of the specified information. For example, the precinct- and system extent-level reports might be generated by different EMSs located in the precinct and central location, respectively. The precinct EMSs need not have the capability to generate system extent-level reports and vice-versa.

 

7.8.1 General reporting functionality

7.8.1-A Reports are time stamped

All reports SHALL include the date and time of the report's generation, including hours, minutes, and seconds.

Applies To: Voting system

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

Even if the clock's accuracy leaves something to be desired, second precision is useful to have if two reports are generated in quick succession.

Source: New requirement

 
7.8.1-B Timestamps should be ISO 8601 compliant

Timestamps in reports SHOULD comply with ISO 8601 [ISO04], provide all four digits of the year and include the time zone.

Applies To: Voting system

Test Reference: Part 3: 5.2 "Functional Testing"

Source: New requirement

 
7.8.1-C Reporting is non-destructive

All programmed devices SHALL prevent data, including data in transportable memory, from being altered or destroyed by report generation.

Applies To: Programmed device

Test Reference: Part 3: 4.3 "Verification of Design Requirements"

DISCUSSION

The appending of an audit record reflecting the fact that a report has been generated is not considered an alteration.

Source: From [VSS2002] I.2.2.6.h, I.2.5.3.1.g, and I.2.5.3.2.d

 

7.8.2 Audit, status, and readiness reports

7.8.2-A Audit reports

All systems SHALL be capable of producing reports of the event logs defined in Part 1: 5.7 "System Event Logging".

Applies To: Voting system

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.2.6.i and I.2.5.3.1.f

 
7.8.2-B Pre-election reports

The EMS SHALL provide the capability to obtain a report that includes:

  1. The allowable number of votes in each contest;
  2. The combinations of voting patterns permitted or required by the jurisdiction;
  3. The inclusion or exclusion of contests as the result of multiple districting within a polling place;
  4. Any other characteristics that may be peculiar to the jurisdiction, the election or the precincts;
  5. Manual data maintained by election personnel;
  6. Samples of all final ballot styles; and
  7. Ballot preparation edit listings.

Applies To: EMS

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

For the logging of auditable events during election programming see Part 1: 5.7 "System Event Logging".

Source: [VSS2002] I.4.4.1 / [VVSG2005] I.5.4.1

 

1 Comment

Comment by Premier Election Solutions (Manufacturer)

Item (d) is not testable since it is undefined. Proposed Change: Remove item (d) from this requirement.
7.8.2-C Status reports

All programmed devices SHALL provide the capabilities to obtain status and equipment readiness reports.

Applies To: Programmed device

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

These reports typically are generated during pre-voting logic and accuracy testing; see Part 1: 7.3.1 "Logic and accuracy testing".

Source: Reworded from [VSS2002] I.2.3.4.1.b

 
7.8.2-D Readiness reports, per polling place

Readiness reports SHALL include at least the following information for each polling place:

  1. The election's identification data;
  2. The identification of the precinct and polling place;
  3. The identification of all voting devices deployed in the precinct;
  4. The identification of all ballot styles used in that precinct;
  5. Confirmation that no hardware or software failures were detected during setup and testing, or a record of those that occurred; and
  6. Confirmation that all vote-capture devices are ready for the opening of polls, or identification of those that are not.

Applies To: In-person voting

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

In jurisdictions where there are no programmed devices in the precincts, confirmation of equipment readiness could occur through a manual check and signoff by election judges. These readiness reports could take the form of checklists, fill-in forms and signature sheets supplied to the precincts by a central authority.

Source: [VSS2002] I.2.3.5, separated generic precinct vs. precinct tabulator reqs, modified to deal with failures

 
7.8.2-E Readiness reports, precinct tabulator

Readiness reports SHALL include the following information for each precinct tabulator:

  1. The election's identification data;
  2. The identification of the precinct and polling place;
  3. The identification of the tabulator;
  4. The contents of each active contest choice register at all storage locations;
  5. Confirmation that no hardware or software failures were detected during setup and testing, or a record of those that occurred; and
  6. Any other information needed to confirm the readiness of the equipment and to accommodate administrative reporting requirements.

Applies To: Precinct tabulator

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.3.5, separated generic precinct vs. precinct tabulator reqs, harmonized with Requirement Part 1: 7.8.2-F, modified to deal with failures, deleted "special voting options"

 
7.8.2-F Readiness reports, central tabulator

Readiness reports SHALL include the following information for each central tabulator:

  1. The election's identification data;
  2. The identification of the tabulator;
  3. The identification of all ballot styles used in the system extent;
  4. The contents of each active contest choice register at all storage locations;
  5. Confirmation that no hardware or software failures were detected during setup and testing, or a record of those that occurred; and
  6. Any other information needed to confirm the readiness of the equipment and to accommodate administrative reporting requirements.

Applies To: Central tabulator

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.2.3.6, harmonized with Requirement Part 1: 7.8.2-E, modified to deal with failures, deleted "special voting options"

 
7.8.2-G Readiness reports, public network test ballots

Systems that send ballots over a public network SHALL provide a report of test ballots that includes:

  1. The number of test ballots sent;
  2. When each test ballot was sent;
  3. The identity of the machine from which each test ballot was sent; and
  4. The specific votes contained in the test ballots.

Applies To: Voting system

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.4.4.2.g / [VVSG2005] I.5.4.2.g

 

7.8.3 Vote data reports

The requirements in this section specify a minimum set of information that a voting system must report. They do not prohibit any voting system from reporting additional information that may be required by jurisdictions or merely found to be useful.

Similarly, the identification of four "standard" reporting contexts (tabulator, precinct, election district, and system extent) requires voting systems to support these at a minimum, but does not prohibit any voting system from supporting additional reporting contexts or from offering a generalized facility through which central election officials may define arbitrary reporting contexts.

 

7.8.3.1 General functionality

7.8.3.1-A Reporting, ability to produce text

All devices used to produce reports of the vote count SHALL be capable of producing:

  1. Alphanumeric headers;
  2. Election, office and issue labels; and
  3. Alphanumeric entries generated as part of the audit record.

Applies To: Voting system

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [VSS2002] I.3.2.7.2 / [VVSG2005] I.4.1.7.2

 
7.8.3.1-B Report all votes cast

All systems SHALL be able to produce an accurate, human-readable report of all votes cast.

Applies To: Voting system

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

Binary document formats and text containing markup tags are not considered human-readable. The system may generate such documents, but it must also provide the functionality to render those documents in human-readable form (e.g., by including the necessary reader application).

Source: [VSS2002] I.2.2.2.1.c as expanded by [P1583] 5.2.1.1.c[5]

 
7.8.3.1-C Account for all cast ballots and all valid votes

All systems SHALL produce vote data reports that account for all cast ballots and all valid votes.

Applies To: Voting system

Test Reference: Part 3: 4.6 "Logic Verification", 5.2 "Functional Testing"

 
7.8.3.1-D Vote data reports, discrepancies can't happen

Vote data reports SHALL be completely consistent, with no discrepancy among reports of voting device data at any level.

Applies To: Voting system

Test Reference: Part 3: 4.6 "Logic Verification", 5.2 "Functional Testing"

Source: Reworded from [VSS2002] I.3.2.6.2.2, extended to all systems

 
7.8.3.1-D.1 Discrepancies that happen anyway must be flagged

Any discrepancy that is detectable by the system SHALL be flagged by the system by an annotation or error message in the affected report(s) and/or a separate discrepancy report.

Test Reference: Part 3: 4.6 "Logic Verification", 5.2 "Functional Testing"

DISCUSSION

If this requirement is applicable, then the system has failed to satisfy Requirement Part 1: 7.8.3.1-D and is therefore non-conforming. Nevertheless, in practice it is essential that discrepancies be flagged by the system as much as possible so that they are not overlooked by election judges. The system cannot detect discrepancies if no single voting device is ever in possession of a sufficient set of data.

Source: New requirement in response to Issue #1366

 
7.8.3.1-D.2 Discrepancies that happen anyway must be explainable

Any discrepancy in reports, regardless of source, SHALL be resolvable to a specific cause.

Test Reference: Part 3: 4.6 "Logic Verification", 5.2 "Functional Testing"

DISCUSSION

If this requirement is applicable, then the system has failed to satisfy Requirement Part 1 :7.8.3.1-D and is therefore non-conforming. Nevertheless, in practice it is essential that a specific cause be determinable.

Source: Reworded and generalized from [VSS2002] I.3.2.6.2.2

 
7.8.3.1-E Reporting, combined precincts

All systems SHOULD be capable of generating reports that consolidate vote data from selected precincts.

Applies To: Voting system

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

Jurisdictions in which more than one precinct may vote at the same location on either the same ballot style or a different ballot style may desire reports that consolidate the voting location.

Source: Derived from [ND06] 5.04.05.g, [UT04] Requirement 23 and [MS05] 14.3.2.3

 

1 Comment

Comment by Gail Audette (Voting System Test Laboratory)

This requirement states that discrepancies SHALL not occur but the next two requirements (D.1 and D.2) are requriements for when discrepancies occur. Please clarify how/why a non-conforming system is released for use and the election judges then need this information.
7.8.3.1-F Precinct tabulators, no tallies before close of polls

Precinct tabulators SHALL prevent the printing of vote data reports and the extraction of vote tally data prior to the official close of polls.

Applies To: Precinct tabulator

Test Reference: Part 3:4.5.2 "Security", 5.4 "Open-Ended Vulnerability Testing"

DISCUSSION

Providing ballot counts does not violate this requirement. The prohibition is against providing vote totals. Ballot counts are required for ballot accounting, but early extraction of vote totals is an enabler of election fraud.

Source: Revised from [VSS2002] I.2.5.3.2

 

7.8.3.2 Ballot counts

Source for Requirement Part 1: 7.8.3.3-A through Requirement Part 1: 7.8.3.3-I: These requirements were distilled, refactored, and clarified from overlapping, subtly differing requirements appearing several places in Chapters 2 and 4 of [VSS2002], including: I.2.2.2.1.c (produce an accurate report of all votes cast), I.2.2.6.h (printed report of everything in I.2.5), I.2.2.9 (ballot counter), I.2.5.2 (means to consolidate vote data), I.2.5.3.1.a (geographic reporting), I.2.5.3.1.b (printed report of number of ballots counted by each tabulator), I.2.5.3.1.c (contest results, overvotes, and undervotes for each tabulator), I.2.5.3.1.d (consolidated reports including other data sources), I.4.4.4.a (number of ballots cast, using each ballot configuration, by tabulator, precinct, and political subdivision), I.4.4.4.b (candidate and measure totals for each contest, by tabulator), I.4.4.4.c (number of ballots read within each precinct and for additional jurisdictional levels, by configuration, including separate totals for each party in primary elections), I.4.4.4.d (separate accumulation of overvotes and undervotes for each contest, by tabulator, precinct, and additional jurisdictional levels), and I.4.4.4.e (for paper-based systems, the total number of ballots both processed and unprocessable, and the total number of cards read).

 
7.8.3.2-A Report cast ballots

All voting systems SHALL report the number of cast ballots in the precinct, election district, and system extent reporting contexts, both in total and broken down by ballot configuration.

Applies To: Voting system

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

In the case of 100 % DRE systems, it would suffice to provide a single total that is noted to represent both the number of cast ballots and the number of read ballots, since these are necessarily equal. Only when there is a tangible (i.e., paper) ballot is it possible to cast a ballot that is never read. There is no subrequirement for separate reporting of provisional cast ballots because the system is unlikely to know whether a ballot is provisional until it is successfully read.

 

2 Comments

Comment by Robert Ferraro, SAVEourVotes.org (Advocacy Group)

There should be a new, separate, almost opposite requirement that all systems which may be used for centrally counting ballots should be able to generate reports that separate counts and subtotals by batch. In particular, central count optical-scan machines should be able to subtotal and store results for batches of ballots. This feature is especially important for many states where absentee ballots and provisional ballots make up a large fraction of the total. The cost of an audit depends on several factors, including the number of samples needed. The number of samples needed (and thereby the cost) can be reduced by having smaller audit units. With centrally based optical-scan systems for absentee ballots, it is more cost effective to group the ballots into batches and then consider each batch as a separate audit unit than to consider all the ballots together in one audit unit. Although batching centrally counted ballots can drastically reduce audit costs, some current systems do not support such batching.

Comment by Verified Voting Foundation (Advocacy Group)

There should be a new, separate requirement that all systems which may be used for centrally counting ballots should be able to generate reports that separate counts and subtotals by batch. In particular, central count optical-scan machines should be able to subtotal and store results for batches of ballots. This feature is especially important for many states where absentee ballots and provisional ballots make up a large fraction of the total. The cost of an audit depends on several factors, including the number of samples needed. The number of samples needed (and thereby the cost) can be reduced by having smaller audit units. With centrally based optical-scan systems for absentee ballots, it is more cost effective to group the ballots into batches and then consider each batch as a separate audit unit than to consider all the ballots together in one audit unit. Although batching centrally counted ballots can drastically reduce audit costs, some current systems do not support such batching or make it difficult to keep track of batch sub-totals.
7.8.3.2-B Report read ballots

All systems SHALL report the number of read ballots in each reporting context (tabulator, precinct, election district, and system extent), both in total and broken down by ballot configuration.

Applies To: Voting system

Test Reference: Part 3: 4.6 "Logic Verification", 5.2 "Functional Testing"

 
7.8.3.2-B.1 Report read ballots, multi-page

Systems that include paper-based devices SHALL, if there are multiple card/page ballots, report the number of cards/pages read in each reporting context (tabulator, precinct, election district, and system extent), both in total and broken down by ballot configuration.

 
7.8.3.2-B.2 Report read ballots by party

Systems conforming to the primary elections class SHALL report separate totals for each party in primary elections.

Applies To: Primary elections

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

This requirement to report by party applies only to the number of read ballots. It does not apply to contest choice vote totals.

 
7.8.3.2-B.3 Report read provisional ballots

Systems conforming to the provisional-challenged ballots class SHALL report the number of provisional-challenged read ballots in each reporting context (tabulator, precinct, election district, and system extent), both in total and broken down by ballot configuration.

Applies To: Provisional-challenged ballots

Test Reference: Part 3: 5.2 "Functional Testing"

 

1 Comment

Comment by George Gilbert (Local Election Official)

7.8.3.2-A—In the case of DRE systems, it would be desirable, and feasible, to report the number of "provisional" ballots cast in each category. Provisional ballots cast on a DRE machine would be identifiable, without reading the ballot, by the "credentials" provided by the activating "token." A readily available report of the number of such ballots would be extremely useful to election administrators and likely highly desirable by the candidates.
7.8.3.2-C Report counted ballots

All systems SHALL report the number of counted ballots in each reporting context (tabulator, precinct, election district, and system extent), both in total and broken down by ballot configuration.

Applies To: Voting system

Test Reference: Part 3: 4.6 "Logic Verification", 5.2 "Functional Testing"

DISCUSSION

See also Requirement Part 1: 7.8.3.2-D, which breaks down counted ballots by contest.

 
7.8.3.2-C.1 Report counted ballots by party

Systems conforming to the primary elections class SHALL report separate ballot counts for each party in primary elections.

Applies To: Primary elections

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

This requirement to report by party applies only to the number of counted ballots. It does not apply to contest choice vote totals.

 
7.8.3.2-C.2 Report counted provisional ballots

Systems conforming to the provisional-challenged ballots class SHALL report the number of provisional-challenged counted ballots in each reporting context (tabulator, precinct, election district, and system extent), both in total and broken down by ballot configuration.

Applies To: Provisional-challenged ballots

Test Reference: Part 3: 5.2 "Functional Testing"

 
7.8.3.2-C.3 Report blank ballots

All systems SHOULD report the number of blank ballots (ballots containing no votes) that were counted in each reporting context (tabulator, precinct, election district, and system extent), both in total and broken down by ballot configuration.

Applies To: Part 3: 5.2 "Functional Testing"

DISCUSSION

Some jurisdictions find this information to be useful. Blank ballots sometimes represent a protest vote.

 
7.8.3.2-D Report counted ballots by contest

All systems SHALL report the number of counted ballots for each relevant N-of-M or cumulative voting contest, in each reporting context (tabulator, precinct, election district, and system extent), per the definition of K(j,r,tE) in Part 1: Table 8-2.

Applies To: Voting system

Test Reference: Part 3: 4.6 "Logic Verification", 5.2 "Functional Testing"

DISCUSSION

See definition of relevant contest in Appendix A.

This is by contest, while Requirement Part 1: 7.8.3.2-C is the overall count. The count by contest could be inferred from the other counts that are broken down by ballot configuration, but providing this figure explicitly will make it easier to account for every vote per Part 1: 8.3.3 "Cumulative voting".

N-of-M in this requirement includes the most common type of contest, 1-of-M.

 

7.8.3.3 Vote totals

For the source of these requirements, please see the note in Part 1: 7.8.3.2 "Ballot counts".

 
7.8.3.3-A Report votes for each contest choice

All systems SHALL report the vote totals for each contest choice in each relevant N-of-M or cumulative voting contest, in each reporting context (tabulator, precinct, election district, and system extent), per the definition of T(c,j,r,tE) in Part 1: Table 8-2 and Part 1: 8.3.3 "Cumulative voting".

Applies To: Voting system

Test Reference: Part 3: 4.6 "Logic Verification", 5.2 "Functional Testing"

DISCUSSION

See definition of relevant contest in Appendix A.

N-of-M in this requirement includes the most common type of contest, 1-of-M.

 
7.8.3.3-B Report overvotes for each contest

All systems SHALL report the number of overvotes for each relevant N-of-M or cumulative voting contest, in each reporting context (tabulator, precinct, election district, and system extent), per the definition of O(j,r,tE) in Part 1: Table 8-2 and Part 1: 8.3.3 "Cumulative voting".

Applies To: Voting system

Test Reference: Part 3: 4.6 "Logic Verification", 5.2 "Functional Testing"

DISCUSSION

See definition of relevant contest in Appendix A.

N-of-M in this requirement includes the most common type of contest, 1-of-M.

[VSS2002] required the reporting of overvotes even on 100 % DRE systems where overvoting is prevented (Requirement Part 1: 3.2.2.1-A); that requirement is retained here, though it may be redundant.

Overvotes are defined in Part 1: 8.3 "Logic Model (normative)". Consistent with the definition of undervotes (see Requirement Part 1: 7.8.3.3-C), the count is of votes lost to overvoting, not of ballots containing overvotes. This means that a ballot that overvotes an N-of-M contest would contribute N to the count of overvotes for that contest.

 
7.8.3.3-B.1 Reporting overvotes, ad hoc queries

All systems SHALL be capable of producing a consolidated report of the combination of overvotes for any contest that is selected by an authorized official (e.g., the number of overvotes in a given contest combining candidate A and candidate B, combining candidate A and candidate C, etc.).

Test Reference: Part 3: 5.2 "Functional Testing"

Source: From [VSS2002] I.2.2.6.h and I.2.5.3.1.e

 

1 Comment

Comment by Premier Election Solutions (Manufacturer)

Overvotes can only occur with manually marked paper ballots and, in a precinct count environment, only if those overvotes are over-ridden when the ballot is cast. In all cases, overvoted contests are not counted and are considered blank contests. It seems arbitrary that the system SHALL be required to be capable of producing reports of this nature. This requirement seeks to capture overvote data that has no bearing on tallies or audits and is redundant information, unless the intent is to gather data to make anecdotal references to any patterns that might be exhibited in the data. Otherwise the data is of no use. If this requirement is for no valuable purpose, then it should be changed from a SHALL to a SHOULD. Proposed Change: Change this requirement from a SHALL to a SHOULD. Otherwise please provide discussion in the VVSG as to the value of this data.
7.8.3.3-C Report undervotes for each contest

All systems SHALL report the number of undervotes for each relevant N-of-M or cumulative voting contest, in each reporting context (tabulator, precinct, election district, and system extent), per the definition of U(j,r,tE) in Part 1: Table 8-2 and Part 1: 8.3.3 "Cumulative voting".

Applies To: Voting system

Test Reference: Part 3: 4.6 "Logic Verification", 5.2 "Functional Testing"

DISCUSSION

See definition of relevant contest in Appendix A.

N-of-M in this requirement includes the most common type of contest, 1-of-M.

Undervotes are defined in Part 1: 8.3 "Logic Model (normative)" as needed to enable accounting for every vote. Counting ballots containing undervotes instead of votes lost to undervoting is insufficient.

 
7.8.3.3-D Ranked order voting, report results

Systems conforming to the ranked order voting class SHALL report the contest choice vote totals for each ranked order contest for each round of voting/counting at the system extent level.

Applies To: Ranked order voting

Test Reference: Part 3: 5.2 "Functional Testing"

DISCUSSION

This requirement is minimal. Since ranked order voting is not currently in wide use, it is not clear what must be reported, how bogus orderings are reported, or how it would be done in multiple reporting contexts. See Part 1: 7.7.2.5 "Logic for ranked order voting".

 

1 Comment

Comment by Terrill Bouricius, FairVote: the Center for voting and Democracy (Advocacy Group)

Eventually these guidelines should require at polling places, precinct systems should be able to report at least the number of first preferences for each contest choice. In the long term, the precinct machine should be able to print a total of each of the rankings received by each of the contest choices. This information is not useful for tallying the election, to know who won, but is a security function to allow a complete audit after the election is completed. None of the major vendors currently have this capacity, but future systems should be required to have this capability.
7.8.3.3-E Include in-person votes

Systems conforming to the in-person voting class SHALL include all votes collected from In-person voting in the consolidated reports.

Applies To: In-person voting

Test Reference: Part 3: 4.6 "Logic Verification", 5.2 "Functional Testing"

DISCUSSION

"Include" simply means that the final totals must reflect them. It does not entail separate totals for the different kinds of votes.

 

2 Comments

Comment by George Gilbert (Local Election Official)

7.8.3.3-E—The distinction between "in-person" votes and "absentee" votes is not reflective of the practices among the states. Many states classify all early votes, whether in-person or by-mail as "absentee" votes, eg. North Carolina. This, in the proposed VVSG definitions, produces significant overlap in the definitions for these terms.

Comment by Premier Election Solutions (Manufacturer)

 
7.8.3.3-F Include absentee votes

Systems conforming to the absentee voting class SHALL include all votes from absentee ballots in the consolidated reports.

Applies To: Absentee voting

Test Reference: Part 3: 4.6 "Logic Verification", 5.2 "Functional Testing"

DISCUSSION

"Include" simply means that the final totals must reflect them. It does not entail separate totals for the different kinds of votes.

 
7.8.3.3-G Include write-in votes

Systems conforming to the write-ins class SHALL include all write-in votes in the consolidated reports.

Applies To: Write-ins

Test Reference: Part 3: 4.6 "Logic Verification", 5.2 "Functional Testing"

DISCUSSION

"Include" simply means that the final totals must reflect them. It does not entail separate totals for the different kinds of votes.

 
7.8.3.3-H Include accepted provisional-challenged votes

Systems conforming to the provisional-challenged ballots class SHALL include all votes from accepted provisional/challenged ballots in the consolidated reports.

Applies To: Provisional-challenged ballots

Test Reference: Part 3: 4.6 "Logic Verification", 5.2 "Functional Testing"

DISCUSSION

"Include" simply means that the final totals must reflect them. It does not entail separate totals for the different kinds of votes. See also Requirement Part 1: 7.7.2-A.4, Requirement Part 1: 7.8.3.2-B.3 and Requirement Part 1: 7.8.3.2-C.2.

7.8.3.3-I Include accepted reviewed votes

Systems conforming to the review-required ballots class SHALL include all votes from accepted reviewed ballots in the consolidated reports.

Applies To: Review-required ballots

Test Reference: Part 3: 4.6 "Logic Verification", 5.2 "Functional Testing"

DISCUSSION

"Include" simply means that the final totals must reflect them. It does not entail separate totals for the different kinds of votes.

  

7.8.4 Procedures required for correct system functioning

The requirements for voting systems are written assuming that these procedures will be followed.

Ballot accounting: All precincts must account for all ballots pursuant to the current best practices for ballot accounting.

Label unofficial reports: Any unofficial reports must be clearly labeled as unofficial. ([VSS2002] I.2.5.4.c, converted to procedural requirement.)