Voter database

One record per voter. Each record carries the registration facts from your file: name, residential address, ZIP, precinct, congressional and state legislative districts, party bucket (Republican, Democrat, Independent, Unknown), registration status and date, date of birth and computed age, and a phone and email where the file had one. Two derived numbers ride on every record, a vote score counting how many of the last five general elections and the last five primaries the person voted in. Under that sit the election-history rows themselves, every raw attribute column you chose to keep from the file, the tags your team applies, survey answers captured at the door or on the phone, campaign notes, and the walk visits that touched the household.

There are two ways a campaign gets its universe. Where platform data exists for your office, the wizard offers it at signup. Everywhere else, and for most campaigns today, you upload the file you already have: a state or county voter roll, or a vendor extract from NGP VAN, L2, i360, or Aristotle. Signup never asks where you are running before letting you in, and the product is the same on both paths.

Your upload lands in a campaign-private silo. Every campaign-scoped table carries a campaign id and a row-level security policy, and the search, list, walk, and export code adds the same isolation on top. No other campaign can read your rows, and a member of two campaigns sees two separate universes. On top of that, the universe is hard-scoped to the office: a State House campaign only ever sees its district, and a county-wide race is pinned to its county, no matter what filters a user types.

Import lives under Voters and is the first item on the setup checklist and the dashboard Game Plan. It runs in four stages, and the screen tells you which one you are in.

• Upload. Drop a CSV, TSV, or TXT file up to 500 MB. The browser streams it straight to storage with a progress bar, and a checkbox tells the parser whether the first row is column names.
• Analyze. The parser detects the delimiter and encoding, reads the headers, samples values per column, and estimates the row count. Large files take 30 to 60 seconds.
• Map. Every column gets a disposition: Identity (the voter ID), Canonical key (first name, ZIP, party, and so on), Election history (wide-format columns like a 2024 general vote flag), Raw attribute (kept on the record but not promoted), or Skip. You confirm the mapping and can save it as a template for the next pull from the same source.
• Auto-map. An alias table of headers seen across L2, i360, Aristotle, VAN exports, and state files fills most columns, then a fuzzy scorer handles near-misses. Only genuinely ambiguous columns go to a small batched Claude Haiku call, and those are labeled AI so you know to check them.
• Required fields. The Continue button stays off until you have an identity, a first name, a last name, a state, and at least one of street address, ZIP, or precinct.
• Identity. A mapped voter ID (VUID, VoterID, VANID, and similar) is stable across re-imports, so a fresh pull updates rather than duplicates. With no ID column, the importer synthesizes one from state, last name, first name, date of birth, and ZIP after you acknowledge the trade-off. With neither, it runs insert-only and warns that re-importing the same file creates duplicates.
• Dedupe mode. Fresh dump overwrites field by field, newest data winning. Incremental only fills fields that are empty on the existing record.
• Validate and preview. A dry run reads a sample (the first 1,000 rows or 1 percent of the file, up to 10,000) and projects new, updated, skipped, and errored rows for the whole file, grouped by error category: missing required field, invalid date, phone, email, or ZIP, dedupe conflict. It also shows how full each canonical field is.
• Error thresholds. Above a 10 percent error rate you get a warning; above 50 percent the Execute button is blocked until you fix the mapping.
• Execute. Rows are hashed into 50 buckets and inserted in parallel with live progress and per-bucket checkpoints, so a retry picks up where it stopped. You can cancel mid-run and keep what already landed, download the error list as a CSV, and soft-delete a finished import with a seven-day undo window before a nightly job removes the rows for good.

The Voters screen opens on your full universe with its label and count in the header. A text box searches name, address, or voter ID. The filter bar covers party bucket, registration status (Active, Suspense, Inactive, Unknown), gender, an age range, ZIP, precinct, congressional, state senate, and state house district, has-phone and has-email, voted in at least N of the last five generals or primaries, and tags (any of, all of, none of). Filters live in the URL, so a filtered view can be bookmarked or pasted to a colleague. Results page 50 at a time with a running "Showing 51 to 100 of 485" label, sort by name or precinct, and switch between compact and comfortable density. Each row shows name, address, party, age, registration month, voter ID, precinct, phone and email presence, and the vote score as filled dots with the date the scores were computed.

Click a name and the detail sheet slides in with four tabs. Voter Info shows tags, identity, the address block with subdivision or neighborhood and every district, a property block where county appraisal data has been matched, and a searchable, grouped list of every attribute on the record with the source it came from. Voting History lists each election once, newest first, with party and vote method where the file had them. Survey Responses shows each session captured at the door or on a phone bank. Notes holds the campaign-private annotation keys: Receptiveness (1 to 5), Do Not Contact, Volunteer Interest, Donation Likelihood, Top Issue, Data Quality, and a free-text note. The party chip in the header follows a fixed precedence, primary-ballot history first, then a vendor party field, then the registration bucket, and clicking it shows which source produced it. Left and right arrow keys move to the previous or next record in your results.

