We began the meeting with comments from Larry Moore, Herb Deutsch, and others regarding what sort of interoperability we are trying to accomplish with this format. There was general agreement that we are focusing on an interoperable format for CVRs currently and not necessarily looking at device interoperability at this point. At the same time, somewhat like election results reporting, this format may well achieve some device interoperability, e.g., between voting devices and tabulators.
Sam Dana gave an overview of the changes to the data model, primarily in that a Rank attribute was added to a voted ballot selection to accommodate RCV especially in cases where the ranks are not uniform or unique. A Weight attribute was also added to accommodate cumulative voting and there was some discussion as to whether this could be used for proportional voting, which may result in fractional values. Sam stated that the weight could serve as the numerator of the fraction.
There was a long discussion regarding what other changes should be made and general agreement that contests should be flagged if there are undervotes or overvotes. Note: the current model currently handles undervotes if the contest is entirely undervoted; adding a flag explicitly for each contest effectively requires that the CVR contain all contests and associated ballot selections - currently, the CVR contains only those contests that contain voted ballot selections.
There was also some discussion as to whether a flag should be included to indicate that the voter intentionally overrode the scanner kicking back a ballot with an undervote/overvote (in the case of a precinct count optical scanner).
There was additional discussion as to whether a ballot selection should be included for each case when the scanner detects some sort of mark on the paper ballot. In other words, if there is a crease in the ballot or a hesitation mark, the CVR should contain a ballot selection where the scanner has detected the crease/mark, but flag the ballot selection as non-tabulated.
The eventual file format was discussed, some people preferring CSV formats where as others recommending that JSON would preserve structure of the CSV more easily and still not take up nearly as much space as XML. We are going to table file formats for now and focus on what data needs to be included in the CSV.
David Cary noted that in some places in California, precinct scanners have an RCV tabulation function to the extent that at the close of polls they print a report which for RCV contests shows the total number of selections for each candidate for first-place rankings, second-place rankings, etc. There was general agreement that this did not require adding any additional information to the CVR.
Harvie Branscomb added that other fields should be part of the CVR to deal with functions involved in auditing and accountability including low resolution timestamps (think day-stamps) and voting/scanning device identification (already included in the current model). An adjudication team ID could be included for rare instances of human override of the original CVR. This provides a different and valuable functionality above the much desired digital signature for the entire CVR report. Write-in votes can be reflected in the CVR as a generic candidate whose total vote can be tabulated in order to compare it to thresholds that some states have for initiating research of write-in specifics. Harvie suggested that the identity of the candidate associated with each CVR-represented write-in vote is to be sought in a separate database.
Ian Piper noted that some central-count scanners can stamp numbers on ballots as they are scanned, including batch numbers. Thus, the data model should accommodate these additional items.
Ryan Macias noted that we are discussing in reality 2 different formats, one for the CVR with minimal interpretation by the scanner, and one to be used in auditing and tabulation. There seemed to be general agreement that the CVR can include some optional fields used in auditing and tabulation but a determination hasn’t been made yet as to what will be included.
The call ended with John Wack asking that people send in specific requirements that they see missing from the model and the discussion in these notes, i.e., “This data field needs to be added: xxxx, to handle this particular sort of situation: yyyy.” Please be as specific and descriptive as possible.
A new version of the model will be prepared with the following modifications:
1. flags for undervotes/overvotes will be added to contests
2. a ballot selection will be noted if the scanner detected a mark but did not tabulate the ballot selection
3. the model will accommodate identification of batches and possibly other identifying numbers
4. an override flag will be added if the ballot was rejected by the precinct count scanner and the voter overrode the rejection
5. a flag will be added to indicate that the write-in field was edited (in the case of the paper ballot that contained a write-in)