2020 Presidential Election Vote Reporting Anomalies

Analysis of 2020 Presidential Election vote count reporting anomalies

Introduction

There have been multiple reports of vote count reporting irregularities observed during the 2020 Presidential Election, like those reported by Gateway Pundit. Based on further analysis of the data already shared via the GP report, in this webpage I present irrefutable examples of vote count irregularities that can only be explained by automatically triggered vote counting/reporting software action (the action could have been initiated by pre-programmed batch instructions to the vote counting/reporting software). In this report are also listed the number of votes and for a category of irregularities the vote margin between Trump-Pence and Biden-Harris tickets that those impacted.

For this analysis Edison Research NEP data was used, scraped at around just past midnight PST from NYT website on 11/17/20 per the below instructions in the blog post that was referenced in the above GP report. The Edison .json files data was converted to a single .csv file using the python script shared below and then it was converted to an Excel spreadsheet for further analysis.

I have now also updated this post with further analysis based on per precinct vote counts scraped from Edison .json files scraped from NYT website, which show clear mismatch with the counts used by most media companies based on Edison election data to call the election result and which also shows massive number of votes (~340K) being purged from the per precinct vote counts in Michigan which were covered up due to no corresponding changes shown in the visible vote counts. Please jump to the section named Per precinct vote count and visible vote count mismatches (check TOC for link) for that analysis.

Before we delve further into the kind of irregularities found, I would like to mention about a quirk that I observed when working with Trump's and Biden's vote counts extracted from the total vote count multiplied by the corresponding 3 digit (after decimal point) share fraction, which is the format in which the data is stored in Edison .json files. Using those vote counts I would see several instances where Trump's AND Biden's vote numbers for an entry was lower than the previous entry, like observed in the 2 screenshots below:

Then I realized that most of these excessive number of vote losses were in fact artifacts of the rounding error that occurs when vote additions of less than 0.001 times the existing total vote count are made in the candidates' vote counts. Below is a screenshot explaining these rounding errors from Gary Warner's blog. Gary Warner is the Director of Research in Computer Forensics at the University of Alabama at Birmingham.

Gary Warner's blog also explains how accurate candidate vote counts can be extracted from Edison data files showing per precinct data, also available at NYT website, as shown in the screenshot below.

As seen in the above screenshot, Gary Warner's biased conclusion is to discount the above discrepancies until Edison Research and/or NYT explain them but I don't concur with that conclusion. I have now extracted the per precinct candidate vote counts from the corresponding Edison data files for 4 states scraped from NYT website. The updated analysis based on that data is below in the section named Per precinct vote count and visible vote count mismatches. In this section, to ignore the above rounding error related artifacts I added more columns in my spreadsheet that would register losses in the vote count numbers only if they were higher than 0.001 times (i.e. >0.1%) the existing total vote count. After adding this check I still found multiple instances, in multiple states where President Trump actually lost votes while Joe Biden gained those votes in a single vote count update, in other words a vote switch. In the below sections I describe that and other irregularities and show that those can only be the result of actions taken by vote counting/reporting software automatically and cannot be explained by new vote tally updates from the vote tabulation locations.

All the Edison data .json files, python script used to convert to .csv, the .csv file and the .xlsx spreadsheet are in the zipped file available for download here. A view of the spreadsheet used for this analysis is as follows.

PresElectionTrumpVoteAnalysis_11_17_20.xlsx

Vote counting irregularities in visible counts

This section describes the various vote counting irregularities observed. Below is a screenshot from the "VoteAnomalyTotals" sheet in the above spreadsheet which shows the irregularities observed in key states and the vote totals or the vote margin (in case of vote switches) changed due to these anomalies. From the vote count analysis I did not find any vote counting irregularities in Arizona or Nevada, but that doesn't include any irregularities pre-tabulation that would cause illegal votes being cast. Please note that the below numbers are lower than those published at the blog post referenced in the GP report likely because the author of the post did not take care of the quirk to account for rounding errors in the candidate vote counts that I described in the previous section. Details of each type of irregularity are below.

Trump to Biden Vote Switches

Pennsylvania

PresElectionTrumpVoteAnalysis_11_17_20_PennVotesSwitched.xlsx

The above view from the spreadsheet shows rows corresponding to vote count updates where votes were switched from Trump to Biden and also corresponding to immediately prior vote count updates from Pennsylvania. The rows where votes were switched have non-zero vote counts in the "Trump Votes Lost >0.1%" and "Biden Excess Votes >0.1%" column cells. "Biden Excess Votes >0.1%" column cells have the number of Biden votes added in the update, when they are more than the total number of votes added for the update by more than 0.1% of the current total vote count. To arrive at the "Trump To Biden Vote Switch Totals" value the cell values from the "Trump Votes Lost >0.1%" and "Biden Excess Votes >0.1%" columns are added (as can be seen in the formulas for the corresponding cells). The vote updates prior to the vote switch can be seen occurring just seconds before in one case and just about a minute before in the other case. Also, the votes added to Biden's total are more than the total number of votes added in the update (in fact, there is a loss of total number of votes in one case). Taking this behavior into consideration it can be concluded that these vote switches cannot be the result of legal vote count updates from the tabulation location.


