Figure 2-1 Voting device classes
This chapter provides information and requirements relating to how manufacturers and test labs can use the features of this document to assess whether a voting system conforms to the VVSG. It is written with these audiences in mind; the overview information in Chapter 4 of the Introduction is written for readers with less-technical backgrounds.
Each part of the VVSG is organized into hierarchically organized sections that address topics of interest. Sections typically begin with prose explaining the general purpose, etc. This is informative background to help understand the requirements. Sections also contain requirements, which are the hard and fast rules to be followed for conformance. The VVSG carefully distinguish normative requirements from informative context using conventions that are explained below.
Each voting system requirement is identified according to a hierarchical scheme in which higher-level, "parent" requirements (such as "provide accessibility for visually impaired voters") are supported by lower-level subrequirements (e.g., "provide an audio-tactile interface"). "Parent" requirements have identifiers consisting of a section number suffixed by a letter (e.g., 1.2.3-A) and are indicated by straight arrows in the left margin. Subrequirements have identifiers consisting of their parent requirements' identifiers suffixed by a digit (e.g., 1.2.3-A.1) and are indicated by bent arrows in the left margin.
Each requirement is composed of a descriptive title, normative text, optional informative discussion, and two fields labeled Applies to: and Test reference:.
The applicability of a requirement is specified with the Applies to: field, which indicates the class(es) of voting systems or devices to which the requirement applies. Classes are defined in Part 1: 2.6 “Extensions”.
A requirement having N different classes separated by commas in its Applies to: field is equivalent to N separate requirements that repeat the same text, each repetition applying to one of the listed classes.
The scope of a parent requirement is inherited by its subrequirements unless they explicitly specify a narrower scope. The scope may be narrowed through a generic relation (e.g., DRE is a subclass of Vote-capture device) or a partitive relation (e.g., a DRE is part of a Voting system). If no narrowing is needed then the Applies to: field may be omitted.
The Test reference: field indicates the general testing approach or approaches that would be used to assess conformity with the requirement.
The following keywords are used to convey conformance requirements:
Requirements are further indicated by the presence of green text and arrows in the left margin. Requirements are directly applicable to achieving conformance to the VVSG.
Informative parts of this document include discussion, examples, extended explanations, and other matter that is necessary for proper understanding of the VVSG and conformance to them. Informative text may serve to clarify requirements, but it is not otherwise applicable to achieving conformance to the VVSG.
A voting system conforms to the product standard if all stated requirements that apply to the voting system and its constituent devices are fulfilled. The implementation statement (see Part 1: 2.4 “Implementation Statement”) declares the capabilities, features and optional functions that have been implemented and are subject to conformity assessment.
There is no concept of partial conformance—neither that a voting system is x % conforming, nor that a device that is not a complete voting system by itself is conforming. Individual devices of voting systems are not tested except as parts of complete systems. [3]
An implementation statement documents the requirements that have been implemented by the voting system, the optional features and capabilities supported by the voting system, and any extensions (i.e., additional functionality beyond what is defined in the VVSG) that it implements.
An implementation statement may take the form of a checklist to be completed for each voting system submitted for conformity assessment. It is used by test labs to identify the conformity assessment activities that are applicable.
An implementation statement SHALL include:
Test Reference: Part 3: 4.1 “Initial Review of Documentation”
DISCUSSION
This requirement addresses many issues about the scope of conformity assessment and uncertainty whether particular features have been implemented in voting systems.
A keyboard, mouse or printer connected to a programmed voting device, as well as any optical drive, hard drive or similar component installed within it, are considered components of the voting device, not separate devices. The voting device is "responsible" for these components—e.g., a DRE must prevent unauthorized flashing of the firmware in its optical drive or other components that could be subverted to manipulate vote outcomes.
Specified capacities and limits should include the limit (if any) on the length of a candidate name that the system can process and display without truncation and similar limits for any other text fields whose usable or practically usable sizes are bounded. If the system provides a way to access the entirety of a long name even when it does not fit the width of the display and does not use any data structures that would force truncation, such a limit might not apply.
Manufacturers may wish to contact their intended testing labs in advance to determine if those labs can supply them with an implementation statement pro forma to facilitate meeting this requirement.
Source: New requirement.
The following terms are defined in Appendix A: voting device, activation device, Vote-capture device, IVVR vote-capture device, paper-based device, electronic device, programmed device, tabulator, precinct tabulator, central tabulator, audit device, VEBD, Acc-VS, MMPB, EBM, VEBD-A, VEBD-V, DRE, VVPAT, optical scanner, ECOS, MCOS, PCOS, CCOS, and EMS.
A class simultaneously identifies a set of requirements and a set of voting systems or devices to which those requirements apply. The purpose of classes is to categorize requirements into related groups of functionality that apply to different types of voting systems and devices.
Classes may subsume other classes. For example, paper-based device subsumes MMPB EBM, and optical scanner. The subsuming class is called the superclass while the subsumed classes are called subclasses.
A group of related classes forms a classification lattice with a largest class at the top and a smallest class at the bottom. The largest class subsumes all other classes. For voting systems the largest class is called Voting system; for voting devices the largest class is called Voting device. The smallest class is subsumed by all other classes. In this discussion the smallest classes are unnamed and are only present to complete the formalism.
Subclasses "inherit" the requirements of their superclasses. Additionally, a subclass may further constrain a class by adding new requirements. However, a subclass is not allowed to relax or remove requirements inherited from a superclass.
There is no assumption of disjointness for classes. Unless otherwise specified, a voting system or device may belong to several classes simultaneously, such as Acc-VS and DRE to signify an accessible DRE device.
A voting system conforms to a class if all stated requirements identified by that class are fulfilled. Since subclasses are not allowed to relax or remove requirements inherited from a superclass, it is true in all cases that a voting system or device conforming to a subclass also conforms to all of its superclasses. For example, a voting system conforming to any subclass of Voting system fulfills the general requirements that apply to all voting systems.
The classification mechanism is useful in many different contexts when there is a need to identify specific portions of the VVSG. Part 1: Table 2-1 provides several examples.
Table 2-1 Use of classes in different contexts
Context |
Use |
VVSG |
Requirements applicable to a given class |
Implementation statement |
This system conforms to a specified class |
Conformity assessment |
Tests and reviews applicable to the specified class |
Certification |
Scope of certification is the specified class |
Declaration of conformity |
This product is certified to that class |
Request for proposals |
Seeking to procure a system conforming to a specified class |
Part 1: Figure 2-1 and Part 1: Figure 2-2 repeat in pictorial form the classification hierarchies that are defined in the next section to illustrate their high-level structure. A class is represented by an oval containing the name of the class. When two classes are connected by a line, this indicates that the higher class subsumes the lower one. The “subsumptions” are also described in the next section.
Figure 2-1 Voting device classes
Figure 2-2 Voting system classes
An implementation statement for a voting system SHALL identify:
Test Reference: Part 3: 4.1 “Initial Review of Documentation”, Requirement Part 3: 4.2-C
DISCUSSION
By definition, the class Voting system applies to every voting system. All voting systems are required to achieve software independence. The IVVR design is one way to accomplish this. Alternatives may be approved through the innovation class submission process.
Source: New requirement.
For each distinct device included in the system, an implementation statement for a voting system SHALL identify:
Test Reference: Part 3 Section 4.1, Requirement Part 3: 4.2-C
DISCUSSION
By definition, the class Voting device is applicable to every voting device.
Source: New requirement.
For each of the voting variationss identified per Requirement Part 1: 2.5.3-A and Requirement Part 1 :2.5.3-B, the implementation statement SHALL cite the specific section or sections of the Voting Equipment User Documentation where the use of that voting variations is documented.
Test Reference: Part 3 Section 4.1
DISCUSSION
Voting variations are enumerated in Part 1 Section 2.5.3.1“Supported voting variations (system-level)” and Part 1: 2.5.3.2 “Supported voting variations (device-level)”.
Source: New requirement.
The classes enumerated in this section identify voting variationss supported by the voting system. Although the intent of most is apparent from the applicable requirements, the following may require additional explanation.
Conformance to the Write-ins class indicates that the voting system is capable of end-to-end processing of write-in votes, including reconciliation of Write-ins (see Part I: Section 7.7.2.4 “Logic for reconciling write-in double votes”) and generation of a final, consolidated report that includes individual tallies for all write-in candidates. If the voting system requires the allocation of write-in votes to specific candidates to be performed manually, then it does not satisfy Requirement Part 1: 6.2-A and therefore does not conform to the Write-ins class. However, it may conform to the Review-required ballots class (see below).
The same principle applies to the Absentee voting class and the Provisional-challenged ballots class. If the counting of these ballots is external to the voting system, then the system does not satisfy Requirement Part 1: 6.2-A therefore does not conform to the Absentee voting or Provisional-challenged ballots class, respectively.
Conformance to the Review-required ballots class indicates that the voting system is capable of flagging or separating ballots for later processing and including the results of that processing in the reported totals. If the consolidation of counts from Review-required ballots with counts from other ballots is external to the voting system, then the system does not satisfy Requirement Part 1: 7.8.3.3-I and therefore does not conform to the Review-required ballots class.
In some systems, write-in votes are counted as anonymous ballot positions, and these votes are assigned to candidates through manual post-processing only if the election is close enough to warrant the effort. Although this approach does not conform to the Write-ins class, the system's handling of write-in positions is identical to its handling of other ballot positions, so the behavior is testable.
Choose all that apply.
The class Voting system subsumes all of the above.
It is necessary to specify voting variationss at the device level as well as the system level because a system may support a given voting variations without having that support in every device. For example, a system may support Absentee voting by having absentee ballot support in one special tabulator and in the central EMS. However, for the most part, these should agree with the variations claimed at the system level.
Choose all that apply.
The class Voting device subsumes all of the above.
The classes enumerated in this section identify different types of voting devices.
Choose all that apply.
The class Voting device subsumes all of the above. Only direct subsumptions are described above, but subsumption is transitive, so if X subsumes Y and Y subsumes Z, then X subsumes Z.
PCOS is implied if precinct tabulator and optical scanner are identified. CCOS is implied if central tabulator and optical scanner are identified.
A class simultaneously identifies a set of requirements and a set of voting systems or devices to which those requirements apply.
For a class C, let S(C) represent the set of voting systems or devices identified by C and let R(C) represent the set of requirements applicable to those voting systems or devices.
A subclass identifies a superset of the requirements and a subset of the voting systems or devices identified by its superclass. A voting system that conforms to a subclass necessarily conforms to its superclass. The superclass is said to subsume the subclass.
If class C1 subsumes C2, then
(Meaning: The set of requirements applying to C2 is a superset of the set of requirements applying to C1.)
(Meaning: The set of voting systems identified by C2 is a subset of the set of voting systems identified by C1.)
A class may have multiple superclasses. Let P(C) represent the set of superclasses of C. Then
(Meaning: The set of requirements applying to C is a superset of the union of the sets of requirements applying to each of C's superclasses.)
(Meaning: The set of voting systems identified by C is a subset of the intersection of the sets of voting systems identified by each of C's superclasses.)
Given classes C3 and C4, one may derive a new subclass by combining C3 and C4. The combining operation on classes is represented with a wedge (Λ).
(Meaning: The set of requirements applying to C3 Λ C4 is a superset of the union of the set of requirements applying to C3 and the set of requirements applying to C4.)
(Meaning: The set of voting systems identified by C3 Λ C4 is the intersection of the set of voting systems identified by C3 and the set of voting systems identified by C4.)
By default, this new subclass, C3 Λ C4, identifies the union of the requirements and the intersection of the voting systems or devices identified by C3 and C4. However, additional requirements that applied to neither superclass may apply specifically to the new subclass.
Part 1: Figure 2-3 shows an example in which a new subclass is derived from Acc-VS and VVPAT.
Figure 2-3 Device class formed by wedge (Λ)
A class that is derived by combining classes that are disjoint is said to be incoherent and identifies no voting systems or devices. The set of requirements identified by an incoherent class is likely to be self-contradictory.
Extensions are additional functions, features, and/or capabilities included in a voting system that are not defined in the VVSG. To accommodate the needs of states that may impose additional requirements and to accommodate changes in technology, these VVSG allow extensions. However, as extensions are essentially subclasses of one or more classes defined in these VVSG, they are subject to the integrity constraint that applies to all subclasses: an extension is not allowed to contradict or relax requirements that would otherwise apply to the system and its constituent devices.
Extensions SHALL NOT contradict or relax requirements of these VVSG.
This section contains requirements related to software independence. software independence means that an undetected error or fault in the voting system’s software is not capable of causing an undetectable change in election results. All voting systems must be software independent in order to conform to the VVSG. There are currently two methods specified in the VVSG for achieving software independence: 1) through the use of independent voter-verifiable records (IVVR) and 2) through the innovation class.
Voting systems SHALL be software independent, that is, an undetected error or fault in the voting system’s software SHALL NOT be capable of causing an undetectable change in election results.
Applies to: Voting system
Test Reference: Part 3: 4.1 “Initial Review of Documentation”, Requirement Part 3: 4.2-C
DISCUSSION
The requirement applies to the voting system class, meaning that all voting systems that conform to the VVSG must be software independent.
Source: New requirement
Voting systems that use independent voter-verifiable records can satisfy the software independence requirement and thus achieve conformance to the VVSG. Such systems include systems that use voter-verifiable paper records (VVPR), such as (a) VVPAT and (b) optical scan used in conjunction with Manually-Marked Paper Ballots or with paper ballots that are electronically marked by an EBP or EBM.
software independence MAY be achieved through the use of independent voter-verifiable records or it MAY be achieved through an innovation class submission.
Applies to: IVVR
Test Reference: Part 3: 4.1 “Initial Review of Documentation”, Requirement Part 3: 4.2-C
DISCUSSION
This requirement is implied by Requirement Part 1: 2.5.3-A, which requires the implementation statement to include an IVVR voting system or an innovation class submission. Use of IVVR is the only method specified by requirements in the VVSG for achieving software independence. By using MAY instead of SHALL, this requirement does not preclude other methods for achieving software independence. When new methods are developed, additional subrequirements of this form will need to be added for those methods.
Source: New requirement
In a voting system of the IVVR class, every Vote-capture device SHALL be an IVVR vote-capture device.
Applies to: IVVR
Test Reference: Part 3: 4.1 “Initial Review of Documentation”, Requirement Part 3: 4.2-C
DISCUSSION
Voting systems that satisfy the IVVR voting system class requirements must include an IVVR vote-capture device, e.g., VVPAT, EBM, or MMPB. Conversely, voting systems of the IVVR class must not include any vote-capture devices that are not of the IVVR vote-capture device class.
Source: New requirement
The innovation class is for the purpose of ensuring a path to conformance for new and innovative voting systems that meet the requirement of software independence but for which there may not be requirements in the VVSG.
The following high-level principles apply to the innovation class:
A review panel process, separate from the VVSG conformance process, will review innovation class submissions and make recommendations as to eventual conformance to the VVSG.
In terms of conformance to the VVSG class structure, an innovation class submission is a voting system that includes one or more distinct innovative devices. The manufacturer must follow the same procedures that any manufacturer of a voting system must follow except that the manufacturer must also request and justify that a new device class be created in the VVSG for each distinct innovative device in the submission. For each new device class requested, the manufacturer must show where in the device class structure the new class is to be created. In listing the specific requirements of the new class, the manufacturer is expected to follow all rules of class hierarchy and requirement inheritance from Section 2.6.
For each distinct innovation class submission, the manufacturer SHALL adhere to the same submission procedures and requirements as for standard submissions.
Applies to: Voting system
Test Reference: Part 3: 4.1 “Initial Review of Documentation”
Source: New requirement
Each distinct innovation class submission SHALL include additional documentation that provides an explanation as to why the voting system and its accompanying devices are innovative and how they differ from voting technology that implements other voting device classes in the VVSG.
Applies to: Voting system
Test Reference: Part 3: 4.1 “Initial Review of Documentation”
DISCUSSION
The submission in effect requests the creation of a new device class for each distinct innovative device included in the voting system. This requirement is for the purpose of evaluating whether the creation of a new class is justified. To satisfy this requirement, the submitter may provide an overview of the device describing its functionality, boundaries, and interactions with other devices.
Source: New requirement
For each distinct innovation class submission, the manufacturer SHALL request and justify that a new device class be created in the VVSG for each distinct innovative device in the submission
Applies to: Voting system
Test Reference: Part 3: 4.1 “Initial Review of Documentation”, Requirement Part 3: 4.2-C
Source: New requirement
For each distinct innovation device class submission included In the voting system, the implementation statement for the voting system SHALL identify the new device classes to be created and where they fit into the device class hierarchy.
Applies to: Voting system
Test Reference: Part 3: 4.1 “Initial Review of Documentation”, Requirement Part 3: 4.2-C
Source: New requirement
For each distinct innovation device class submission included in the voting system, the implementation statement for the voting system SHALL identify all requirements that apply to the new class and suggested test methods.
Applies to: Voting system
Test Reference: Part 3: 4.1 “Initial Review of Documentation”, Requirement Part 3: 4.2-C
DISCUSSION
Identification of applicable requirements may occur through inheritance from superclasses or it may occur through reuse of requirements from other, similar classes.
Source: New requirement