Digital Poll Watchers (dot) Org

Bottom Line Up Front (BLUF):

There are at least 6,096 statewide records that are currently approved to receive absentee ballots, on a permanent basis, that DO NOT HAVE CORRESPONDING RECORDS EXISTING in the Registered Voter List.

---

Derivation:

As we’re now in the early voting period for the VA April 21 2026 Special Election regarding the redistricting push (sidebar: we strongly urge you to vote, and to vote “NO” btw), we purchased a fresh version of the Registered Voter List (“RVL”) and the Comprehensive Absentee Application List (“CAAL”) from the department of elections, as well as a Voter History List (VHL), all at the same time.

This gives us a full, temporally consistent, official dataset of all of these files direct from the department of elections (“ELECT”).

The the CAAL encompasses the Permanent Absentee List (PAL) as well as those voters that have made non-recurring requests for absentee by mail ballots. Upon examining the CAAL file, there are a couple of issues that are easily observed.

The first issue observed is that the CAAL, as we received it from ELECT, contains a number of duplicated records, with the only distinction being the APP_STATUS field. As there is no other distinguishing difference between rows that represent the same voter ID, it is impossible to know which row represents the current “status” of the voter ID being represented. There is no distinguishing transaction time stamp or other method to determine precedence of the records.

We don’t have any way of knowing which row entry came first. i.e. Was John Q Public in the table below first deemed to be “INCOMPLETE” then “DENIED”, and then John corrected his request and was “APPROVED”? OR was he initially “APPROVED” by default, but then an issue was discovered by the GR and he was deemed “INCOMPLETE”, with him finally getting “DENIED” because he didn’t correct the issue after a given time period?

There is no way to tell from the incomplete data provided by ELECT.

ID	FIRST	MIDDLE	LAST	…	APP_STATUS
12345	John	Q	Public	…	APPROVED
12345	John	Q	Public	…	INCOMPLETE
12345	John	Q	Public	…	DENIED
		… etc …

So how do we make an inference as to if a given voter with multiple conflicting records in the CAAL are “APPROVED” to receive mail in ballots or not?

Since we don’t know the temporal precedence, we could try and make a mathematical simplification / assumption that an APPROVED state can be cancelled out by a any “non-approved” state, and then we can take the sum of any APPROVED state (with a value of +1) combined with any “non-approved” (with a value of -1) state for a given voter ID number that appears in the CAAL. If the result is positive, we could consider the current state as being “approved”.

While that might be an appropriate way to interpret the data … a more conservative method is to only consider those records where there is no conflict in the APP_STATUS field. i.e. There is only a single row representing a given Voter ID number, and it’s status is “APPROVED”. This assures us that there is no confusion, although it may be a significant undercount as to understanding the total numbers that are considered APPROVED by the state from the official record as provided.

If we take that second, more conservative, approach and then cross correlate with the aforementioned RVL, which was purchased at the same time as the CAAL, we discover a second issue with the data from ELECT. Namely, that there are a number of APPROVED records on the CAAL that have no existing record in the RVL. There are 6,109 of these, to be exact.

To be extra conservative in trying to interpret this data, if we further restrict this list to only those records that are “Permanent Absentee” … meaning that they are signed up to automatically receive mail in ballots every election in perpetuity … the number drops (only by 13) to 6,096.

That is … There are 6,096 statewide records (a very conservative estimate) that are currently approved to receive absentee ballots, on a permanent basis, that DO NOT HAVE CORRESPONDING RECORDS EXISTING in the Registered Voter List.

• This is based on only official data from ELECT
• All data was purchased at the same exact time from ELECT, so we have the most temporally consistent datasets possible to compare against.
• Our analysis was extremely conservative in our interpretation of the data from ELECT, ignoring entries that could not be clearly interpreted or rectified.

I previously had put together analysis that utilized the full name and date of birth information from the Virginia Registered Voter List (“RVL”) in order to look for duplicate registrations, either exact matches or by using a string distance measure (the Levenshtein distance) to accommodate for typos, abbreviations, and mis-spellings.