Michigan

PresElectionTrumpVoteAnalysis_11_17_20_MIVoteSwitch.xlsx

The above view from the spreadsheet shows rows corresponding to vote count updates where votes were switched from Trump to Biden and also corresponding to the immediately prior vote count updates from Michigan. The same behavior is observed here as observed for vote count switches in Pennsylvania.


Vote Losses

The following sub-sections show total votes lost in multiple states. These cannot be part of legal vote count updates from the tabulation locations where votes are supposed to be added, not deleted and hence vote counting/reporting software action would have caused this. Once legal votes are deleted from the total counts this way, illegal votes can be stuffed in their place to generate a fake vote margin.


Pennsylvania

PresElectionTrumpVoteAnalysis_11_17_20_PennVoteLoss.xlsx

Georgia

PresElectionTrumpVoteAnalysis_11_17_20_GAVoteLoss.xlsx

Michigan

PresElectionTrumpVoteAnalysis_11_17_20_MIVoteLoss.xlsx

Wisconsin

PresElectionTrumpVoteAnalysis_11_17_20_WIVoteLoss.xlsx

Virginia

PresElectionTrumpVoteAnalysis_11_17_20_VAVoteLoss.xlsx

Minnesota

PresElectionTrumpVoteAnalysis_11_17_20_MNVoteLoss.xlsx

Spurious Vote Additions

A spurious vote addition behavior was observed in Minnesota where the number of votes added both to Trump and Biden were observed to be more than the number of total votes added by more than 0.1% of the existing vote count. This behavior would be typical of when votes are being illegally switched from 3rd party or write-in candidates. This also cannot happen without willful participation of vote counting SW. This is shown in the below view of the spreadsheet. The spurious vote stuffing mechanism in other states was not clearly apparent from the vote counts, but one possible way it could have been accomplished is by a set of illegal ballots all voting for Biden and subsequently tabulated. There clearly would have been need for vote stuffing to match the actual ballots cast count, since it was artificially reduced by the vote counting/reporting software. Maybe that's why Wayne County, MI is having ballot count mismatch issues currently.

PresElectionTrumpVoteAnalysis_11_17_20_MNVoteLoss.xlsx

Per precinct vote count and visible vote count mismatches

In a comment to this post by the user unfiltered I found the list of all the per precinct vote count data .json files (until 11/11), as specified below:

Georgia: https://pastebin.com/CD05B8fw

Michigan: https://pastebin.com/W4h6FSPi

North Carolina: https://pastebin.com/stpeXHYE

Pennsylvania: https://pastebin.com/5xBeaQzh


So, I wrote a multithreaded Python script to quickly download all the .json files listed in a text file whose name is passed as a command line argument and I have uploaded it here. I saved the above URL lists in files named GAPrecinctURLList.txt, MIPrecinctURLList.txt, NCPrecinctURLList.txt and PAPrecinctURLList.txt and I ran the above python script to download all the .json files to the same folder. I already had the regular Edison election feed data .json files previously scraped from NYT website at the same location. Then I ran this python script to extract the statewide aggregate vote counts and per candidate vote counts from each of the .json files and tabulated it in a single result.csv file along with the data from regular election feed files with a proximate timestamp. Also, the script creates separate .csv files for each state tabulating the per precinct counts for each timestamp and they are named GAPrecinctResults.csv, MIPrecinctResults.csv, NCPrecinctResults.csv and PAPrecinctResults.csv respectively. I renamed result.csv to PresElectionTrumpVoteAnalysisPrecincts_11_21_20.csv and converted it to PresElectionTrumpVoteAnalysisPrecincts_11_21_20.xlsx spreadsheet while adding columns to facilitate further analysis. Views of the spreadsheet are shown below along with description of various observations. In both the .csv and .xlsx files entries for the columns named state, timestamp, votes, eevp, Trump Share, Biden Share were extracted from the regular election feed .json files while the Trump Votes, Biden Votes, Jorgensen Votes and Total Precinct Votes column entries were generated from the precinct data .json file with a timestamp proximate to the timestamp of the corresponding entry in the regular election feed data. The additional columns in the .xlsx file with "Timeseries" in their name have stats extracted from the data in regular election feed .json files and the other columns have data extracted from the per precinct .json files. I have uploaded all the data along with the .xlsx spreadsheet in a zip file here. For anyone who would like to run the python script to generate the .csv files from the .json files, please note that the script takes a while (it takes ~30 mins on my laptop) to crunch the data and generate the .csv files.

