18a — Vote Reporting in Georgia: the Advance-Voting Tabulator Gap

18a.2 — Two kinds of tape are in a Georgia batch

18a.3 — The election‑day tapes join perfectly

An election‑day scanner only ever sees one precinct’s ballots, and Georgia’s official export reports results per precinct, broken out by voting method (Election Day, Advance Voting, Absentee by Mail, Provisional). So a precinct tape lines up exactly with that precinct’s “Election Day” column. That is why all six matched, candidate‑for‑candidate.

18a.4 — Why the advance‑voting tapes can’t join the published results

Advance voting breaks the one‑scanner‑equals‑one‑precinct assumption in both directions:

• The tape mixes many precincts. A single advance‑voting scanner accepts voters from every precinct in the county. Each voter casts their own home‑precinct ballot, but they all run through the same machine. The tape shows that scanner’s combined totals — a slice of dozens of precincts blended together.
• The official results split advance votes back out by home precinct. Georgia does not report advance votes by scanner or by advance‑voting location. It attributes each advance ballot to the voter’s home precinct and reports it there, under that precinct’s “Advance Voting” column. (In the data, every precinct is a real geographic precinct — there are no virtual / per‑location precincts for advance voting.)

So the thing the tape measures (one scanner’s blended total) and the way the county reports (each precinct’s scattered advance votes) never line up to a single number. There is no row in the official results that equals “the votes this advance‑voting scanner counted.”

// official export → localResults["Cobb County"] → ballotItems["US Senate - Rep"]
"ballotOptions": [ {
  "name": "Mike Collins",
  "precinctResults": [ {
    "id": "AC1A", "name": "Acworth 1A", "voteCount": 257,
    "groupResults": [
      { "groupName": "Election Day",     "voteCount": 128 },
      { "groupName": "Advance Voting",   "voteCount": 128 },   // ← the deepest grain there is
      { "groupName": "Absentee by Mail", "voteCount": 1 },
      { "groupName": "Provisional",      "voteCount": 0 }
    ] }, … 147 more precincts — and never a per-tabulator entry
  ] } ]

18a.6 — The remedy: request the cast‑vote records grouped by tabulator

The deepest grain Georgia publishes is precinct × method — but that is not the deepest grain the county holds. Every ballot is recorded, anonymously, in the tabulation system's cast‑vote records (CVR), and every CVR row carries the tabulator that scanned that ballot. So the county can produce the advance results grouped by tabulator: the same certified ballots already in the per‑precinct totals, merely re‑sorted by scanner. That is a standard Results‑by‑Tabulator / cast‑vote‑ record export from the Dominion reporting system, and it is exactly the unit a poll tape represents. A public‑records request for it — drawn narrowly, seeking no figure the county withholds for voter privacy (see the mock‑up in §18a.10) — is all it takes.

The export is one row per ballot. Only a few columns matter for this purpose — the tabulator, the counting group, and a 1/0 flag for each contest‑choice:

// Cast-vote records — one row per ballot (anonymous; no voter identity)
TabulatorNum   CountingGroup      PrecinctPortion   │ "US Senate-Rep│Collins"  "US Senate-Rep│Dooley"  ...
="2045"        "Advance Voting"   Big Shanty 01     │          1                       0            ...
="2045"        "Advance Voting"   Mableton 3A       │          0                       1            ...
="2045"        "Advance Voting"   Kennesaw 5A       │          1                       0            ...
="1745"        "Election Day"     Kennesaw 5A       │          0                       1            ...
  ↑ tabulator     ↑ the group        ↑ home precinct     ↑ one 1/0 column per contest × choice

Aggregating is mechanical: keep the rows whose CountingGroup is Advance Voting, group by TabulatorNum, and sum the 1/0 columns. Each tabulator's rows collapse into one block of candidate totals — precisely the block an advance‑voting tape prints. (The home‑precinct column is still there, which is what lets the county also publish the per‑precinct view; we simply don't group by it.)

