Tournament operations for a live debate event: check-in, pairing, power matching, room allocation, results and a leaderboard. I ran the tab by hand on Tabbycat for two tournaments first. This is that job, written down as software.
A debate tournament is a scheduling problem with an audience. Every round, the same questions have to be answered under time pressure in front of a room full of people: who is actually here, who debates whom, in which room, and who won. Get it wrong and sixty people wait while someone recalculates on a laptop.
Axiom runs that loop. Debaters check themselves in inside a time window. The system draws round one at random from whoever checked in, allocates rooms and times, takes results from an admin, and from round two on it power-matches: the unbeaten face the unbeaten. Statistics and the leaderboard fall out of the same data rather than being maintained separately.
Everything that changes state is admin-only, enforced by role rather than by a hidden URL. Every mutation goes through the API, so the state of the tournament is whatever the database says it is, not whatever is on someone's screen.
Click any stage to read what it does, or press the button to walk a full round. The second button shows what the system does when a round does not go to plan.
Check-in is a time window, not a checkbox.
The obvious way to build check-in is a flag on a user: present, or not. It is also the way you end up pairing someone who went home an hour ago, which means an empty room, a walkover, and a round that starts late for everyone else.
So check-in is bound to a window on the round itself. Outside the window it is refused. The pairing engine draws only from people who checked in for this round, not from the registration list, so absence is handled before the draw rather than discovered after it.
The same instinct runs through the rest: power matching filters to debaters with zero losses rather than sorting by score and hoping, and every state-changing endpoint is behind an admin role check rather than an unlinked page.
The repository is private and the service is only hosted while a tournament is running. It holds real participant records - names, check-ins, results - for a society I am responsible for, so it is not left on the internet between events, and the code is not open while the same instance is reused.
What I can show is the design: the API surface above, the pairing rules, and the schema shape. If you want to walk the code, ask me and I will screen-share it.