The following sub-sections list out consistent mismatches between the per precinct vote counts and vote counts from election feed data files, which prove beyond any reasonable doubt systemic issues in election feed software which impacted the outcome of the election since the number of votes impacted are more than the vote margin between the candidates. Also, the election data feed failed to reveal purges in total of about 340K votes seen in the per precinct vote count data in Michigan that could have been done to facilitate later ballot stuffing. So, it comes as no surprise that there was a large discrepancy in the vote counts in Wayne County, MI.

Exhibit 1: Front Loading of Votes in Election Data feed in Pennsylvania

PresElectionTrumpVoteAnalysisPrecincts_11_21_20 1_PennFakeVotesFrontLoaded.xlsx

In the above view of the spreadsheet it can be seen that at row 7, the election data feed from Pennsylvania already shows a count of 64535 votes in column C (votes) even when none of the precincts had reported. Later even after the precinct data feed starts showing up votes (in column J "Total Precinct Votes"), the gap in number of votes between the election data feed and precinct data feed keeps increasing. Also, the share of votes for the candidates in the election data feed and the precinct data feed keeps diverging by a large margin. In fact, as seen in the below snapshot from the same spreadsheet, at row# 580 it can be seen that the difference between the votes in the feeds has grown to 4,667,665 votes and the number of votes in the precinct feed did not move for several days while the election feed vote count continuously keeps incrementing. The vote numbers in both the feeds should match otherwise it clearly shows fraud in one of these vote counts. Since all the results are based on election feed results and it does not match the precinct vote counts, it cannot be accepted as reliable on the basis of which the result of the election can be determined.

Exhibit 2: Switching of votes in Pennsylvania in Election data feed with no change in Precinct votes

PresElectionTrumpVoteAnalysisPrecincts_11_21_20 1_VoteSwitchWhenNoRealVotesAdded.xlsx

In the above view of the spreadsheet are shown 2 instances of vote switches from Trump to Biden, when no votes were added to the precinct vote count and in the election data feed Biden gained 12400+17929 = 30329 votes while Trump lost 127915+17876 = 145791, a total difference in margin of 176120 votes. In the first instance, when Biden gained 12400 votes the total number of votes in the election data feed actually went down by 114886 votes. This clearly shows the unreliability of the software generating the election data feed. It appears to be generating manipulated vote counts that do not match the real vote counts that are supposed to be generated at the precincts.

Exhibit 3: Divergence Between Election Data feed And Precinct Vote Counts in Michigan

As can be seen in the above screenshot from the spreadsheet, the difference between the election data feed vote count and the precinct vote totals initially is around 230K votes. But it keeps on diverging and increases to 2,884,235 votes as can be seen in the screenshot below, which is considerably more than the vote margin between the candidates. The election data feed vote count must match the precinct vote counts and it instead diverges. This clearly shows that the election feed vote counts are unreliable and cannot be used as a basis for calling the election for any candidate.

Exhibit 4: Precinct Vote Count Purges in Michigan

As can be seen in the above screenshot from the spreadsheet, precinct vote purges were observed early morning after 3 am EST on 11/04, which did not register in the corresponding election feed. It is possible that the vote purges were done to purge valid votes and then later fill those votes via illegal ballot stuffing and this needs to be investigated. The number of votes thrown out is above the current vote margin between the candidates. Also, the fact that the election data feed did not pick up these vote purges shows a fundamental systemic issue with the software providing that feed, since the precinct vote counts are supposed to back this election data feed.

Exhibit 5: Votes lost from Election Data Feed in Georgia to match Precinct vote percentages

Above screenshot from the spreadshseet shows that there was a loss of about 3K votes from the election feed vote count while the precinct votes remained unchanged and the apparent reason was to keep the candidate vote percentages same as the precinct vote. Trump's vote share fluctuated between 0.523 and 0.521 until it reached 0.522 via the vote loss. This clearly shows that election results reporting SW was doing some kind of curve shaping so that the percentages remain the same, instead of recording the precinct votes accurately. It is possible that the SW needed to do this to counter some effects of weighted voting that causes the total number of votes to be more than the number of people who voted. In any case, if election results reporting software is not accurately reporting the precinct vote totals, then the people who created that software are engaging in fraud.

Vote count tracker based on NYT Votes Remaining Page