Just prior to the start of early voting in the 2024 November General Election, we were notified that the department of elections (“ELECT”) was removing the full date of birth from the data we purchase. This removal of the full date of birth increased the number of false positive in our duplication detection scripts. Our organization, as well as others, were ready to go to court to compel ELECT to reinstate the data. (Link to our notice of violation letter is here).

Happily, we ended up not having to go to court as ELECT decided to reinstate the data earlier this year (~May timeframe), which means we can resume our computation and detections of potentially duplicate entries again with much more reliable results. The results below mirror our previous analysis, but with the new updated data.

---

Using the latest Registered Voter List (RVL) and Voter History List (VHL) data purchased directly from the VA Department of Elections (ELECT) I wrote up an analysis script to check for potentially duplicated registrant records in the RVL and cross reference duplicate pairings with the VHL to identify potential duplicate votes. The details are summarized below.

Please note that I will not publish voter Personally Identifiable Information (PII) on this blog. I have substituted fictitious, but representative, PII information for all examples given below, and cryptographically hashed all voter information in the downloadable results file. I will make available the detailed information to those that have the authorization to receive and process voter data upon request (contact us).

Summary of Results:

As a baseline, there were 5,514 (as compared to 6,464 in the previous May 27, 2023 posting) records for STATUS=’Active’ registrants that adhered to the definition of a “duplicate” when Social Security Number (SSN) is not available, as defined by the MOU between DMV and ELECT (section 7.3) of having the same First Name + Last Name + Full Date of Birth (DOB). It should be noted that most records held by DMV and ELECT have a SSN associated with them (or at least they should). SSN information is not distributed as part of the data purchased by us from ELECT, however, so this is the appropriate standard baseline for this work.

Upgrading our definition of a potential duplicate to [First + Middle + Last + Suffix + DOB] and using a LevenshteinDistance=0 (meaning an exact match) drops the number of potential duplicates to 1,062 (1,982 previously), with each identified registrant in a pair having an exactly matching string result and unique voter ID numbers.

According to my derivations and simulations that are described in detail here, we should only expect to see an average of 11 (+/- 3) potential duplicate pairs (a.k.a. “collisions”) at a distance of 0. This is over two orders of magnitude different than what we observe in the compiled results. Such a discrepancy deserves further investigation and verification.

Allowing for a single string difference by setting LevenshteinDistance<=1 increases the pool of potential duplicates to 4,572 (5,568 previously). While this relaxation of the filter does allow us to find certain issues (described below) it also increases our chances of finding false positives as well. The LD metric results should not be viewed as a final determination, but as simply a useful tool to make an initial pass through the data and find candidate matches that still require further review, verification and validation.

Increasing to LevenshteinDistance<=2 brings the number of potential duplicates up to 27,178 (32,610 previously). When we increase to LD <= 3 we get an explosion of 158,940 (183,130 previously) potential duplicates.

It should be noted that compared to our last full analysis (May 2023) the dept of elections has reduced the number of exact duplicates by about 45%, and by approximately 13-15% for the other inexact categories.

Method:

For every entry in the latest RVL, I performed a string distance comparison, based on Levenshtein distance, between every possible pair of strings of (FIRST NAME + MIDDLE NAME + LAST NAME + SUFFIX + FULL DOB).  For the ~6M+ different RVL entries, we therefore need to compute ~3.8 x 10^13 different string comparisons, and each string comparison can require upwards of 75 x 75 individual character comparisons, meaning the total number of character operations is on the order of 202.5 Quadrillion, not including logging and I/O.

A distance of 0 indicates the strings being compared are identical, a distance of 1 indicates that there a single character can be changed, inserted or removed that would convert one string into the other. A distance of 2 indicates that 2 modifications are required, etc. 

Example: The string pair of “ALISHA” –> “ALISHIA” has an LD of 1, corresponding to the addition of an “I” before the final “A”.

I aggregated all of the Levenshtein distance pairings that were less than or equal to 3 characters different in order to identify potential (key word) duplicated registrants, and additionally for each pairing looked at the voter history information for each registrant in the pair to determine if there was a potential (again … key word) for multiple ballots to be cast by the same person in any given election.  As we allow for more characters to be different, we potentially are including many more likely false positive matches, even if we are catching more true positives.