The same worked example, now resolved

Recall tape #5091 (AV‑Northeast ICP 1), whose 828 Collins / 1,137 Dooley the published results could only scatter across a hundred‑plus precincts. Its tabulator is CVR tabulator 2045; aggregating that tabulator's advance ballots yields a single block that lines up with the tape to the vote:

The very numbers this chapter earlier called "impossible to compare" now have an exact official partner — not by redistributing the tape, but by asking for the certified data in the shape the tape is already in. The matching ballot count (2,434) is a second, independent confirmation: it verifies the tape was joined to the right tabulator before a single candidate total is checked.

The full result across all 18 tapes

Each of the 18 advance tapes was joined to its tabulator by the tabulator ID printed on the tape, cross‑checked by matching the tape's printed ballot count to that tabulator's advance‑ballot count in the CVR. Every tape found its partner: seventeen matched on their printed "Total Scanned" line, and the eighteenth (#5099) matched exactly on its "Total Voters" line (1,618) while its separate "Total Scanned" line prints 1,818 — the tape's own two count lines differ, and the CVR agrees with the voter count. So the join itself is validated 18 times over. Then, candidate for candidate:

As expected with AI transcription of hand‑held video, some values were flagged as first‑pass non‑matches — every one a transcription artifact, concentrated on a few advance tapes that had bowed away from the wall, curving the paper and making digits hard to read. Each resolved to the certified value once the frame was re‑read by hand and checked against the tape's own printed arithmetic. None was a reporting difference — ordinary noise in the reading process, handled by the human review the pipeline is built around. Combined with the six election‑day tapes (88 of 88), the Cobb analysis reached 260 of 260 comparisons matching, 80,449 votes audited, zero discrepancies — the advance vote confirmed to exactly the standard as election day, once the reporting grain was no longer in the way.

18a.7 — When the county won't (or can't) provide per‑tabulator data

The records request is the clean fix, and it is the one to reach for first. But if a jurisdiction declines it, or supplies it slowly, two weaker checks are still available from the tapes alone — worth knowing because they need no official cooperation at all:

Fallback 1 — Aggregate reconciliation (needs the complete set of scanners)

Forget matching each tape: could we sum across tapes and compare totals? There is a clean arithmetic identity, because every advance ballot was scanned on exactly one advance‑voting machine:

So a county‑level reconciliation is possible in principle. It wouldn’t prove per‑precinct attribution, but it would confirm the rollup — that the reported countywide advance total equals the sum of what the machines actually printed at close, catching aggregation or upload errors. Two things have to hold, and in this dataset one of them doesn’t:

• You need the complete set of every scanner in the county. The identity only holds if all advance‑voting machines are captured. Our 18 are a volunteer‑filmed subset, so their sum is a floor, not a match. Confirming completeness means accounting for every advance‑voting tabulator Cobb deployed (e.g. by machine serial number).
• You need a clean countywide advance total to compare against — and this export doesn’t contain one. The same gap that affected the precinct tapes: many precincts publish no per‑method breakdown — for US Senate‑Rep, 41 of Cobb’s 148 precincts (about 28% of all per‑method cells are blank; 13 precincts report no breakdown for any contest). So summing the published “Advance Voting” cells understates the true advance total. For US Senate‑Rep / Mike Collins the advance cells sum to 7,145, but the candidate’s true countywide total is 22,869 — the by‑method cells only account for 17,455, hiding 5,414 votes in those 41 precincts. (Per the Georgia Secretary of State results portal, these blanks are deliberate: method‑level results are “hidden in cases where not enough ballots were cast to ensure voter privacy” and shown as a dash. So this gap is a permanent privacy redaction, not pending data that will fill in — and the public portal has no tabulator‑level detail either, which is why the per‑machine figures can only come from the county directly.)