I have added a NYT-2020-Vote-Count_Tracker Github repository based on alex/nyt-2020-election-scraper (github.com) which was auto scraping the NYT Votes Remaining page JSON every 5 minutes, where I added a python script TabulateVoteCounts.py that tabulates, into the file VoteCounts.csv, per candidate, per vote type (Absentee, ElectionDay, Provisional) vote counts statewide aggregated per county and other relevant vote information like Maximum Absentee Votes, Uncounted Mail-in Ballots (available only for Pennsylvania) extracted from the per county information on the page and the referenced precinct_metadata JSON files. The VoteCounts.csv spreadsheet is downloadable from the NYT-2020-Vote-Count_Tracker Github repository. The tabulation of the above data is aligned with the latest timeseries data for the state. Also, another enhancement in this repository compared to the original repository alex/nyt-2020-election-scraper (github.com) is that I checked-in all versions of NYT Votes Remaining Page that were auto-scraped by Wayback Machine before this auto scraper was deployed. If any readers of this blog would like to clone the above Github repository and run the TabulateVoteCounts.py script themselves on their machine they should note that when the script runs for the first time it fetches from Github all versions of the 'results.json' file in the repository and caches a copy of that in the '_cache' sub-folder. It also caches copies of the precinct_metadata .json files referenced in the 'results.json' snapshot in the '_cache\precinct_metadata' sub-folder. This data is about 22GB in size. So, if you would like to run the script yourself please ensure that you have that much space available on your machine. Also, an initial run of the script takes about an hour to complete. It then runs faster for further runs when operating on cached data. Below are some observations based on a first pass scan of the spreadsheet.

I pushed significant updates to the above GitHub project on 12/03-12/04, pushed other significant changes on 12/09 and 12/20 and all the changes are listed below:

  1. Pushed a feature to show precinct data from precinct_metadata files previously listed at the links shared in a previous section, at gaps in between results.json snapshots. Also, the change adds another feature in TabulateVoteCounts.py to add columns in VoteCounts.csv to show total number of precints and precincts reporting both from results.json snapshots and also from referenced precinct_metadata files.

  2. Pushed a change in TabulateVoteCounts.py script to use 'precinct_by_vote_type' list instead of 'precinct_totals' list from precinct_metadata .json files to assemble aggregate precinct stats, as I observed more precincts reported votes via that list.

  3. Pushed a change to enhance TabulateVoteCounts.py script to add another column 'Precinct_Meta_Precincts_Reporting_ElectionDay_Votes' in VoteCounts.csv spreadsheet that shows the total number of precincts reporting the election day votes.

  4. Pushed changes to add another script TabulateCountyVoteCounts.py that tabulates in the added CountyVoteCounts.csv spreadsheet the Absentee, Non-Absentee (which are Election Day votes if no provisionals have been counted) and Total votes for each candidate from each of the counties in every state for every scrape of the NYT votes remaining page.

  5. Pushed changes to TabulateCountyVoteCounts.py to enhance CountyVoteCounts.csv spreadsheet to include data from precinct-metadata files for which no corresponding NYT votes remaining page snapshot was saved and added more columns to the spreadsheet. Also there are changes to improve the performance of the script via using Python Numpy arrays and that cut down the run time to 1 hour and 50 minutes, as opposed to 6+ hours.

  6. Pushed changes to TabulateCountyVoteCounts.py to enhance CountyVoteCounts.csv spreadsheet to extract additional data from precinct-metadata files, like the aggregate of precinct vote totals for the counties, which is instrumental in identifying any discrepancies with the vote tallies reported at the county level.

  7. Pushed a change to add CountyVoteCountsDelta.xlsx spreadsheet to show differences in vote counts between consecutive updates for several columns in CountyVoteCounts.csv spreadsheet and also to show discrepancies in the vote tallies reported at the county level compared to the aggregate of precinct vote totals for the same counties.

Using the CountyVoteCountsDelta.xlsx spreadsheet I was able to identify evidence of over a million votes fraudulently injected during countywide vote tallying in Pennsylvania. This evidence is presented via a YouTube video embedded in the first sub-section of the following section. Using the enhanced VoteCounts.csv spreadsheet and the corresponding listed precinct_metadata files there I was also able to identify the smoking gun evidence of how the tremendous election day vote margin for President Trump broke the election night reporting (ENR) software being used in Allegheny county, PA which is hosted on Scytl servers. This evidence is presented in the second sub-section of the following section. Moreover, using the Non-Absentee, i.e. Election Day (as no provisional ballots are being reported) vote counts extracted in CountyVoteCounts.csv I found evidence of election day vote count manipulation in all Pennsylvania counties that used Scytl ENR software. This evidence is presented in the third sub-section of the following section.

Pennsylvania


Evidence of over a million fraudulent votes injected during countywide vote tallying in Pennsylvania

The above YouTube video presents evidence of over a million fraudulent votes injected during countywide vote tallying in Pennsylvania. This evidence is based on the discrepancies observed in the vote tallies reported at the county level compared to the aggregate of precinct vote totals for the same counties. For folks who are not familiar with git commands to sync the repository, the Excel spreadsheet that was used in this analysis is also available for download here.


Election Night Reporting Software Busted in Allegheny County

