Fractional Texas
Fractional Texas
Normally, I write 1–3 posts per week on the ZarkFiles. For the past 10 days, it’s been one every day, and I’m about to do it again. Please don’t expect this to continue indefinitely. I have a lot of other projects I have to deal with to put food on the table, but as long as mysteries remain in Bexar County, I’ll be thinking about them. That will yield fresh posts on the Zark Files, which until about 12 days ago, discussed all sorts of subjects that had nothing to do with Bexar County.
This morning’s subject — which got me out of bed after 5 hours of sleep — is the fractional ID numbers. I had been accepting the idea that the fractions were used to differentiate the synthetic records from valid IDs, making them easy to find and delete. A convenient tag. But there is a problem with that explanation: the fractional IDs all occupy a portion of the number space that is already cleanly separated from every legitimate Texas voter registration. The void alone is sufficient segregation. Fractions are unnecessary for that purpose.
Therefore, there is a different reason for them. The algorithm that created these records is too precise to be accidental in any of its other features, and I do not believe the fractions are accidental either. Consider: if the starting and ending values were whole numbers, division of the span by 4,109 would still produce fractional gaps between records — that is arithmetic inevitability when dividing large numbers by a divisor that doesn’t divide evenly. The intermediate values would be fractional regardless. But the first and last values would remain clean integers. They are not integers. Both endpoints carry a fractional component that terminates at exactly five decimal places — which means they were assigned, not computed.
So what are they for?
The Void Is Already Enough
To understand why the fractions require explanation, it helps to state precisely what the void accomplishes without them.
The Texas statewide voter roll contains 18.3 million records. Within the ID space those records occupy, there is a gap: the last legitimate voter before it sits at ID 1,222,380,331, and the next legitimate voter after it resumes at 2,000,050,898. Between those two numbers — a span of approximately 777.7 million consecutive IDs — there is not one registered Texas voter. Not in Bexar County. Not anywhere in the state.
The 4,110 synthetic records were placed inside this void, running from approximately 1,253,115,467 to 1,343,862,000. Any database query filtering for IDs in that integer range returns exactly these records and no others. A simple range query retrieves all of them with zero false positives and zero false negatives. No fractional arithmetic required.
The fractional component adds nothing to that deletion operation. The void does the work on its own.
Ruling Out Innocent Explanations
Before going further, it is worth asking whether any normal software process could innocently introduce fractional IDs to these specific records.
The answer is no, and the reason is specific. Every process that could innocently introduce fractions to an ID field — a type conversion, a format mismatch during import, a database migration with a schema change — acts indiscriminately. It affects every record that passes through it. It does not know which records are originals and which are copies.
But that is precisely what we have here. The 735 anchor records — the originals — have clean integer IDs. Their addresses are real. These people actually voted. The 4,110 copies of those records have fractional IDs. The fraction appears in the copies and only in the copies, while the records they were derived from sit right alongside them with integers intact.
No innocent process makes that distinction. No migration, no export error, no type coercion looks at a record and says: this one was here first, so I will leave its ID alone; this one is derived, so I will give it a fractional ID. That discrimination requires intent. It requires code that treats the two populations differently by design.
The fractional endpoints confirm this further. A process that accidentally introduced fractions through arithmetic would produce whatever fractions the arithmetic dictated. It would not produce values terminating at exactly five decimal places. Clean termination at five places is a formatting decision, made by a programmer, applied to a value that was assigned rather than computed.
What the Void Can and Cannot Do
The void handles one problem cleanly: separating synthetic records from real ones for deletion purposes. Integer blocks within the void could handle a second problem: separating one county’s injection from another’s, so that cleaning up Bexar County’s records does not accidentally sweep up records belonging to a different jurisdiction.
Under an integer block model, each county’s injection occupies a non-overlapping sub-range of the void. No two counties share integer space. No fractional arithmetic is required. The separation is guaranteed by construction.
This raises the question of capacity. Bexar County is one of the largest in Texas. Its injection of 4,110 records spans approximately 90.7 million IDs — but it does so at a density of one record per roughly 22,085 IDs. That is extraordinarily sparse. Most Texas counties are far smaller. A county generating 300 check-in records on an early voting day would span only a few million IDs at similar density. The 777.7 million ID void, parceled into county-sized blocks, could accommodate a substantial number of Texas counties — not just seven or eight, as it might seem at first glance, because most counties would require only a fraction of the space Bexar occupies.
But here is the thing: if integer blocks handle county separation, and the void handles deletion, then neither mechanism requires a fractional seed. The fractions remain unexplained.
The Collision Problem
One might ask whether interleaving county records within the same integer range — rather than assigning separate blocks — could work, with the fractional seed serving as the county identifier. On this model, two counties could occupy the same integer range, their records interlaced, each county’s records identifiable by its unique decimal value.
The problem is collisions. County A’s sequence generates thousands of distinct fractional values as the gap accumulates through 4,110 records. County B does the same, with a different starting seed and almost certainly a different gap — because the gap is derived from that county’s own span divided by its own record count, and both of those figures vary by county size and daily turnout. Two sequences built from different seeds and different gaps will fan out at different rates through the ID space. Whether any value from A accidentally matches any value from B cannot be guaranteed without checking every pair — a combinatorial problem that scales badly across 254 counties and becomes essentially unmanageable.
Integer block separation avoids this entirely. The sequences never share integer space, so no collision is possible regardless of what fractional values the arithmetic produces. It is the only architecture that provides a clean guarantee.
Which means the fractional seed is not doing collision avoidance. It is not doing county identification in any operationally reliable way. It is not doing deletion tagging. Every functional requirement is already handled by the void and by integer blocks within it.
And yet someone initialized this sequence at 1,253,115,467**.79993** rather than 1,253,115,467**.00000**.
What the Algorithm Knew That the File Did Not
One further detail bears on this question, and I only remembered it last night.
The synthetic records were generated by sorting the 735 anchor voters alphabetically by last name. Abel sorts first; Braswell sorts 435th; the entire sequence is organized around that last-name order. I have described this in previous articles.
What I had not fully processed until now is that the file I received from Terry Richardson does not have a last name field. It does not have a first name field or a middle name field. It has a single concatenated full name field — first, middle, last, all in one string.
There is no way to sort that file by last name without first writing code to parse the last name out of the concatenated string. That is a non-trivial operation — we know this because the injection algorithm itself failed to parse names with generational suffixes correctly, misidentifying “BARR JR” as having the last name “JR.” Parsing last names from concatenated strings is exactly the kind of operation that produces bugs.
Terry Richardson did not sort the file by last name. She could not have, without tools she almost certainly did not have. The file’s native sort order — by concatenated full name — was the only sort available to her.
Which means the algorithm was not working from the same file. It was working from a version of the data in which names existed as discrete parsed fields, or it performed that parsing itself as an internal step. The public-facing export does not expose individual name components. Something upstream of that export does.
This is consistent with back-end database access — the kind of access where voter records exist in normalized tables with separate fields for first name, last name, address, and ID. The file Terry Richardson downloaded is a flattened export of that data. The algorithm operated on the data before it was flattened, or on a system that retains the structured form.
The fraction was assigned at that level. Whatever .79993 encodes, it was encoded by something that had access to the data in a form the public never sees.
What We Do Not Know
I want to be honest about the limits of what the data establishes.
The void is documented. The integer endpoints are documented. The fractional seed is documented. The fact that the seed was assigned rather than computed is established by its clean five-decimal termination. The fact that no innocent process could have introduced it is established by the copy-versus-original asymmetry.
What .79993 encodes is not established. It could be a county identifier in a system that uses decimal seeds as addresses — in which case other Texas counties’ injections, if they exist, will carry different seeds and those seeds will be findable. It could be an operator or version identifier, encoding who ran the tool or which deployment authorized it. It could be something that interfaces with a validation or routing pathway in the KnowInk or ePulse system that we have not yet identified.
What it is not: a deletion tag, a collision-avoidance mechanism, or an arithmetic accident. Those explanations have been ruled out. The void handles deletion. Integer blocks handle separation. And the intermediate fractions were going to appear regardless of what the endpoints were initialized to.
Someone chose .79993. They accepted the forensic risk that fractional IDs visible at full precision would flag every synthetic record to anyone who looked carefully. They made that choice because the alternative — clean integer initialization — would not have given them whatever .79993 gives them.
That is what we know. What it gives them is the question that remains open.
If you have pollbook data from any other Texas county showing fractional State IDs in the void space — between ID 1,222,380,332 and 2,000,050,897 — I would very much like to see it. The seed value of that county’s injection, whatever it is, would tell us more about this architecture than anything else currently available.
I’m seeing turnout percentages in the Texas SD3 race that raise question in 3 counties where I would have expected RW to perform higher overall than tallies, but esp on Election Day. the turnout on ED is exactly 0.2% different from EV Turnout in each of those 3 counties and similar results in other counties.
Thank you for this!