Households are a first-class idea. Records that share a household id from your file are grouped, and where an id is missing the household view falls back to a normalized street address plus ZIP match. The walk-stop view and the household lookup return everyone at the address, up to 12 members, and only people on the current roll.

A voter whose ID is not on the latest county master roll is marked off roll and treated as inactive. That flag is enforced on every listing, count, targeting, and export surface: structured search, the AI query, saved lists, walk generation, household expansion, mail, phone banks, and texting. The search page has an "Include off-roll records" toggle that shows them with an Off roll badge, but they still cannot be added to a walk or a list. Looking up a single record by its ID still works, so the notes and history you collected are never lost.

The reason is money and volunteer time. A stale file carries tens of thousands of moved and cancelled registrations, and each one is a wasted door, text, or mail piece. Retiring them at the database layer means nobody has to remember to filter them out downstream.

Viewing voter data is a granted permission, not an automatic one. The candidate and campaign manager always have it. A staff member sees the Voters, Query, and Lists screens only when an admin has turned on the Voters tab for them. Precinct chairs get a scoped view of their own precinct with no detail sheet. Volunteers never reach voter records outside the walk they are assigned to.

Downloading is stricter than viewing. The CSV export on the search page is available to the candidate and campaign manager only. A staffer can filter, build lists, tag, and run field operations in the app, but cannot pull a bulk file. The export dialog lets you pick fields from 22 columns, with a one-click "Names and phone" preset for call lists, and every export is capped at 100,000 rows sorted by last name and hard-scoped to the campaign's district.

School board trustee, single-member district. The candidate pulls the county roll for her district, 38,400 rows, and uploads it. Auto-map recognizes 31 of 34 columns from the alias table; she confirms the three AI suggestions and saves the mapping as "County roll" for the next refresh. On the search screen she filters to voters who cast a ballot in at least two of the last five generals and gets 14,200. Adding has-phone narrows it to 6,100, which she saves as a static list for texting, and the remaining 8,100 become the walk universe.

City council, at-large, 22,000 registered. The campaign's first file is a Secretary of State export with no voter ID column, so the importer synthesizes identities. Two months later a fresh pull, this time with the ID column mapped, runs in Fresh dump mode; the dry run projects 21,300 updated, 640 new, and 12 errored rows before anything is written. Addresses and phone numbers refresh in place, and no duplicates appear.

County commissioner precinct, 95,000 voters. The manager grants two field staffers the Voters tab so they can build lists and cut walks, but neither can download the file. When the finance chair asks for a call list of 4,000 likely donors, the manager exports it with the Names and phone preset in one click. Weeks later a data-quality note from a walker flags a wrong address, and the fix lives on the record for everyone.

Local races are won by a few thousand votes, and the people who cast them are knowable in advance. Vote history is the single most predictive field on a file, and a database that computes the last-five-generals score for every record, keeps it current, and lets a first-time candidate filter on it in two clicks turns the file into a plan. If reading a file is new to you, start with how to read a voter file and how many votes it takes to win a local election.

One resolved record per voter also stops the double-contact problem that plagues campaigns running five disconnected tools. A survey answer captured at the door on Saturday is a filter for Tuesday's text, and a Do Not Contact note set on the phone bank is honored by the mail list. The data compounds across features and across weeks, which is the whole argument for an integrated system.

Honest boundaries, so you can plan around them.

• It does not source a voter file for you. Unless your office is in a geography where platform data is offered at signup, the file you upload is the universe, and its freshness is yours to manage with re-imports.
• It does not pool campaigns. Your upload is never merged with another campaign's data, even for the same district, because vendor licenses are per client.
• Off-roll records can be viewed but never targeted, and there is no override.
• Identity synthesis is exact-match, not fuzzy. If a later file spells a name or formats a birth date differently, those rows will not deduplicate.
• Some vendor-derived fields, for example an L2 party column, only display for campaigns that hold an active grant for that source.
• Caps: 50 rows per page in search, select-all up to 100,000 records, exports up to 100,000 rows, and static lists built from select-all up to 50,000 members.
• Precinct chairs do not get the detail sheet, and staff never get the export button.

The database feeds every other feature. Ask questions of it in plain English with the AI voter query, segment it with search, lists, and tags, cut it into turf with block walking, and message it through SMS outreach, email outreach, and direct mail. The isolation and export rules described above are part of the compliance and data security posture.