While analyzing the VoteCounts.csv spreadsheet I observed that the number of precincts reporting votes went down as shown in the screenshot above, as reported in the precinct_metadata file at UTC timestamp of 11/04/2020 05:27:31 AM (i.e. 00:27:31 AM EST). So, I looked at the 'precinct_by_vote_type' list in this precinct_metadata file (which is saved at \_cache\precinct_metadata sub-folder relative to the local copy of the repository) and compared it against the immediately previous precinct_metadata file which has a timestamp of 11/04/2020 05:01:47 AM (i.e. 00:01:47 AM EST). Below is a screenshot of the comparison (older file is on the left side).

From this comparison it appeared as if precincts were being turned OFF alternately (i.e. showing "is_reporting":false). However, as seen in the screenshot below, a closer look at the precinct_metadata file with later timestamp reveals that all the entries that are being turned OFF are for Allegheny county election day votes for the corresponding precincts. It makes sense that this caused the number of precincts reporting to go down as the script aggregates the numbers of only those precincts that report election day votes, to avoid repetition.

A closer scan of the older precinct_metadata file revealed that all of the entries that were being turned OFF were election day vote counts in Allegheny county and each of those entries was stuck at a value of 7 total votes distributed amongst the candidates exactly as follows:{"bidenj":1,"trumpd":2,"jorgensenj":3,"other":1}. An even closer look at the data via converting the 'precinct_by_vote_type' list in the precinct_metadata .json file (using the JsonList2Csv.py (github.com) script) to CSV spreadsheet revealed that all the election day entries were either in the above distribution or in the distribution {"bidenj":2,"trumpd":4,"jorgensenj":6,"other":1} or in an integral multiple of either of those distributions. This can be seen in the "PAlleghenyScytlStuck" spreadsheet view shared below. This is the hallmark of a software weighted voting (aka Ranked Choice Voting) algorithm that initialized the election day votes in all Allegheny precincts with that fake distribution before getting busted for some reason. I also confirmed that votes were being distributed amongst the candidates in the above same ratio across Alleghany County for multiple updates by tabulating the 'county_by_vote_type' list in all the precinct_metadata .json files for Pennsylvania using JsonAllList2Csv.py (github.com) in a single CSV spreadsheet, as seen in the "PACountyByVoteTypeList" spreadhseet view below.

PAAlleghenyScytlStuck
PACountyByVoteTypeList

Below is a video showing the election day vote counts updating in the unreal Biden:Trump:Jorgensen ratio of 1:2:3 in the updated CountyVoteCounts.csv spreadsheet (after SW update 5 specified in the previous section) which also shows an instance of Absentee Vote counts zeroed out in NYT Votes Remaining page JSON file and moved to Non-absentee vote column in an apparent attempt to hide this behavior. This is irrefutable evidence of illegal software manipulation of the election night vote counts. So, no wonder Allegheny County officials had to stop all vote counting at 1:30 am EST after this snafu. Pennsylvania legislators should call for a full audit of the election night vote tallying done via software in Allegheny county and look for any malicious vote manipulation algorithms being used in the software.

CountyVoteCounts.csv - Excel 2020-12-20 04-11-51_Trim.mp4

I also looked at the precinct_metadata files corresponding to the entries in the VoteCounts.csv spreadsheet when the precincts reporting number started picking up again and there it can be seen (see precinct_metadata diff screenshots below compared to the time when election day reporting was stopped) that President Trump had tremendous vote margins in 2:1, 3:1 or even close to 4:1 ratios for election day over his opponent and possibly that is what broke Scytl ENR software vote manipulation algorithm.

Evidence of Vote count manipulation in all PA counties that use Scytl ENR software

Allegheny, Westmoreland and Luzerne counties in Pennsylvania use Scytl ENR software. Plots of the election day candidate vote counts, from CountyVoteCounts.csv, against each other are shown below. The plots show a straight line or a set of connected straight lines (except for what look like branches growing out of the longest straight line for Allegheny county, which are explained in the following paragraphs), which implies that the vote update ratio between the 2 candidates remains constant across multiple updates plotted on the line encompassing hundreds of thousands of votes, which is an un-realistic anomaly.

The election day vote count update sequence for Alleghany county on the Trump vs Biden plot is shown in the following slides with the Y axis values showing up in bold on the label for each data point.

AlleghenyCountyPAVoteCountManipulation.pptx

