From 86e53085ee1e5f7fc1ee66b6dec1a98c7f6aa9e7 Mon Sep 17 00:00:00 2001 From: Adam Masiarek Date: Sun, 16 Aug 2026 22:45:22 -0400 Subject: [PATCH] docs: let a losing candidate verify a tie-break themselves A tie-break is the most contestable moment in an election, and 'the computer shuffled them' is not an answer that survives a challenge. This is the deep companion to the ties page: what BetterVoting publishes about a tie-break, how to check it independently, and -- as importantly -- what checking it does not prove. Written for the person who LOST the tie, and for anyone who has to certify a result to people who were not in the room. Calm and precise rather than reassuring; this reader may be upset and will not be helped by breeziness. What it documents: - The full tie-breaking ORDER is published, not just the winner -- on the results page and in the download, with each candidate's position, the tied set, and the kind of tie-break applied. There is nothing to request; it is already there. - The shuffle is deterministic, so re-running the count cannot produce a different answer. An administrator cannot re-roll it. - The ordering could not have been known in advance, because the ballot count feeds it and only settles when voting ends. - The algorithm was chosen to be language-agnostic precisely so an outsider can reimplement it and compare. - A warning callout for the trap that will otherwise sink a hand-check: the shuffle uses the RAW ballot count from the download, while the results page shows a TALLY count that excludes uncountable ballots. Checking with the wrong number produces the wrong order and looks like evidence of fraud. The limits section is the reason the page is worth publishing. It states that verification proves the published order follows from the published inputs, and does NOT establish that the ballot set is complete or correct -- that is a separate question -- and does not make the outcome fair in any wider sense. A verification page that overclaims is worse than no page, because it invites someone to believe they have checked more than they have. Also includes step 5, the step people skip: confirm the tie-break was needed at all. A correct shuffle applied to a tie that should not have existed is still a wrong result. Co-Authored-By: Claude Opus 5 --- docs/help/verifying_a_tie_break.md | 69 ++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) create mode 100644 docs/help/verifying_a_tie_break.md diff --git a/docs/help/verifying_a_tie_break.md b/docs/help/verifying_a_tie_break.md new file mode 100644 index 000000000..da928819f --- /dev/null +++ b/docs/help/verifying_a_tie_break.md @@ -0,0 +1,69 @@ +--- +layout: default +title: Verifying a Tie-Break +nav_order: 19 +parent: BetterVoting Documentation +--- + +# Verifying a Tie-Break + +If a tie decided your election, you don't have to take the result on trust. This page explains exactly what BetterVoting publishes about a tie-break and how to check it. + +It's written for the person who lost a tie, and for anyone who has to certify a result to people who weren't in the room. For what a tie is and how one gets broken, start with [Ties](ties.md). + +## What gets published + +When a tie is broken by shuffle, BetterVoting doesn't just announce a winner. It publishes **the full tie-breaking order** — every candidate involved, from highest priority to lowest. + +That order appears in two places: + +* **On the results page**, in the tie-breaker section shown alongside the result. +* **In the downloadable election data**, where each candidate carries its position in the order, along with which candidates were tied and what kind of tie-break was applied. + +This matters more than it sounds. A losing candidate can be shown the complete ordering rather than a single assertion about who won. There is nothing to reveal on request — it is already published. + +## Why the result can be checked at all + +The shuffle is **deterministic by design**. It is not a fresh coin toss performed once and recorded; it is a calculation that produces the same answer every time it runs, from inputs that are themselves published. + +Three consequences worth stating plainly: + +* **Re-running the count cannot change the answer.** If the same ballots are tabulated again, the same tie-breaking order comes out. An administrator cannot re-run the results hoping for a different outcome. +* **Nobody could know the order in advance.** One of the inputs is the number of ballots cast, so the ordering isn't fixed when the election is created — it settles only when voting ends. +* **It can be reproduced independently.** The shuffling algorithm was deliberately chosen to be small and language-agnostic, precisely so that someone outside the project can implement it and get the same result. + +{: .warning } +> **The one number people get wrong.** The shuffle uses the **raw** ballot count — every ballot submitted, which is what appears in the full data download. The results page displays a **tally** count, which excludes ballots that couldn't be counted. These two numbers are frequently different, and a check done with the tally count will produce the wrong order and look like evidence of a problem. Use the raw count. + +## How to check it + +1. **Download the full election data.** You need the raw ballots, not the summary shown on screen. +2. **Note the published tie-breaking order** from the results page or the export — the whole ordering, not just the winner. +3. **Count the raw ballots** in the download. This is the figure that feeds the shuffle. +4. **Reproduce the shuffle** using that ballot count and the identifier of the race the tie occurred in, and compare the ordering you get against the published one. +5. **Confirm the tie-break was actually needed** — that the candidates recorded as tied really were level on the count, and that the earlier steps of the protocol (which use the ballots themselves) genuinely couldn't separate them. + +Step 5 is the one people skip, and it's the one that matters most. A correct shuffle applied to a tie that shouldn't have existed is still a wrong result. + +## What this does and does not prove + +Being precise about the limits is what makes the check worth doing. + +**It does prove** that the published tie-breaking order follows from the published inputs — that the ordering wasn't chosen, adjusted, or re-rolled to favour anyone. Given those ballots and that race, that ordering is the only one the rules produce. + +**It does not prove that the ballot set is correct or complete.** Whether the right people voted, whether every ballot was received, and whether any were wrongly excluded are separate questions. Verifying a tie-break tells you the tie was broken according to the rules; it says nothing about what happened before the counting started. If your concern is the ballots rather than the tie-break, that's a different check. + +**It does not make the outcome fair in a wider sense.** A tie-break is a rule for resolving a genuine deadlock. It produces a defensible answer, not a more deserving winner. + +## If the numbers don't match + +Contact the election administrator before drawing conclusions — a mismatch is far more often a raw-versus-tally mix-up than anything else. + +When you get in touch, include: which race, the tie-breaking order you were shown, the ordering you calculated, and the raw ballot count you used. Those four things let someone find the discrepancy immediately. Without them the conversation takes days. + +If the administrator can't resolve it, they can escalate to BetterVoting with the same information. + +## Related + +* [Ties](ties.md) — when ties happen and how they're broken +* [Hand Count](hand_count.md) — verifying a count without a computer