Select Page

How Database ID Patterns Work

Sequential IDs, data migration, and 'living' databases

 

There has been an interesting theory spreading across the election integrity universe that we felt needed some grounding in reality. It has to do with recognizing patterns, or the absence of patterns, within voter ID’s across a state. The primary thing to remember when deciding whether claims like these have merit is Occam’s Razor: The simplest explanation is usually the correct one.

The claim centers around the idea that there is a hidden algorithm within state voter ID’s that prove there is some type of fraud taking place. We love a good conspiracy as much as anybody, but there are enough factually identifiable flaws within our voting systems that wild ideas like this detract from making substantive changes. We don’t want to discourage this type of investigation and the inquisitiveness that goes along with it, we just prefer to not make inflammatory claims based on an assumption without doing our research first.

There seems to be a basic misunderstanding of how ID assignment in a working database is handled, in particular one that has been subject to complete data migrations between older and newer systems.

Imagine a county has a filing cabinet with folders for every registered voter, numbered 1, 2, 3, 4… all the way up, in the order people registered over the years.

Now the county decides to move everything into a new statewide computer system. To do that, they take every single existing folder and load them in, one by one, giving each one a new ID number in order 1, 2, 3, 4… This happens all at once, during the move. So naturally, those original records will have IDs that look neat and sequential. Then the next county that joined the system loads their records, but the first county already used 1, 2, 3, 4, so the second county has to use 5, 6, 7, 8. Eventually a little later a new person registers to vote in the first county, this new voter is assigned number 9 because 5 is already taken, and the relation between county and ID number begins to splinter.

The database doesn’t stop after the first record sets are moved to the new system. New people register, people move and update their address, names get corrected. Those new entries get added after the move, so their ID numbers come from a different point in the sequence and they don’t fit the original pattern, because they were never part of the original move.

That’s not a glitch or fraud. That’s exactly how it’s supposed to work.

What this person has “discovered” is the difference between:

  • Records that existed before the system was built (sequential, neat)
  • Records that were added or changed after (later numbers, different pattern)

Below is an explanation of how ID’s are assigned and how the relation between sequential ID’s can shift over time and how the source of these claims discovered in a very, very, roundabout way that these voter databases are functioning exactly as expected.

When a database is first built, or an old database is migrated into a new system, all existing records are imported at once and given clean, sequential IDs. Any records added or changed after that point will naturally fall outside the original pattern because they were created at a different time. It is how every modern database works, no flaw, hidden algorithm, or evidence of fraud on it's own.

Example 1
Voter Registration Database
๐Ÿ—ณ๏ธ
Step 1

Old system: records exist with legacy IDs

Thousands of voter registrations exist in the old system, organized by county and date. They have their own internal reference codes.
OLD-A
Smith, Jane
OLD-B
Johnson, M.
OLD-C
Patel, R.
OLD-D
Garcia, L.
OLD-E
Williams, T.
โ€ฆ
thousands more
โ†“
Migration Day
Step 2

All records imported into the new system at once

Every record from the old system is loaded in bulk and assigned a brand new sequential ID: 001, 002, 003โ€ฆ in order. This happens on a single day.
001
Smith, Jane
002
Johnson, M.
003
Patel, R.
004
Garcia, L.
005
Williams, T.
006โ€“890
โ€ฆall others
Result: IDs 001 through 890 are perfectly sequential and follow a clean, uniform pattern because they were all created in a single automated batch on the same day.
โ†“
Weeks, Months, Years Later
Step 3

Real life continues, new registrations and changes are added