In the above sequence there are 3 instances (between slides 2 & 3, 5 & 6 and 11 & 12) when the election day vote counts for both the candidates go down, with the last 2 instances manifesting on the line chart plot as what look like branches growing out of the longer line. A look at the CountyVoteCounts.csv spreadsheet entries corresponding to the above changes (see spreadsheet screenshots below corresponding to each change) reveals that the election day votes deleted here are switched over to absentee vote counts. Also, from the markedly different slope for the branches corresponding to the addition of these votes before they get deleted it appears that these are absentee votes to begin with that were incorrectly added to the election day vote counts. However, on looking at the NYT Votes Remaining Page .json file snapshots (accessible via copy saved in '_cache' subfolder with filename listed in 'Votes_Remaining_File' column entry) corresponding to these absentee vote infusions it can be seen that none of them include any write-in votes, which is unrealistic. Below the spreadsheet and line chart snapshots are posted the .json file snapshots corresponding to the first absentee vote infusion (116,431 votes) and the final snapshot taken on 12/04 (345,031 absentee votes) both of which show 0 write-in absentee votes, which is totally unrealistic. On the other hand, other smaller counties like Washington county, which do not use Scytl ENR, report write-in absentee votes, as expected. Also, for the first instance after the votes are switched over to the absentee columns, the remainder election day votes are in the same anomalous Biden:Trump:Jorgensen ratio of 1:2:3 as was discussed in the previous sub-section. Also, for the third instance, before the anomalous vote infusion into election day votes, at 'state_last_updated' timestamp of 2020-11-07T00:10:39 UTC there are tiny changes in election day votes of Biden's vote count going down by 84 votes and Trump's vote count going up by 111 votes. This happens when the total absentee vote count goes up by 5290 votes and the total election day vote count goes up by a mere 67 votes. The change in the Trump to Biden election day vote count ratio by this change is so minute (0.0016) that the data point of Trump:209,016, Biden:148,019 before the change does not even show up in the above line chart plot. This indicates that the vote counts reported by ENR software are not raw vote counts reported by vote counting centers but are instead extracted using ratios internally manipulated by a SW algorithm that causes these minute vote count changes due to rounding artifacts. All this is can be observed in the below spreadsheet screenshots.

The election day vote count update sequence for Westmoreland county on the Trump vs Biden plot is shown in the following slides with the Y axis values showing up in bold on the label for each data point.

WestmorelandCountyPAVoteCountManipulation.pptx

The Westmoreland county plots are a straight line in the beginning and then they start plotting along a second line with a slope towards Biden's vote gains (at 'state_last_updated' UTC timestamp of 2020-11-04T20:08:53, as seen in slide# 4 above) and at the end pull back along that line after election day vote deletion (at 'state_last_updated' UTC timestamp of 2020-11-11T03:13:44, as seen in slide# 8 above). A look at the CountyVoteCounts.csv spreadsheet entry corresponding to slide# 8 above reveals that the election day votes deleted there are switched over to absentee vote counts and in fact, then the absentee vote column for county registers numbers for the first time. From the above behavior it appears that added absentee vote counts were being masqueraded as election day vote counts, while maintaining the same candidate vote shares in the votes added across updates (hence the straight line), for about a week before they were switched over to absentee vote column and the same candidate election day vote shares were maintained even after the switch. Also, a comparison of the election day vote counts seen at slide# 3 (screenshot shown below) before the vote counts start moving along the second line where absentee votes masqueraded as election day votes appear to be added and the final vote counts at slide# 12 (screenshot shown below), show that Trump lost 6,899 election day votes. Also, it can be seen in the plot that after the election day vote deletion seen between slides 7 and 8 above, the election day vote counts increase along a very short third straight line until they reach the counts shown on slide# 12. Also, just like Allegheny county above and Maricopa County in Arizona where data shows Dominion SW illegally purging election day write-in votes and switching some of them to absentee votes, the "results_absentee" JSON object for Westmoreland county in the NYT Votes remaining page .json file snapshot does not show any "write-in" absentee votes, while that for Washington county with lower number of absentee votes shows absentee write-in votes. This can be seen in the .json file snapshots posted below the spreadsheet and line chart snapshots. This makes all the 59,261 absentee votes counted in Westmoreland county suspect and potentially fake. The above behavior is a clear hallmark of a SW driven vote manipulation algorithm, with or without manual intervention.

On the other hand, a realistic voting pattern is seen in the election day vote count plots for Butler, Franklin and Philadelphia counties that do not use Scytl ENR software and the plots are shown below, where the ratio between the candidate votes added changes frequently across the vote count updates and there are no vote deletion shenanigans. This clearly proves that Scytl ENR software is manipulating the vote counts wherever it is used and since (according to a January 2019 study by the Blue Ribbon Commission at the University of Pittsburgh) some counties allow the Pennsylvania Department of State to directly scrape results from their election reporting website and if these counties use Scytl ENR software the resulting manipulated, incorrect vote counts were added to the state vote total. That clearly opens up the possibility of vote count manipulation above the current margin between Biden and Trump having taken place via this means.

Discrepancy in number of precincts reporting

The number of precincts reporting votes, as reported via the 'precinct_by_vote_type' list in the precinct_metadata .json files does not match the the number reported via the 'precincts_reporting' element for the state in the NYT votes remaining page .json file and in fact, it is never even close, as can be seen in the screenshot below. Likewise the vote totals based on the 'precinct_by_vote_type' list do not match those based on the 'county_by_vote_type' list in the precinct_metadata .json files and neither the aggregate of the county vote totals. This indicates manipulation in the county wide vote numbers which are not derived from the precinct reported vote numbers.