For example: At a distance of 4 the strings of “Dave Joseph Smith M 10/01/1981” and “Tony Joseph Smith M 10/01/1981” at the same address would produce a potential match, but so would “Davey Joseph Smith M 10/01/1981” and “David Josiph Smith M 10/02/1981”. The first pair is more likely to be a false positive due to twins, while the second is more likely to be due to typo’s, mistakes, or use of nicknames and might warrant further investigation. A much stronger potential match would be something like “David Josiph Smith M 10/01/1981” and “David Joseph Smith M 10/01/1981”, with a distance of 1 at the same address. In an attempt to limit false positives, I have clamped the distance checks to <= 3 in this analysis.

Note that the Levenshtein distance measure is importantly able to identify potential insertions or deletions as well as character changes, which is an improvement over the Hamming distance measure. This is exampled by the following pairing: “David Joseph Smith M 10/01/1981” and “Dave Joseph Smith M 10/01/1981”. The change from “id” to “e” in the first name adds/subtracts a character making the rest of the characters in the remainder of the string shift position. A Levenshtein metric would correctly return a small distance of 2, whereas the hamming distance returns 27.

Also note that with the official records obtained from ELECT, and in accordance with the laws of VA, I do not have access to the social security number or drivers license numbers for each registration record, which would help in identifying and discriminating potential duplicate errors vs things like twins, etc. I only have the first name, middle name, last name, suffix, month of birth, day of birth, year of birth, gender, and address information that I can work with.  I can therefore only take things so far before someone else (with investigative authority and ability to access those other fields) would need to step in and confirm and validate these findings.

Results:

The summary totals are as follows, with detailed examples.

	DMV_ELECT MOU Standard	LD <= 0	LD <= 1	LD <= 2	LD <= 3
Number of Potential Duplicate Registrant Pairs	6,108	1,250	5,116	29,480	170,772
Number of Potential Duplicate Registrant Pairs (Active Only)	5,514	1,062	4,572	27,178	158,940
Number of Potential Duplicate Ballots	2,856	58	1,580	16,984	109,428
Number of Potential Duplicate Ballots (Active Only)	2,770	54	1,552	16,410	105,932

Examples of Types of Issues Observed:

NOTE THE BELOW INFORMATION HAS HAD THE VOTER PERSONALLY IDENTIFIABLE INFORMATION (“PII”) FICTIONALIZED. WHILE THESE ARE BASED ON REAL DATA TO ILLUSTRATE THE DIFFERENT TYPES OF OBSERVATIONS, THEY DO NOT REPRESENT REAL VOTER INFORMATION.

Example #1: The following set of records has the exact match (distance = 0) of full name and full birthdate (including year), but different address and different voter ID numbers AND there was a vote cast from each of those unique voter ID’s in the 2020 General Election.  While it’s remotely possible that two individuals share the exact same name, month, day and year of birth … it is probabilistically unlikely (see here), and should warrant further scrutiny.

Voter Record A:

AMY BETH McVOTER 12/05/1970 F 12345 CITIZEN CT

Voter Record B:

AMY BETH McVOTER 12/05/1970 F 5678 McPUBLIC DR

Example #2: This set of records has a single character different (distance of 1) in their first name, but middle name, last name, birthdate and address are identical AND both records are associated with votes that were cast in the 2020, 2021, and 2022 November General Elections.  While it is possible that this is a pair of 23 year old twins (with same middle names) that live together, it at least bears looking into.

Voter Record A:

TAYLOR DAVID VOTER 02/16/2000 M 6543 OVERLOOK AVE NW

Voter Record B:

DAYLOR DAVID VOTER 02/16/2000 M 6543 OVERLOOK AVE NW

Example #3: This set of records has two characters different (distance of 2) in their birthdate, but name and address are identical AND the birth years are too close together for a child/parent relationship, AND both records are associated with votes that were cast in the 2020 and 2022 November General Elections. 

Voter Record A:

REGINA DESEREE MACGUFFIN 02/05/1973 F 123 POPE AVE

Voter Record B:

REGINA DESEREE MACGUFFIN 03/07/1973 F 123 POPE AVE

