bv_test_id: BV2257
bv_election_id: q2rkfm
bv_results_url: https://bettervoting.com/q2rkfm/results
election_title: "Team lunch on a choose-one ballot — a dead tie (BV2257, q2rkfm)"

scenario_description: |-
  Five coworkers, three lunches, and the old ballot: mark one box.

  Sushi 2 · Tacos 2 · Pizza 1 — and that is the entire count. Nothing on these
  ballots can separate Sushi from Tacos, so the pre-published lot order decides.
  The Pizza-fan is the one voter who could have broken the tie, and a choose-one
  ballot gave them no way to say so.

  Same five people, same opinions, on a 5-star ballot:
  01_STAR/02_Examples/cases/bv2184_fyy886_lunch_vote.yaml — where STAR elects Pizza,
  the compromise everyone is happy with.

  TIEBREAK — this case is NOT deterministic, on purpose. LH resolves the 2-2 tie
  with the pre-published lot order below and elects Sushi. BetterVoting resolves
  it at RANDOM (its frozen export records tieBreakType: "random"); the live run
  happened to land on Sushi too, but a re-run could just as well say Tacos. That
  is the honest state of a tied choose-one election, not an engine disagreement.

  Live results (BV2257): https://bettervoting.com/q2rkfm/results
  Lesson: 06_Other/Plurality/README.md

voting_method: Plurality
num_winners: 1

lot_numbers: [Sushi, Tacos, Pizza]   # the ballots can't break the tie — the lot does

ballots: |-
  Sushi,Tacos,Pizza
      1,    0,    0   # Sushi-lover
      1,    0,    0   # Sushi-lover
      0,    1,    0   # Taco-lover
      0,    1,    0   # Taco-lover
      0,    0,    1   # Pizza-fan

expected_winners:
  - Sushi

# file: lunch_choose_one_dead_tie.yaml