Uncounted Mail-in ballots discrepancy

Pennsylvania precinct_metadata json files also include an 'uncounted_mail_ballots' count for each county specified in the 'county_totals' list. As seen in the screenshot below, I observed at row 8249 in the spreadsheet that the total number of uncounted mail-in ballots reported here at the beginning (i.e. on 11/04/20 5:43:27 AM EST or 10:43:27 AM UTC) was 1,435,289. Then as expected the count started decrementing as these ballots were counted. But then at 11:50:51 AM EST there was an infusion of 302,581 ballots to this count to bring this number to 1,224,287. Where did these extra 302,581 ballots come from that were not included in the beginning? It is interesting that the 1,435,289 initial uncounted mail-in ballot count number is closer to the original 1,462,302 mail-in ballot returned count that was posted on PA SOS website and later deleted, as tweeted by PA Senator Mastriano after the hearing on PA election irregularities. This abrupt huge change in the number of uncounted mail-in ballots in the middle of counting votes could be an indicator of fraud to infuse illegal mail-in votes.

There are more instances of uncounted mail-in ballot counts increasing, indicating possibly more fraudulent mail-in ballots getting infused. Below are spreadsheet screenshots showing these instances. The second infusion of 65,853 mail-in ballots occurred at 12:14:47 PM EST the same day on 11/04/20. The third infusion of 1,404 mail-in ballots occurred days later at 12:13:22 PM EST on 11/11/20. So, in total 369,838 possibly fraudulent mail-in ballots got infused.

I found another discrepancy in the individual uncounted mail-in ballot counts for the counties in the precinct_metadata files. Towards the end when the statewide total uncounted mail-in ballot count stops changing several counties show negative uncounted mail-in ballot counts, thereby indicating that more mail-in ballots were counted in those counties than the number of available uncounted mail-in ballots. This is shown in the first screenshot below. The counties which show the most number of negative uncounted mail-in ballots are Delaware (1250 ballots) and Chester (1083 ballots) counties. In fact, some of these counties start showing negative uncounted mail-in ballot counts even when the statewide uncounted mail-in ballot counts are changing, as seen in the second and third screenshots below, from the precinct_metadata file saved at 12:13:22 PM EST on 11/11/20, when the last infusion of possibly fraudulent mail-in ballots (as indicated by the uncounted mail-in ballot counts increasing) occurred. I have not tracked the uncounted mail-in ballot counts individually for all the counties and it is possible if those counts are looked at closely more instances of mail-in ballot infusions in some of the counties can be found, while the uncounted mail-in ballot counts in other counties kept decreasing as the ballots were counted.

Arizona

Evidence of Vote count manipulation in Maricopa County

Maricopa county is the only county in Arizona that uses Dominion voting equipment. A line chart showing the plots of Biden and Trump election day candidate vote counts, from CountyVoteCounts.csv, against each other are shown below. The line chart shows a set of connected straight lines on which multiple vote count updates occur, which implies that the vote update ratio between the 2 candidates remains constant across multiple updates plotted on each line encompassing hundreds of thousands of votes, which is an un-realistic anomaly. Also, the election day vote counts anomalously go down multiple times along couple of these lines and the behavior is explained in the following paragraphs.

The election day vote count update sequence for Maricopa county on the Trump vs Biden plot is shown in the following slides with the Y axis values showing up in bold on the label for each data point.

MaricopaCountyAzVoteCountManipulation.pptx

In the above sequence there are 3 instances (between slides 4 & 5, 6 & 7 and 8 & 9) when the election day vote counts for both the candidates go down. A look at the CountyVoteCounts.csv spreadsheet entries corresponding to the above changes (see spreadsheet screenshots below corresponding to each change) reveals that the election day votes deleted here are switched over to absentee vote counts. For instances 1 and 2, the exact number of votes added to the election day vote counts are also added to the total vote count and in the next update the same number of votes are transferred to the absentee vote columns. However, for the third instance when votes are added to the non-absentee vote columns before being transferred to the absentee vote columns in the next update, the total number of non-absentee votes and total number of votes actually go down (as seen in the third screenshot below). This could have happened only if there was some manipulation in the number of write-in votes. So, I looked at the NYT votes remaining page JSON snapshots (accessible via copy saved in '_cache' subfolder with filename listed in 'Votes_Remaining_File' column entry) before and after the vote infusion and saw that the write-in votes had been purged when the votes were infused, as shown in the screenshots below the spreadsheet screenshots. So, basically out of the 7,463 write-in votes purged 5,291 votes were illegally converted into the other candidate election day votes, which in turn were moved into their absentee vote columns in the next update. This resulted in a reduction in the total and election day vote count of 2,172 votes. I also noticed that 'results_absentee' json list for Maricopa county does not have any "write-ins" vote count, while Pima county that has a lower population than Maricopa county has absentee write-in votes, as expected. This is smoking gun proof of vote count manipulation by Dominion vote counting/reporting software, as here they were caught red-handed manipulating write-in vote counts into absentee vote columns for candidates, while the absentee write-in votes had already been purged. This makes all the other absentee vote infusions that are being made via first masquerading them as election votes suspect and they are not likely real absentee votes.