Example #4: This set of records has again a single character different (distance of 1) in the first name (but not the first letter this time) and the last name, birthdate and address are identical.  There were also multiple votes cast in the 2019 and 2022 November General from these registrants.

Voter Record A:

EDGARD JOHNSON 10/19/1981 M 5498 PAGELAND BLVD

Voter Record B:

EDUARD JOHNSON 10/19/1981 M 5498 PAGELAND BLVD

Example #5: This set of records has two characters different (distance of 2) in the first and middle names and the last name, birthdate, gender and address are identical.  There were also multiple votes cast in the 2021 and 2022 November General from these registrants. Again it is possible that these records represent a set of twins given the information that ELECT provides.

Voter Record A:

ALANA JAVETTE THOMPSON 01/01/2003 F 123 CHARITY LN

Voter Record B:

ALAYA YAVETTE THOMPSON 01/01/2003 F 123 CHARITY LN

Example #6: The following set of records has the exact match (Distance = 0) of full name and full birthdate (including year), and same address but different voter ID numbers.  There was no duplicated votes in the same election detected between the two ID numbers.

Voter Record A:

JAMES TIBERIUS KIRK 03/22/2223 M 1701 Enterprise Bridge

Voter Record B:

JAMES TIBERIUS KIRK 03/22/2223 M 1701 Enterprise Bridge

Example #7: The following set of records has the exact match (distance = 0) of full name and full birthdate (including year), same address but different gender and voter ID numbers.  There was no duplicated votes in the same election detected between the two ID numbers.

Voter Record A:

MAXWELL QUAID CLINGER 11/03/2004 M 4077 MASH DR

Voter Record B:

MAXWELL QUAID CLINGER 11/03/2004 U 4077 MASH DR

Example #8: The following set of records has a single punctuation character different, with the same address but different voter ID numbers.  There was no duplicated votes in the same election detected between the two ID numbers.

Voter Record A:

JOHN JACOB JINGLHIEMER-SCHMIDT 06/29/1997 M 12345 JACOBS RD

Voter Record B:

JOHN JACOB JINGLHIEMER SCHMIDT 06/29/1997 M 12345 JACOBS RD

Results Dataset:

A full version of the aggregated excel data is provided below, however all voter information (ID, first name, middle name, last name, dob, gender, address) have been removed and replaced by a one-way hash number, with randomized salt, based on the voter [First Name, Middle Name, Last Name, Suffix, and DOB]. The full file with specific voter information can be provided to parties authorized by ELECT to receive and process voter information, Election Officials, or Law Enforcement upon request.

Recently I was made aware of the work Ed Solomon had been doing with data from the 2020 Colorado Cast Vote Records (CVRs), and I’ve taken some time to replicate and validate some of his data observations. I don’t always agree with Ed, but I wanted to take some time and verify the facts of the matter for myself.

For background, CVRs are machine logs of the way the tabulators process the “cast” ballots. You can think of them as equivalent to your bank statement showing all of the recorded transactions for each ballot scanned. They are required to be producible by ballot electronic tabulation systems, and are used as part of official forensic audits and documentation. They do not have any personal information and simply operate on the content of individual ballots as they are processed.

There are 2 specific items that need to be validated here:

1. Odd statistics associated with statewide ballot measures in Arapahoe County as compared to other counties. Specifically, there were two statewide ballot measures (one dealing with taxes, and another on abortion) that one would expect to show a significant partisan split, and we in fact do see such a split in neighboring El Paso and Adams counties. However, the ballot measures do not show the partisan split in Arapahoe County.
   • The difference is not just that the partisan split is muted or reduced, it is a night and day difference. In Arapahoe county there is almost no statistical difference between Trump and Biden voters on the ballot measures, but there is an obvious and clear difference on the same ballot measures in neighboring Adams and El Paso counties.
   • Why is this important? It raises questions as to the veracity of the election counts, data handling practices, and the ability to use CVRs for their intended forensic purpose.
