Over the past few weeks we’ve covered cutting turf, running call time, modeling turnout, and chasing ballots through a six-week election. All of it assumes the voter file underneath is right, or that you know exactly how it’s wrong. Cut a universe on a stale or misread file and the error doesn’t stay in the database. It walks out the door with your canvassers and dials out with your phone bank.

This post covers where the Romulus file comes from, how it’s put together, and what happens on a refresh. It also has a practical occasion: the latest refresh of the statewide files we maintain, New Jersey and Florida, was uploaded on August 1, 2026.

Two layers, one file

A voter file is a record of an administrative process, not a portrait of the electorate. That was the lesson of this summer’s registration mess, and it’s the founding design decision in Romulus: every voter record has two layers that never blur.

The state layer is what the government currently claims about a voter: name, address, party, registration status, districts, and the elections they’ve participated in. Romulus indexes, searches, filters, and annotates it, but doesn’t overwrite it. A voter’s registration gets fixed at the county, not in a CRM. If the state’s claim is wrong, record what you know alongside it.

The campaign layer is what you’ve worked to learn: support IDs, tags, custom fields, contact history, volunteer flags, scores. It’s scoped to your campaign, invisible to anyone else on the platform, and exportable with an audit trail.

Because the layers never mix, the state layer can be replaced wholesale, millions of rows at a time, without touching anything your team has learned.

Where the file comes from

Romulus doesn’t manufacture voter data, and the docs say plainly that it isn’t a replacement for a vendor file. You can bring one from your state party, a commercial vendor, or a secretary of state export. But in the two states where our practice lives, you don’t have to. NJR maintains hosted statewide files for New Jersey and Florida, built from the states’ own exports and refreshed monthly. Start a campaign on either and the full file is loaded on day one, with districts configured, vote history in place, and default turnout scores computed.

The two states publish very differently. Florida’s Division of Elections ships a full statewide registration and vote-history extract every month, to anyone, because Florida law makes nearly all of it public record: north of thirteen million records, more than twice New Jersey’s roughly 6.6 million. New Jersey’s export comes out of the Statewide Voter Registration System with its own habits, the best known being vote history kept as a participation ledger. There’s a row for every election a voter showed up for, and silence for every one they skipped.

Those differences get reconciled somewhere: deliberately, once, by whoever builds the file, or accidentally, forever, by everyone who queries it. We do it the first way. Both files reach a campaign in one schema, with the same statuses, district structure, and history semantics, so a universe or model that works in Bergen County works the same way in Broward.

What a refresh actually changes

An upload is not a re-import. Romulus matches the new statewide file record by record against the one you’re working, on the state’s own identifiers, and applies the differences:

  • New registrations appear, immediately searchable.
  • Changed records update in place. Movers, party switches, status flips, district reassignments.
  • Missing voters are marked, not deleted. A voter who drops out of the export flips to a removed status. Deleting the row would take your contact history and support IDs with it.
  • Vote history appends as counties post participation.

Your IDs, tags, and contact history stay where they were, attached to fresher facts.

Every record also carries its vintage: which refresh wrote it, and when. A “registered voter” in your file is really “a voter the state claimed on August 1,” and knowing the date is the difference between using data and trusting it. When the state says one address and your canvasser swears another, the file shows which claim is newer and where it came from instead of silently picking one.

Everything downstream reacts on its own. A universe is a definition, not a snapshot, so saved audiences recount against the new file the next time they’re opened. Smart tags reconcile after any import that touches voters. Published models re-score overnight as new history lands. Nobody exports a Friday file and reconciles it by hand, which is the failure mode we warned about for ballot season.

August 1, in particular

New Jersey. The June primary’s vote history, as posted by the counties. Turnout scores have recomputed with it, and a “voted in the last primary” universe now means this year’s primary. You’ll also see the first churn from the county review of the roughly 2,100 registrations referred back to election officials in July: status changes and removals arriving on twenty-one county timelines through the fall. If a county shows removals you can’t explain, check the vintage first. It’s cleanup, not turnout signal. Registration keeps moving until the October 13 deadline, so expect the file to grow through the next refresh or two.

Florida. Florida closed its registration books for the August 18 primary on July 20, twenty-nine days out by statute. So the August 1 file is the primary electorate: every voter eligible on August 18, with the registration facts the election will be run on. There’s no fresher ground truth coming before the primary. The next material change is the primary itself, when its vote history starts posting.

Both files went live in Romulus on August 1. Universes recounted on their next open, and nightly scoring caught up the same week.

The parts you never see

Anyone can load a CSV. The work is knowing what each column actually records, which counter produced it, and with what error rate. Some of what’s built into the Romulus files:

  • “Inactive” is a mail-delivery fact, not an eligibility verdict. An inactive New Jersey voter is someone whose sample ballot bounced. They can still vote. Drop them from a GOTV universe reflexively and you abandon real votes; treat them as a confirm-the-address list.
  • A missing history row is a skipped election, not missing data. New Jersey’s ledger will convince a naive query that anyone who voted once is a perfect-turnout voter. Every turnout rate in Romulus divides by the elections that actually happened in that voter’s jurisdiction: the calendar, not the file.
  • History arrives on county time. Participation posts county by county over weeks in both states, and Florida’s counties don’t all code a ballot the same way. The vintage on the history tells you whether a quiet county means low turnout or slow paperwork.
  • Removals deserve suspicion in both directions. As this summer showed, records leave the file for administrative reasons as often as human ones. A removal needs the county and the date attached before it means anything.

None of this is secret. It’s obvious in year ten and expensive in year one, and the file is where we keep it.

If you’re building on it

On the hosted New Jersey or Florida file, there’s nothing to run. Open your universes, check the counts, and skim the refresh summary for your counties. New registrants in your district are a call list nobody else has worked yet, sitting in a filter two clicks deep. If you bring your own file, the same machinery applies: the importer matches on your vendor’s identifiers, your campaign layer survives every update, and vintage is stamped the same way.

Mind the dates. Florida votes on August 18, on the file that’s already loaded. New Jersey’s clerks drop the first general-election ballots on September 19, which leaves room for about one more refresh. Cut your September program on the freshest file you can get, because from ballot drop onward the file is the scoreboard.

The docs cover search, filtering, universes, and scores.