On the other hand, a realistic voting pattern is seen in the election day vote count plots for Pima and Yavapai counties that do not use Dominion voting equipment and their plots are shown below, where as expected the ratio between the candidate votes added changes frequently across the vote count updates and there are no vote deletion shenanigans.

Absentee ballot processed count more than mail-in ballot returned count

The absentee ballot count analysis from Arizona shows that in the final update on 11/30/20 the total Absentee Vote count reported for the state was 2,987,296 votes while the unchanged aggregate of total Maximum Absentee Votes reported by all counties throughout all vote reporting was 2,359,547 votes. This can be seen in the spreadsheet screenshot below. It is not clear what Maximum Absentee Votes refers to as reported here. If it shows the number of mail-in ballots returned then clearly it is less than the number of absentee votes counted, which shows fraud. The number of reported absentee votes is still more by 322,610 votes than the latest returned mail-in ballot count of 2,664,686 as reported by Data Orbital. So, this is irrefutable evidence of mail-in ballot fraud large enough to overturn the result of this election.

Georgia

Early Votes Stolen and converted to Absentee votes in Fulton County

CountyVoteCounts.csv - Excel 2020-12-20 18-17-48.mp4

The above video presents evidence of early votes being stolen and converted to absentee votes in Fulton County, Georgia, from the vote counts extracted into the CountyVoteCounts.csv spreadsheet, after update #5 described at a previous section about the NYT-2020-Vote-Count_Tracker GitHub project used for this analysis.

Evidence of more Vote count manipulation in Fulton County

Fulton county like all other counties in Georgia used the Dominion Voting System which was deployed statewide by Georgia Secretary of State Raffensperger. A line chart showing the plots of Biden and Trump election day candidate vote counts in Fulton County, from CountyVoteCounts.csv, against each other are shown below. The line chart shows a set of connected straight lines on which multiple vote count updates occur, which implies that the vote update ratio between the 2 candidates remains constant across multiple updates plotted on each line encompassing hundreds of thousands of votes, which is an un-realistic anomaly. Also, the election day vote counts anomalously go down multiple times along multiple lines, as seen in the structure at the center of the line chart and the behavior is explained in the following paragraphs.

The election day vote count update sequence for Fulton county on the Trump vs Biden plot is shown in the following slides with the Y axis values showing up in bold on the label for each data point.

FultonCountyGAVoteManipulation.pptx

In the above sequence there are 6 instances (between slides 4 & 5, 7 & 8, 9 & 10, 11 & 12, 13 & 14 and 18 & 19) when the election day vote counts for both the candidates go down. A look at the CountyVoteCounts.csv spreadsheet entries corresponding to the above changes (see spreadsheet screenshots below corresponding to each change) reveals that the election day votes deleted here are switched over to absentee vote counts for all the instances except the last one. For the last instance, the same number of votes that were added in slide 18 are just deleted in slide 19. For all the other instances except the first one, all the votes added to election day vote columns in the first slide are transferred to absentee vote columns in the next slide. For the first instance not all the votes added to election day vote columns in slide 4 are transferred to absentee vote columns in slide 5. Also, a look at the NYT votes remaining page JSON snapshots (accessible via copy saved in '_cache' subfolder with filename listed in 'Votes_Remaining_File' column entry) corresponding to each update reveals that both election day and absentee "write-in" vote counts are 0, which is a statistical impossibility, considering the hundreds of thousands of votes that were added. This can be seen in the NYT votes remaining page JSON snapshot posted below the spreadsheet screenshots. This clearly leaves only one possibility and that is Dominion SW is illegally stealing the write-in vote counts and stuffing them into the absentee vote counts, like was observed in the data for Maricopa County, Arizona. This makes all the 461,979 absentee votes counted in Fulton county suspect and potentially fake.

Conclusion

As demonstrated above there is evidence beyond reasonable doubt of illegal vote count manipulation by vote counting/reporting software used in multiple states, indicative of systemic issues in this election. The data shows that upwards of a million votes were thrown out or switched in Pennsylvania and several thousand in the other states. Also, as shown in the previous section there is smoking gun evidence of stealing write-in votes and infusion of fake absentee vote counts by Scytl and Dominion reporting software. A full audit and hand recount of all legal ballots cast in the affected states should be done, to ensure that legal voters are not disenfranchised. Hopefully, law enforcement agencies will further investigate these irregularities and the voting machines and software that facilitated this fraud and the companies that developed them will be banned from further participation in any other election.