2. The fact that the Arapahoe County CVR data was changed on the official county website without any notification or explanation around Feb 2025. The internal composition of ballots was changed in the data and “scrambled” by Arapahoe county … with the new version of the CVR files no longer showing the inconsistency from #1.
   • As CVRs are official records that are used for legal purposes such as audits etc., they should never be “quietly” changed or modified retroactively. A full and transparent explanation of the issues and steps made to remedy should accompany any updates for official documents such as CVRs.
   • This change took place years after the CVR was originally produced, and after Ed Solomon had used this particular CVR as part of his supporting documentation in an election case (Thompson vs Secretary of State NV) in Nevada.
     • The county was fully aware of the use of these records in the Nevada case.
     • The county CVRs had already been used in a previous audit of the 2020 election, where ballots from a specific tabulator and batch were pulled and compared to the cast vote record for accuracy. (see here, and here)
   • After Ed and Mark noticed the retroactive modifications and started asking questions, the County released a statement explaining that they were contacted by a researcher about potential issues with their CVR regarding “redaction” and privacy concerns.
     • However, the county statement gives an incompatible date for when the documents were “corrected”, according to the file timestamps and internet archive logs. The statement claims April 2nd 2025, whereas the contents of the uploaded file show Feb 20th 2025 as the file modification date.
     • The counties explanation does not comport with the observation of the scrambling of internal contents of official ballots. Its not just that the ordering of ballots was randomized to assuage privacy concerns, but that the actual records of votes cast were being swapped between ballots.
   • At BEST this shows a woeful lack of transparency and procedural safeguards by the county.
   • At WORST this has the appearance of being intentional tampering with official records.

I can independently replicate and validate both of these data observations. There does seem to be an issue with the ballot measures in the original Arapahoe County CVR data, and that data has been retroactively modified by the county in such a way as to scramble the information associated with votes cast.

Note that Ed Solomon, Draza Smith, Jeff O’Donnell (a.k.a. “The Lone Raccoon”), Mark Cook, MadLiberals, and others all provided data and pointers to the original documents and URLs in question, as well as their own analysis on the X.com platform.

Starting with item # 1:

