# My zero-vote study now has a public record anyone can rerun ## Dek I republished my study of the 106 runoff sections where Flávio Bolsonaro got no votes, this time with every step on view. One program, run from start to finish, writes each number into a results file that only grows. I froze the files on 1 November, and a Bitcoin block proves they existed in that form that evening. The numbers did not change. ## Short version On 27 October 2026, Folha de S.Paulo [reported](https://www1.folha.uol.com.br/colunas/painel/2026/10/flavio-teve-zero-voto-em-106-urnas-nas-quais-somou-quase-15-mil.shtml#:~:text=n%C3%A3o%20obteve%20nenhum%20voto%20em%20106%20urnas) a study that found 106 polling sections with no votes for Flávio Bolsonaro (PL) in the 2026 runoff, which Lula (PT) won. A section is the group of voters assigned to one voting machine. Two days later I rebuilt the count from the public files and compared it with 2018 and 2022. Nearly every zero-vote section in the last three runoffs was a zero for the PL side: 328, 143 and 106, against 4 a year for the PT side. In October I asked readers to take two things on my word. One was that the plan came before the results. The other was that the numbers in the text were the numbers the code produced. You can now check the second yourself. All 135 measured numbers in the October piece trace to a results file written by the code, and anyone can rerun the code that writes it. The first still rests on my word, because I did not freeze the plan before I computed results. A second count I wrote separately, sharing no code with the analysis, gives the same headline counts from the court's files. I also reran everything without the two hand-labelled files I cannot publish, and it reproduced 133 of the 135 numbers. ## Key findings - In the 2026 runoff, Flávio Bolsonaro had 0 votes in 106 sections, in which Lula had 14,860 votes in all. Lula had 0 votes in 4 sections, in which Flávio Bolsonaro had 296 in all ([scale.csv](https://github.com/vinarise/zero-vote-sections-2026/blob/c41e4eda480c1df105cf9dffa095d7f6ab76b9ce/results/scale.csv)). These are the October numbers, unchanged. - Jair Bolsonaro had 328 zero sections in 2018 and 143 in 2022, Flávio Bolsonaro 106 in 2026. The PT candidates had 4 in each year. In 2018 and 2022 most PL-side zeros were in the Northeast, 177 of 328 and 82 of 143. In 2026 most were in the North, 65 of 106 ([zero_by_state.json](https://github.com/vinarise/zero-vote-sections-2026/blob/c41e4eda480c1df105cf9dffa095d7f6ab76b9ce/finding/zero_by_state.json)). - Each of the 135 listed numbers equals its row in the results file. All 63 published tables come out byte for byte identical to the October package ([FINDINGS.md, sections 1 and 8](https://github.com/vinarise/zero-vote-sections-2026/blob/c41e4eda480c1df105cf9dffa095d7f6ab76b9ce/FINDINGS.md)). - A second count of the raw TSE section files, in a short awk script I wrote separately with no code in common with the notebook, matches the results file on all 63 fields it covers, among them 106, 4, 143, 4, 328, 4 and Lula's winning margin of 4,430,191 votes. It counts the published files again. It does not recount any vote ([REPRODUCE.md, section 7](https://github.com/vinarise/zero-vote-sections-2026/blob/c41e4eda480c1df105cf9dffa095d7f6ab76b9ce/REPRODUCE.md)). - Four input files were reissued by the TSE after my 28 October download, with the same values the analysis reads. What changed was generation dates and times, row order, archive dates and one municipality name in a column the analysis does not read ([sources.freshness-2026-11-01.tsv](https://github.com/vinarise/zero-vote-sections-2026/blob/c41e4eda480c1df105cf9dffa095d7f6ab76b9ce/sources.freshness-2026-11-01.tsv)). - A rerun on the republished files, without the private labels, reproduces 133 of the 135 listed numbers and 56 of the 63 tables. The other two numbers and seven tables need the labels ([REPRODUCE.md, section 4](https://github.com/vinarise/zero-vote-sections-2026/blob/c41e4eda480c1df105cf9dffa095d7f6ab76b9ce/REPRODUCE.md)). - The seal covers 108 files, published in [commit `c41e4eda`](https://github.com/vinarise/zero-vote-sections-2026/tree/c41e4eda480c1df105cf9dffa095d7f6ab76b9ce) of the repository, signed with my key ([BUNDLE.sha256](https://github.com/vinarise/zero-vote-sections-2026/blob/c41e4eda480c1df105cf9dffa095d7f6ab76b9ce/BUNDLE.sha256)). Its timestamp is anchored in Bitcoin block 974,183, mined at 22:15 UTC on 1 November 2026 ([BUNDLE.sha256.ots](https://github.com/vinarise/zero-vote-sections-2026/blob/3fc6e2dcbdb6622412806850d041fdf60e7c06ec/BUNDLE.sha256.ots)). ## Article ### What was claimed On 27 October 2026, Folha de S.Paulo's Painel column [reported](https://www1.folha.uol.com.br/colunas/painel/2026/10/flavio-teve-zero-voto-em-106-urnas-nas-quais-somou-quase-15-mil.shtml#:~:text=n%C3%A3o%20obteve%20nenhum%20voto%20em%20106%20urnas) the 106 sections, in which Lula had nearly 15,000 votes. My October piece rebuilt that count and its findings stand. I repeat here only what the record needs. ### What I found, unchanged The PL side is Jair Bolsonaro in 2018 and 2022 and Flávio Bolsonaro in 2026. In 2018 Jair Bolsonaro ran for the PSL. The PT side is Fernando Haddad in 2018 and Lula in 2022 and 2026. I count a zero only where at least one valid vote went to either candidate. The 14,860 votes in Flávio Bolsonaro's zero sections are 0.34% of Lula's winning margin ([FINDINGS.md](https://github.com/vinarise/zero-vote-sections-2026/blob/c41e4eda480c1df105cf9dffa095d7f6ab76b9ce/FINDINGS.md)). Of Lula's 4 zero sections, 3 are rural or riverside and 1 is urban. By official registers, most of the 106 are at indigenous villages or quilombola communities, Black rural communities with roots in resistance to slavery. Under the best-scoring model, which I added after seeing results, 2026 had 106 zero sections against 10.8 expected on the PL side, and 4 against 0.4 on the PT side. None of my models can represent a whole community voting one way, and that limit says nothing either way about the count. In 503 indigenous polling places followed from 2022 to 2026, the PL-side zero rate was 3.6% and then 3.4% of sections. These places hold 36 of the 106. I added this comparison after seeing results too. Every consistency check between the published files passed. Before the vote I published a [forecast](https://vinarise.com/en/lab/2026/10/brazil-2026-runoff-forecast) giving Flávio Bolsonaro an 84.6% chance of winning. Lula won. That miss is about my forecast. It says nothing about the count. This piece does not grade that forecast. ### What is new The analysis now runs as one notebook, [zero_vote_sections.ipynb](https://github.com/vinarise/zero-vote-sections-2026/blob/c41e4eda480c1df105cf9dffa095d7f6ab76b9ce/zero_vote_sections.ipynb), from top to bottom. It first runs 37 tests on small tables whose right answers are known in advance, and it refuses any library not at its locked version. Then it runs the October code unchanged. Every number goes into [results.csv](https://github.com/vinarise/zero-vote-sections-2026/blob/c41e4eda480c1df105cf9dffa095d7f6ab76b9ce/results.csv), a ledger that only grows, with one row per measurement. Each row names the inputs, code and environment behind it, and each decision row cites the rows it uses. Every proportion comes with its margin of error. A script writes [FINDINGS.md](https://github.com/vinarise/zero-vote-sections-2026/blob/c41e4eda480c1df105cf9dffa095d7f6ab76b9ce/FINDINGS.md) from the ledger. Its first section lists the 135 measured numbers of the October piece beside their rows. Dates, fixed settings such as the 1 km rule, and figures quoted from other pages are not in that list. One expectation I wrote down in advance did not hold, and the ledger says so. I expected the two simplest models to call the count unexpected in every check, every year, on both sides. A model calls a count unexpected when more zeros occur than it allows. My plan said that alone means nothing, because these models cannot represent a whole community voting one way. On the PL side it happened in all 18 checks each year. On the PT side it happened in 5 of 18 in 2018, 13 in 2022 and 15 in 2026. The seal is one SHA-256, `18fed139d418a309b1a291e352a04565fd54c82aac75c9932f4a090a92bfe70c`, over the list of 108 files in [BUNDLE.sha256](https://github.com/vinarise/zero-vote-sections-2026/blob/c41e4eda480c1df105cf9dffa095d7f6ab76b9ce/BUNDLE.sha256), the executed notebook included. The sealed commit holds the timestamp request as sent to four OpenTimestamps calendars at 21:53 UTC. A later commit carries the upgraded proof, which ties the hash to Bitcoin block 974,183. The sealed commit did not change. GitHub shows both commits as Verified. The block proves these 108 files existed in exactly this form by 22:15 UTC on 1 November 2026, three days after the October piece. It does not show when the plan was written, and it does not show that the analysis is right. ### How I checked the record 1. The ledger against the text. Each of the 135 listed numbers matches its ledger value. A second check finds them in the October text, using the named part of the text where there is one. 2. The tables against the package. The 63 tables match the October package by their recorded checksums. No table names a section, a polling place or a community. 3. A second count with no shared code. An awk script of 33 lines reads the raw TSE section files and counts the zero sections, the votes in them and the margins. It shares no libraries and no derived tables with the notebook. On its first pass it read no 2022 rows and raised no error, because that year's file quotes every field. The output was visibly empty, so I caught and fixed it the same hour. The record keeps the fault and the fix, and the script now stops on any year with zero rows ([recount](https://github.com/vinarise/zero-vote-sections-2026/tree/c41e4eda480c1df105cf9dffa095d7f6ab76b9ce/recount)). ### What you can rerun without my private files The sealed run reads the files I downloaded on 28 October. The TSE has since reissued four of them, the 2022 and 2026 results by municipality and zone, the totalization report and the municipality code table. I compared each new copy with the locked one. The values the analysis reads match. Two inputs are files I labelled by hand and cannot publish, because they name single sections and polling places. Their fingerprints are in the sealed record, so I cannot swap them without it showing. I reran everything on the republished files, without those labels and without the map inputs. It gave the same values for 133 of the 135 listed numbers. The other two, behind "103 of 106", need the labels. Only 56 tables could be compared, not 63, because seven need them too. The run used an environment already built from the locked versions, so it did not test building one afresh. I ran this check myself, on the setup that made the record. It shows what someone else would get with the files that were public on 1 November. It does not show that anyone else has done it. ### What the plan's date rests on By my account, I wrote the original questions, models and rules for "unexpected" on 29 October 2026, before computing results. I did not freeze that text with a hash then. The same text is published at [EXPERIMENT.md](https://vinarise.com/labs/2026-10-zero-vote-sections/EXPERIMENT.md), with the SHA-256 `9d97b20920ab2da9bd7359334d401408954c049b7d43d1d21c88b4b13b35f617`. The host's deployment record dates that copy to 29 October 2026 at 11:21:07 UTC, a time kept by a party other than me. That record is not public. Anyone can recompute the hash today, but the date rests on that record. The record's copy of the plan is that text unchanged, plus a dated status section and 38 dated deviations. The published copy dates from after the first results. So the claim that the rules came first still rests on my word, and the record says so. ### What the files can't show Nothing here changes the October limits. The consistency checks compare files published from one system. They cannot show whether a machine recorded what each voter typed, because every public record of a vote comes from the machine itself. I did not check the files each machine signs. I could not, because the court's pages that describe their format blocked my automated downloads. This study is not an audit of the machines. The PT side rests on 4 sections a year, too few to say much. My classification of places by their names finds about 41% of the places the registers mark as indigenous. ### Check it yourself Get the repository, go to the sealed version, check the seal, then run it. The last line accepts the four reissued TSE files. Fresh registers may differ from the pinned ones. Read REPRODUCE.md section 4 before accepting them with ZV_ACCEPT_NEW_REGISTERS=1. ``` git clone https://github.com/vinarise/zero-vote-sections-2026 cd zero-vote-sections-2026 git checkout --detach c41e4eda480c1df105cf9dffa095d7f6ab76b9ce shasum -a 256 -c BUNDLE.sha256 ZV_ALLOW_CHANGED_SOURCES=1 ./run_all.sh ``` It needs Linux on x86_64, Python 3.13.5, pdftotext and about 12 GB of disk. The first run downloads about 4.9 GB of TSE files. [REPRODUCE.md](https://github.com/vinarise/zero-vote-sections-2026/blob/c41e4eda480c1df105cf9dffa095d7f6ab76b9ce/REPRODUCE.md) says what to expect, and its section 7 holds the second count. With a photo of one section's printed bulletin, the [October piece](https://vinarise.com/en/lab/2026/10/zero-vote-sections-2026-runoff) shows how to check it without code. For the timestamp, run `git show 3fc6e2d:BUNDLE.sha256.ots > BUNDLE.sha256.ots`, then `ots verify BUNDLE.sha256.ots`. It names Bitcoin block 974,183. Without a Bitcoin node of your own, [opentimestamps.org](https://opentimestamps.org/) checks the proof in the browser, with BUNDLE.sha256 as the stamped file. The code is under the Apache License 2.0, the derived data under CC BY 4.0 and the text under CC BY-ND 4.0. The TSE data keep their own licence, with attribution to the Tribunal Superior Eleitoral. The IBGE map outlines keep IBGE's terms, as LICENSE.md explains. ## Sources - [data] [Zero-vote sections research record, the repository at the sealed commit](https://github.com/vinarise/zero-vote-sections-2026/tree/c41e4eda480c1df105cf9dffa095d7f6ab76b9ce) - [data] [FINDINGS.md, generated from the ledger](https://github.com/vinarise/zero-vote-sections-2026/blob/c41e4eda480c1df105cf9dffa095d7f6ab76b9ce/FINDINGS.md) - [data] [EXPERIMENT.md, the plan with its status and deviations](https://github.com/vinarise/zero-vote-sections-2026/blob/c41e4eda480c1df105cf9dffa095d7f6ab76b9ce/EXPERIMENT.md) - [data] [REPRODUCE.md, how to rerun it](https://github.com/vinarise/zero-vote-sections-2026/blob/c41e4eda480c1df105cf9dffa095d7f6ab76b9ce/REPRODUCE.md) - [data] [BUNDLE.sha256, the seal](https://github.com/vinarise/zero-vote-sections-2026/blob/c41e4eda480c1df105cf9dffa095d7f6ab76b9ce/BUNDLE.sha256) - [data] [Resultados 2026, TSE open-data portal](https://dadosabertos.tse.jus.br/dataset/resultados-2026) - [data] [Relatório de Resultado da Totalização 2026, Brazil, TSE](https://cdn.tse.jus.br/estatistica/sead/odsele/relatorio_resultado_totalizacao/Relatorio_Resultado_Totalizacao_2026_BR.zip) - [report] [Flávio teve zero voto em 106 urnas, nas quais Lula somou quase 15 mil, Folha de S.Paulo, 27 October 2026](https://www1.folha.uol.com.br/colunas/painel/2026/10/flavio-teve-zero-voto-em-106-urnas-nas-quais-somou-quase-15-mil.shtml) - [page] [In Brazil's last three presidential runoffs, nearly all zero-vote sections were zeros for the PL side, Vinarise, 29 October 2026](https://vinarise.com/en/lab/2026/10/zero-vote-sections-2026-runoff) - [page] [OpenTimestamps](https://opentimestamps.org/)