-
-
Actual working UI with synthetic ballots: plurality A, instant-runoff B and pairwise B.
Inspiration
A student club can get different answers to the same activity choice depending on its counting rule. QuorumGlass makes that difference inspectable before the group calls a winner. Its intended users are small student clubs and people learning social choice. The examples are synthetic, not collected ballots or a user study.
A concrete use case is a student club choosing its next activity. Before interpreting the result as a shared preference, the organizer can compare the same complete rankings under three counting rules. If the rules disagree or an elimination is tied, QuorumGlass exposes that uncertainty so the club can discuss its decision procedure. It does not collect votes or establish that a real club's decision improved.
What it does
Enter grouped complete rankings for three fictional activities. Compare first-choice plurality, instant-runoff and a strict pairwise winner. Inspect the head-to-head matrix and round audit, load a cyclic-preference example and export a local JSON calculation. A tie remains a tie: there is no hidden alphabetical elimination rule. Editing inputs invalidates the previous result; malformed rankings cannot be exported as a fresh calculation.
How it was built
A dependency-free static HTML/CSS/JavaScript app with a separate pure calculation module. Inputs stay in memory and the app code makes no network requests. Development began on 2026-10-22, after the event's published 01:00 KST submission opening. OpenAI Codex generated the implementation, tests, explanation and design prompting. Built-in Image Gen generated a visual concept; that image is not embedded as a fake working interface. The participant supplied the contest objective and constraints. No claim is made that the code was handwritten without AI assistance.
Challenges and validation
The most important policy decision was how to handle a tied elimination round without inventing an apparently objective winner. The implementation deliberately reports unresolved ties. Six automated tests pass, including 4,095 profiles checked against individually expanded pairwise ballots. A separate review compared instant-runoff results against another expanded-ballot implementation on 46,655 profiles; all matched. These are bounded synthetic checks, not proof of every possible input or election-security certification. Default, cycle and invalid-input browser flows were checked; an actual 1,176-byte exported JSON was downloaded and verified. Mobile was checked at a 390px viewport override.
Limits
Three fixed options and complete rankings only; at most 100 groups and 1,000,000 ballots. No accounts, remote ballot collection, identity verification, duplicate-vote prevention or secure election workflow. No recommendation that one rule is universally fair. No production use or adoption, impact estimate or award is claimed.
Demo and next steps
The 90-second silent demo uses actual captured working UI states edited into a captioned walkthrough; it is not a real-time screen recording. It is hosted as an unlisted YouTube video. The video shows the default calculation, round audit, cyclic preferences, invalid input and JSON export. Future work would add configurable options and incomplete-ballot policies; these are not implemented.
Try the decision audit
Open the live demo and calculate the default synthetic profile. Compare the plurality, instant-runoff and pairwise results; then inspect the head-to-head matrix and round audit. Load the cyclic example to see why a strict pairwise winner may not exist. Finally, edit a ranking into an invalid input and confirm that stale results cannot be exported. This is a tool for inspecting counting rules, not an election-security or identity-verification service.
Log in or sign up for Devpost to join the conversation.