Arapahoe County makes their CVR data available on their website (https://arapahoevotes.gov/transparency/). To obtain the new (modified) file click on the “Certification & Recounts” tab and scroll down to find the CVR link on the left hand side. Direct link is here: https://www.arapahoevotes.gov/file/2020-general-election-redacted-cast-vote-record

The original data is also still available on the Arapahoe County website, but one needs to do some creative sleuthing via the wayback machine and looking at the URL links in order to get to it, as was done by Mark Cook. (see: here and here)

The link to the original CVR file is: https://gis.arapahoegov.com/DL_Data/Redacted_CVR/Redacted_CVR_Export.zip

The original data from the 2020 CVR data had also been collected and collated by Jeff O’Donnell on his https://votedatabase.com (formerly ordros.com) site, which I archived and versioned in Sept of 2022. I can confirm that the original file matches the files in the votedatabase archive, as well as the current votedatabase site. I used additional files from votedatabase archive for neighboring Adams and El Paso counties as a source for the rest of this work, as I could not find corresponding links to CVR downloads on the Adams or El Paso county websites.

Ed’s original observation was that the two ballot measures that *should* be partisan split were not when looking at the original 2020 CVR Arapahoe County data. He used this observation as supporting evidence showing inconsistencies and irregularities in 2020 election data in an court case (Thompson vs Secretary of State NV) he was providing analysis for in Nevada. All of his analysis and the original file have therefore been previously submitted to the court.

Amendment B was a repeal of the “Gallagher Amendment” dealing with property tax rates and was expected to have a highly partisan split. Likewise Proposition 115 dealt with abortion and was also expected to have highly partisan split.

If we look at the plots of the ballots cast for these two ballot measures, but we condition them on if the person voted for Trump or Biden at the top of the ticket we do see in neighboring counties such as El Paso and Adams counties this partisan split, as shown below. Note the significant spread between the Biden/No (Yellow) & Trump/No (Purple), as well as between the Biden/Yes (Blue) & Trump/Yes (Red).

As can be seen in the plots above from Adams and El Paso counties, there is a significant partisan split in these two down-ballot races when conditioned on how the top of the ticket votes. However this seems to vanish when looking at Arapahoe County, with the Biden/No (Yellow) & Trump/No (Purple) and the Biden/Yes (Blue) & Trump/Yes (Red) stacking almost completely on top of one another.

It can be clearly seen in the plots that the partisan split that was present in the other counties results seems to have completely vanished in Arapahoe.

I will note that the partisan split seems to be missing from almost all down-ballot races that I looked at, not just these two, although these were the ones specifically called out by Ed. This is an important point that I will come back to in a minute.

… And now to item # 2:

Ed’s original observation was submitted as part of his case in Nevada. At one point he and Mark Cook attempted to make a live stream video showing how people could recreate the observations starting from the source documents on the Arapahoe County website, which is when he and Mark realized that the original CVR file on the county website had been quietly replaced with a new file that had its contents scrambled and the results no longer showed the observed pattern.

Note that a CVR file is a legally required forensic record. It is the equivalent of a bank transaction log, and should almost never have its contents manipulated. If an error is discovered, and a correction does need to be issued, then a new file with the corrections should be published along side the original with a clear and prominent explanation and notification of the change. In this case, however, the County simply replaced the link to the original file with the new file with no explanation and no notice.

It was only after this was discovered, and after Ed started making phone calls to the County and bringing up the issue with the Judge in his Nevada case, that Arapahoe County belabouredly published an admission that they had adjusted the file. Their excuse for the modification was that they were made aware of a mistake with their “redaction” of data in the original publication, and were worried about individual privacy.

The (new) altered file did have 16 specific ballots that had their down-ballot races zeroed out, and was missing the “CountingGroup” metadata column. However, the file didn’t just have a small number of ballots (16) down-ballot information omitted, the internal contents on ALL ballots were also completely scrambled, with the top-of-the-ticket entries for President and Senate and metadata columns being completely reordered from all of the down-ballot information. This split-scrambling also also “fixed” the observed issues with Amendment B and Proposition 115, as can be seen below, where there is now a distinct partisan split between the data trends.

This kicked off multiple efforts to reverse engineer the actual changes that were performed on the CVR data by Arapahoe county, by myself and multiple others. Jeff O’Donnell and MadLiberals on X made the observation of the split reordering. I was able to verify this and remove the split-shuffling, exposing the fact that there were 16 ballots that also had all of their down ballot information zeroed out. There were a total of 432 down ballot votes that were removed from 16 specific ballots, followed by ALL of the President and Senate votes for ALL ballots being scrambled in relation to their down-ballot races.

Back to the point I made before above … the “scrambling” of the new file does seem to have “fixed” the expected partisan nature of most of the down-ballot races, so it is not unreasonable to think that this was actually a “fix” for a processing error on the original CVR file. That being said, the original (assumed incorrect) CVR was used in an audit process of two down-ballot races (linked above). Why did they not catch this issue years earlier during the audit? And why did they make the change to files, under the pretense of privacy issues, without announcing and documenting the errors?

Conclusion:

I can verify the two main data issues documented by Ed Solomon on the Arapahoe County 2020 CVR data.

The original data file had significant issues with down-ballot races not showing the expected partisan splits.

Arapahoe county did “quietly” revise the data without explanation until it was discovered by Ed and Mark, and then when pushed, only acknowledged that there was an issue with redactions and data privacy concerns.

The fact that the modification did correct the expected partisan split for ALL down-ballot races lends some credence to the assertion that they were correcting an error/issue with the original CVR file, however it does not excuse the fact that they performed this correction without notice or explanation. It also does not explain how their 2020 audit was able to use the incorrect original CVR files and not catch any of these issues.

The CVR files are intended to be official forensic records. If they are subject to manipulation and “adjustments” without transparency then that brings into question the validity of those files as forensic devices in the first place.

Corrections:

• (5/28/2025) Typo correction in that the original posting of this article had “April 2 2024” as the data the Arapahoe county statement said they changed the CVR. That was corrected to be “April 2 2025”.
• (5/28/2025) I had the wrong reference for the associated case in NV. I had originally posted that the case was the “Gilbert” case. It is actually “Thompson vs State”. Links have been updated accordingly.
• (5/28/2025) Minor spelling errors corrected.