People move and update their address. Name corrections are made. New voters register. Each gets the next available ID number from wherever the counter currently sits, at different times from different offices.
001
Smith, Jane
002
Johnson, M.
003
Patel, R.
โ€ฆ
890
Williams, T.
891
Torres, A. ๐Ÿ†•
892
Patel, R. โœ๏ธ moved
893
Kim, S. ๐Ÿ†•
894
Brown, D. ๐Ÿ†•
What a conspiracy theorist sees: IDs 001โ€“890 follow one clear pattern. IDs 891+ break that pattern. Therefore: hidden algorithm, secret manipulation, fraud! What is actually happening: IDs 001โ€“890 were assigned in one automated batch on migration day. IDs 891+ were assigned one at a time, on different days, by different county offices, as normal life events occurred. There is no hidden pattern. There is a calendar.
Migration-era record (imported on day one)
New registration added after migration
Existing record updated or corrected
Legacy system record (pre-migration)
Example 2
Company Sales Records
๐Ÿ’ผ
Step 1

Company starts with one salesperson: Alex

Every sale Alex makes gets the next order number in sequence. The pattern is simple and clean: all Alex's sales, one after another.
1001
Alex
1002
Alex
1003
Alex
1004
Alex
1005
Alex
Observed pattern: All records are sequential and all belong to Alex. If you were to sort by salesperson, you would see a perfect, unbroken run.
โ†“
New Hires Join the Team
Step 2

Two more salespeople join: Beth & Carlos

Now all three log sales throughout the day. Order IDs keep counting up in sequence but they're no longer all from Alex. The numbers interleave across all three salespeople.
1001
Alex
1002
Alex
1003
Alex
1004
Alex
1005
Alex
1006
Beth ๐Ÿ†•
1007
Carlos ๐Ÿ†•
1008
Alex
1009
Beth ๐Ÿ†•
1010
Carlos ๐Ÿ†•
1011
Alex
1012
Beth ๐Ÿ†•
If you filter to only Alex's sales: 1001, 1002, 1003, 1004, 1005 then 1008, then 1011. The sequence has gaps! Orders 1006, 1007, 1009, 1010 seem to be "missing" from Alex. Nothing is missing. Beth used 1006 and 1009. Carlos used 1007 and 1010. The gaps in Alex's sequence are simply other people doing their jobs. Filtering to one person and calling the gaps suspicious is the same flawed logic.
Alex's sales
Beth's sales
Carlos's sales
Example 3
Online Store Product Catalog
๐Ÿ›’
Step 1

Store launches with an existing product catalog

On launch day, all 200 existing products are loaded into the new store system at once. Each product is automatically assigned a sequential ID.
P-001
Blue T-Shirt
P-002
Black Jeans
P-003
White Shoes
P-004
Red Hat
P-005
Gray Jacket
P-006โ€ฆ200
all others
Launch-day pattern: P-001 through P-200 are all sequential, all assigned on the same day, all part of the original catalog load.
โ†“
Store Opens & Grows Over Time
Step 2

New products and seasonal items are added over time

New products are added after launch. Items are re-entered with new SKUs after a product refresh. Returned items that become re-sellable get new catalog entries. All of these get the next available ID.
P-001
Blue T-Shirt
โ€ฆ
P-200
Gray Jacket
P-201
Summer Dress ๐Ÿ†•
P-202
Linen Shorts ๐Ÿ†•
P-203
Black Jeans (new SKU) โœ๏ธ
P-204
Canvas Bag ๐Ÿ†•
Products P-001 to P-200 were all assigned at launch. Products P-201 onward were added later, one at a time, as the business grew. A "pattern" in the first 200 IDs is simply a snapshot of launch day it proves nothing suspicious about the ones that came after.
Launch-day catalog products
New products added after launch
Re-entered or updated records

The Bottom Line applies to every example above

Any living database will show a clear, orderly pattern among its earliest IDs that is the migration batch created all at once during a single process, or the original inputs. After that point, IDs are assigned one at a time as real events occur: new people register, employees join, products are added. Those later IDs do not follow the original bulk pattern, because they were never part of it. Calling this a "hidden algorithm" is like noticing that the area code 479 covers northwest Arkansas, 480 covers the East Valley in Arizona, and 481 is in Houston. They werent partitioned and reserved in sequential state order from the beginning They were added later as the need arose. The numbers reflect reality. That is the entire explanation.