I think the relation between the two topics is the assumption that it's the same puppeteer pulling the strings of both subjects' narratives. Also, the vaccine topic is mechanically much easier to visualize for laymen/amateur investigators.
I'm pushing the puppeteer imagery and cross-lines-communication imagery to emphasize that your skillset might be exponentially useful in locating the proverbial 'factory' where these directives/narratives are coming from. I don't imagine you've spent a lot of thought on that - (if I'm assuming correctly) Why?
You are right of course. The fake vaccines and the fake elections are connected. Maybe it's just that I'm so focused on the election that it's difficult to shift gears sometimes. I think a colleague may have identified where the election software was generated. Or at least, the company that was supposed to make it. Whether the version I see reflects that work or the work of an intruder remains to be seen.
I did not notice the question earlier whether there was a psychic element to discovery of the algorithm. Overtly, my answer is no. The problem is that almost anything can be described as "psychic". The simple act of moving any part of your body can be described as psychokinesis because you are using mental directives to manipulate a physical object (your body). Speech can be viewed as partly telepathic. For instance, have you ever noticed how it is more difficult to follow what someone is saying if they are reading from a document instead of speaking extemporaneously? If they are thinking about the subject while they speak about it, it is easier to understand than if they aren't mentally engaged with the words. This is true even when the document in question is written well and extemporaneous speech is ungrammatical. This may be the feat accomplished by good actors: investing their reading of lines with authentic mental energy to aid in understanding.
As for the algorithm, I don't deny it is very well hidden. To my knowledge, I am the first person to discover anything like it in the country. Since then, I have spoken to groups in other states and they have started looking. Of those efforts, I only know of one that may have been successful, in Hawaii. The person who spotted it is in Pennsylvania and we've discussed the NY algorithm many times. In Hawaii's case, it wasn't the sort of complex algorithm I found in NY and NJ, but a 12 digit alphanumeric tag used in place of the last 12 digits of an approximately 24 digit UUID.
I have found things in what might be described as "lucky" circumstances many times. Sometimes, the circumstances are so unusual that they invite questions whether there was a psychic element. The algorithm discovery is one of those but from my perspective, it has less support than other examples I could name. That said, here is a breakdown of hw it came about:
1) in November/December 2021, I realized that phantom voters in the voter rolls have no value without an efficient and clandestine method to track and interact with those records.
2) In April, 2022, I was looking for something else when I noticed that certain SBOEID numbers were more likely to be associated with a specific county than any other county. This was very important to discovering the algorithm. I doubt I would have spotted it except for something "lucky". When I imported the data into my custom database, I was only able to load about the first 8.5 million records out of almost 21 million records. If I had loaded the full database, it is unlikely I could have spotted the SBOEID/county connection. This is because almost all of the records I had were in range numbers and almost all of the missing records were out of range. Meaning, I had a nearly complete set of records that used the algorithm I discovered first, without the flak thrown up by all the other numbers, which used a different algorithm. Why I couldn't load the full database I don't know. I later discovered that it wasn't a space limitation and that the software could load the entire file but I had done it incorrectly, causing it to stop loading almost precisely at the end of the in range records.
3) After discovering the in range/out of range partitions, I was able to map out a rough picture of how the in range numbers were divided into 67 sub-partitions. There are 62 county partitions and 5 empty "buffer zones". I sent that work to a programmer who had access to the full database and he was able to find the exact boundaries for each partition. This part of the effort was, in my view, pure brute force pattern recognition on my part.
4) For the next several months, I worked on the algorithm with a colleague. The way it worked is that I studied the data looking for clues to how the algorithm worked, then passed my findings to the programmer, who tested them on the database. We were eventually able to reproduce exactly what we saw in the voter rolls with our own code. However, a few counties required manual offsets added to the code. This where the second "lucky" break occurred.
5) In July, 2022, I was working on the algorithm when an electrical storm knocked out my power. My USP did not kick in because, unknown to me, when I'd had my computer upgraded a few months earlier,someone (me or the person who upgraded the machine) accidentally plugged my computer directly into the wall. I didn't notice because all of the UPS slots were in use. This was a key lucky break though it didn't look that way at the time.
When the power came back on, I discovered that my file had been corrupted. I had to rebuild it from scratch. It took almost a week but managed to get the database back to approximately the same place it had been in before. And then we had another storm and the file got corrupted again. After getting it put together again, we had another storm and I lost the file a third time. All of these were lucky breaks but I was very annoyed at the time. By the time I was rebuilding it for the fifth time, I had decided to rebuild the database in discrete sections and keep good backups so that if I lost power I wouldn't lose the entire database. I divided the original 21 million record text file from the state into 21 separate files. 20 had exactly 1 million records each and the last had the remainder. To ensure I didn't enter the same data twice, I made a separate Excel file that recorded the names of voters in the first and last position in each of the files. I also added a serial number to the database so that I could keep track of the records as they were imported, so that, for instance, record number 1,000,000 in the database would be the same as the record in row 1,000,000 of the original text file.
It turned out that by importing a million records at a time, I could import all 21 million records. More importantly, that serial number I added retained the original sort order from the database. I was aware of that when I did it but my primary purpose was to check whether I'd missed or double imported any records. The result is that I could now see something that was destroyed the first time I used the database: the original sort order. It also showed me that the SBOEID sort was better than the CID sort I'd been using until then. Now, the records that needed offsets to work with our code, didn't need offsets. The problem was that counties that used alphanumeric CID numbers don't sort correctly. They are inserted in a way that cannot be reproduced using any normal sort method. The only way to see it was with the original disk order of the records, something that had been lost as soon as I started using the original version of the database. Because I had created the serial numbers, that information is retained no matter what I do to the database. It also showed that the SBOEID sort is better.
If there was any "psychic" element to this, it would be those two lucky breaks described above.
![[[p]]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7 "Wink [[p]]")