When the top-scoring candidate isn't the winner¶
This is STAR's single most important lesson — the one BetterVoting itself asks about when it pops up "Why is the top-scoring candidate different from the winner?" (Presenting with BetterVoting? Explaining Runoff Reversal to Voters has a corrected, plain-language version of that popover.)
Teaching this? The step-by-step presenter's guide — the order to teach it in, why it's a good thing, and the devil's-advocate questions with answers — is Teaching Runoff Reversal — a step-by-step guide.
Real BetterVoting cases — the Runoff_01–Runoff_08 two-view series now live in a sibling folder: runoff_reversal_bv_cases/ — real BV elections, each a two-view lesson (BetterVoting screenshots beside an independent count from Larry Hastings' open-source starvote engine, extended in this repo — the "LH" tabulator) walking the how much vs how many arc, from the smallest possible reversal to the 61-candidate CA-Governor field. The small teaching demos that have no live BetterVoting election stay here (below).
Concept hub for all of it: The Automatic Runoff Round.
The name for it: we call this a Runoff Reversal — the Scoring-Round leader loses the Automatic Runoff to the finalist more voters prefer. (In technical or debate writing, the precise phrasing is "the runoff overturns the score leader," to avoid colliding with reversal symmetry in social-choice theory.)
The short answer is in the name of the method. STAR = Score Then Automatic Runoff. The count has just two steps:
- Scoring Round. Add every candidate's stars. The two highest-scoring candidates become the Finalists.
- Automatic Runoff. Now look only at those two. Each ballot's full vote goes to whichever finalist it scored higher. The finalist more voters prefer wins.
That second step is the whole point. The candidate with the biggest pile of stars is the one who leads the score round — but leading the score round only makes you a finalist, not the winner. The winner is whichever finalist more voters actually prefer. Usually that's the same candidate. Sometimes it isn't — and that is the lesson.
The one-screen version (your real election)¶
This is the actual recorded race in 03_c7_b3_ice-cream-live.yaml (BetterVoting id c3m79f), three voters:
ChocoDrk ChocoAlm ChocoHzn ...
voter 1 4 5 3
voter 2 0 3 0
voter 3 5 0 0
score total 9 8 3 ← ChocoDrk leads the score round
Score round: ChocoDrk has the most stars (9), so it tops the round. ChocoAlm is second (8). Those two are the finalists.
Automatic runoff — ChocoDrk vs ChocoAlm only:
- Voter 1 scored ChocoAlm 5, ChocoDrk 4 → prefers ChocoAlm
- Voter 2 scored ChocoAlm 3, ChocoDrk 0 → prefers ChocoAlm
- Voter 3 scored ChocoDrk 5, ChocoAlm 0 → prefers ChocoDrk
Two of three voters prefer ChocoAlm, so ChocoAlm wins, 2–1 (67% to 33%) — even though ChocoDrk had more total stars.
Why is that the right answer? ChocoDrk's lead came from one superfan giving it a 5. ChocoAlm is the candidate more people actually prefer when it comes down to the two of them. The runoff makes sure the winner has majority support, not just a loud minority — and it does it without anyone having to vote dishonestly.
The lessons in this folder¶
Each file is a tiny, self-contained election you can run through the engine. They're built so the score-round leader loses the runoff — except the last one, which is the control case where the leader wins (so you can see the runoff isn't rigged).
The Page (left) is the readable write-up with ballots + full results; the raw .yaml (right) is the tabulatable source.
| Page (read this) | Field | What happens | src |
|---|---|---|---|
| 01a — more stars, fewer voters | 3 cand, 3 voters | The atom: Almond leads 13 stars, Brownie wins the runoff 2–1 | .yaml |
| 01b — overturn holds at scale | 3 cand, 9 voters | Same election, bigger crowd: Almond leads 39–33, Brownie wins 6–3 (67/33) | .yaml |
| 02 — leader overturned | 5 cand, 5 voters | Austin leads 22 stars, Boston (the broad compromise) wins the runoff 3–2 | .yaml |
| 03 — ice-cream, live | 7 cand, 3 voters | The real race: ChocoDrk leads 9, ChocoAlm wins 2–1 | .yaml |
| 04 — runoff confirms leader | 4 cand, 3 voters | Control: Blue leads and wins — the runoff confirms the leader | .yaml |
| 05 — low scores (BV1265) | 3 cand, 5 voters | A real BetterVoting election with all-low scores: C leads (7), A wins the runoff 3–2 | .yaml |
| reversal — the convincing case | 3 cand, 100 voters | Intense-minority Max leads on stars 335–255, Nora (broad) wins the runoff 55–45 — the runoff clearly earns its keep | .yaml |
| reversal — the jarring case | 3 cand, 100 voters | Near-consensus Uma leads 449–255 (avg 4.5) yet polarizing Rye wins 51–49 — STAR choosing majority over utility, the honest drawback | .yaml |
The last two are the contrasting pair behind the second-round FAQ — one reversal almost everyone accepts, one that's a genuine philosophical trade-off (a token no-hoper keeps each a proper three-way race).
Two more, in the main folder, push the field even wider:
- 06b — nine-candidate overturn (
.yaml) — nine candidates: Andre leads with 9 stars, Carmen wins the runoff (Carmen is also the candidate who beats every other one-on-one). - 06a — nine-candidate confirm (
.yaml) — another nine-candidate field where the runoff confirms the leader.
Why it starts at three candidates¶
With only two candidates there's nothing to teach here: both are automatically finalists, so the runoff is just "which of the two do more voters prefer" — plain majority rule, and the star totals never get to matter. The interesting behavior only appears once the score round has to choose two finalists out of a larger field, i.e. three candidates or more. That's why the smallest lesson here is 3 candidates.
"Is overturning the leader fair?"¶
It's the opposite of unfair — it's the safeguard. A high score total can come from a small group of enthusiasts. The runoff asks a different, majority-protecting question: of the two finalists, which one do more voters prefer? When the score leader really is the most-preferred candidate, the leader wins (that's 04 and 06a). The runoff only changes the answer when enthusiasm and majority preference point at different candidates — and in that case majority preference is exactly what you want to win.
A related point: because your runoff vote is decided by the scores you already gave, you never have to lowball a candidate to "protect" your favorite. Scoring honestly is also the smart strategy.
Going deeper — read the full count (201)¶
Everything above is the minimal view: scores → finalists → runoff → winner, which is all a first-time voter needs. But every example here also writes a complete audit report to its _tabulated.txt sibling (in runoff_overturns_leader_tabulated/) — the pairwise preference matrix, the score distribution, and the engine's plain-English Majority Preference block stating exactly which candidate led on score and which won the runoff. Learning to read that report is Voting 201. Don't put the full report in front of a 101 beginner — point them here when they're ready.
The whole 201 level is one page: → Voting 201 — reading results, comparisons, multi-winner intro. That's the index of everything below, in teaching order. The topics it opens up, if you'd rather jump straight to one:
| 201 topic | Page |
|---|---|
| Read a full engine report, section by section (uses this folder's BV1265 example) | How to read a STAR result report |
| Where the preference matrix comes from — every ballot is a tiny matrix, and they add up | Pairwise counting |
| The runoff shown two ways (% of all voters vs % of those with a preference) | Two denominators, one winner |
| The same election counted by STAR and by RCV-IRV, step by step | STAR vs RCV-IRV — the count · the honest comparison |
| What happens when the count can't be summed by precinct | Central tabulation |
| Ties, tiebreakers, and the ladder they climb | Ties (topic hub) · the tie-breaking ladder |
| Electing more than one seat — the majoritarian intro | Bloc STAR (201.5) |
| What are we even optimizing for? | What makes a good winner? · Criteria at a glance |
Above 201: Voting 301 (proportional methods, criteria, debate theory) and Voting 401 (failure modes) — the full map is the curriculum hub, and every concept page is listed in the topic index.
How often does it happen? (301)¶
Often enough to matter — but the exact rate depends entirely on your modelling assumptions, which is a lesson in itself. A brute-force simulation (06_Other/simulations/runoff_reversal_simulation.py) measures it: under a realistic spatial electorate of ~100 voters, a clean Runoff Reversal happens in roughly 1 election in 11; under white-noise Impartial Culture it's higher, and at tiny electorates the figure is dominated by ties. The takeaway for a debate: never quote a bare percentage without naming the model, the electorate size, and how ties were counted. Full writeup: Simulations — measure it, don't guess it.
Run them yourself¶
From the repo root:
uv run python STARVote_LH_tabulation_engine/starvote_larry_hastings.py "01_STAR/02_Examples/runoff_overturns_leader/cases/03_c7_b3_ice-cream-live.yaml"
Watch for the engine's Majority Preference note — it prints exactly which candidate earned the highest score and which one won the runoff, whenever the two differ.