The version that does have a clean official target is the all‑methods reconciliation — sum every scanner tape of every kind (election‑day + advance + absentee + provisional) and compare to the all‑methods countywide total per candidate, which is reliably published (22,869 for Collins). But that raises the bar even higher: it requires the complete set of every scanner in the county, not just the advance‑voting ones. Bottom line: a meaningful aggregate check is achievable, but only with the complete set of every scanner in the county — a much larger collection effort than this volunteer batch.

Fallback 2 — Lower‑bound checks (what a partial set can still flag)

Even an incomplete set isn’t worthless. Because each captured tape is a real subset of the county’s votes, it supports one‑directional (lower‑bound) checks that can only ever flag a problem, never falsely clear one:

• No‑contradiction bound. The sum of our captured tapes for a candidate must be ≤ that candidate’s official all‑methods total. If it ever exceeded it, something would be wrong (double‑count, mis‑scan, or an inflated official‑side number). Across all 22 candidates below, every captured sum stays within the official total. ✓
• It already corroborates the missing‑precinct gap. For four candidates our partial sum already exceeds the published “Advance Voting” figure (e.g. Collins 8,477 > 7,145) — independent evidence that the official advance breakdown is incomplete, exactly as the 41 null‑breakdown precincts predict.
• Per‑tape internal integrity. On each tape, the candidate counts should sum to the printed “Total Votes” line and the ballot‑count header — a machine‑level consistency check that needs no official data at all.

⚑ = our partial captured sum already exceeds the published “Advance Voting” figure, confirming that figure is missing precincts. *Published “Advance” is the sum of the per‑precinct Advance‑Voting cells and is understated (41 of 148 precincts omit the breakdown). The all‑methods column likewise sums the published method cells, so where breakdowns are withheld it too understates the candidate’s true total (Collins’s is 22,869) — which only makes the bound stricter. Captured sums are OCR‑derived from low‑resolution video, not de‑duplicated, so treat them as rough lower bounds — the point is the direction of each check, not the exact figure. None of this is a substitute for the per‑scanner breakdown that would make a true comparison possible.

What would it actually take for a lower‑bound check to flag a discrepancy?

Worth being precise here, because it explains both the value and the limits of the check. A flag means one thing: the votes we counted on just the machines we filmed exceed the official total for that candidate. Since the machines we captured are only a fraction of all the county’s scanners, this essentially cannot happen by ordinary means — every vote we counted is a real ballot the official total already includes, so a part cannot exceed the whole. For a flag to appear, one of these would have to be true:

• The official results omitted more of that candidate’s votes than every machine we didn’t film, combined. For Mike Collins that means the reported total falling below 8,477 — under‑reporting his ~22,869 votes by more than 63%. That is the kind of gross, obvious undercount an audit exists to catch, and nothing remotely like it appears here.
• Or — far more likely if a flag ever did appear — an error on our side: the same scanner’s tape filmed and counted twice, or an OCR/matching mistake inflating a number. We would verify and rule those out first.

So the check is deliberately one‑directional. It can only ever surface official under‑counting (or a duplicate/misread on our side); it cannot detect official over‑counting, and it can’t be tripped merely because we hold a partial set of tapes. That one‑sidedness is exactly why a clean pass is reassuring but not a full audit — and why a flag, however unlikely, would be worth taking seriously.

18a.8 — How the comparison pipeline handles both grains

Each election‑day tape joins to official results through a precinct entry (e.g. 5104 → KE2A) and is compared to that precinct's published "Election Day" column. Each advance‑voting tape joins instead to its tabulator, and is compared to that tabulator's block aggregated from the cast‑vote records (the Advance Voting group). Before the county provided the CVR, the advance tapes had no matching official unit, so the pipeline deliberately skipped them — showing 0 comparisons rather than a pile of false discrepancies — while still transcribing and archiving every one. With the CVR in hand, those same 18 tapes move from skipped to fully compared, with no change to the tapes or their transcriptions — only to the official data they can now be set beside.

18a.9 — Ballot secrecy — and why our recordings stay up

A separate question from comparison: could our own published poll‑tape recordings expose how an individual voted? Several states — North Carolina, Georgia, Florida — withhold small official totals “in cases where not enough ballots were cast to ensure voter privacy.” The underlying risk is a unanimous cell: within one reporting unit, contest, and voting method, every recorded vote goes to a single choice. A unanimous cell identifies no one on its own, but combined with a public record that an identified person voted in that unit and contest, it could reveal their vote. (A poll tape is itself a reporting unit, so the same test applies to ours — see the America Counts standard, Balancing Ballot Secrecy and Result Transparency.)

We screened every transcribed contest on all 24 Cobb tapes for unanimous cells. There are none. Every contest on every tape recorded at least one vote for each choice. (The single closest case, under the more conservative “runner‑up ≤ 2 votes” variant, is one advance‑voting contest where the runner‑up got 2 — and it still clears the strict unanimity rule.) The screen is reproducible: ava privacy-screen → exhibits/privacy_screen.md.

18a.10 — What we asked Cobb County for — and what it provided

Our records request (the letter to the Director of Elections) asked for one thing: the advance‑voting results grouped by the tabulator that counted them instead of by the voter's home precinct. This is the same set of advance ballots already in the certified per‑precinct results — just re‑sorted by scanner — and it is a standard Results‑by‑Tabulator export from the Dominion reporting system, filtered to the Advance Voting group. With it, each of our 18 advance‑voting tapes lines up 1:1 with its tabulator's block, exactly as the election‑day tapes did with their precincts. Below is the shape of that table. Cobb County supplied exactly this — as a cast‑vote‑ record export, which carries the same tabulator‑tagged ballots and aggregates to the same layout — so every (vote total) cell below is now filled in, and the comparison in §18a.6 is the result.

The request and the reply. America Counts submitted this open‑records request to the Cobb County Director of Elections on July 1, 2026, and the office replied the same day — a response we greatly appreciate. What it sent back was the county's Dominion cast‑vote‑record (CVR) export (a CSV with one anonymized row per ballot, each tagged with the tabulator that scanned it and the voter's home precinct) together with per‑tabulator Statement of Votes Cast (SOVC) PDFs. Aggregated by tabulator and filtered to the Advance Voting group, the CVR is exactly the Results‑by‑Tabulator view the request asked for.

18a.11 — The payoff: recording effort turned into transparency

Pulling the thread together: our volunteers recorded 18 advance‑voting tapes, but Georgia's published results — organized by home precinct — offered nothing to compare them against. The one thing that closed that gap was what Cobb County provided in response to our open‑records request: the Dominion cast‑vote records, one anonymized row per ballot, each tagged with the tabulator that scanned it. Aggregating those rows by tabulator (§18a.6) reconstructs exactly the per‑scanner totals a poll tape prints, so every vote total on every advance tape suddenly had an official counterpart to be checked against. The 18 tapes went from zero possible comparisons to 172, every one matching the certified count.

That is the recording work paying off. Without those records, the 18 advance tapes — 75% of our 24 submissions for this election, carrying 92% of the votes this analysis ultimately audited (73,953 of 80,449) — would have stayed uncomparable: filmed, transcribed, and archived, but unable to become evidence of accurate reporting. Hours of volunteer effort would have yielded no election‑transparency payoff, which would have been deeply disappointing. Instead, a single narrow records request converted nearly all of that effort into an independent, exact confirmation of the county's advance vote.

Worked through analysis 20260616_usa_ga_cobb (Actual Vote Assist). Election‑day join verified against the EnhancedVoting per‑precinct export; advance‑voting join verified against the county's Dominion cast‑vote‑record export, aggregated by tabulator for the Advance Voting group. “Advance Voting” is one of four voting‑method groups reported under each of Cobb's 148 precincts, none of them virtual/per‑location; the per‑tabulator grain exists only in the cast‑vote records, which is why a records request was needed.