Judging, show control, and awards for multi-room competitions. A dead iPad, a hub reboot, a dropped network — back in under 60 seconds, with nothing lost. Everything runs on hardware in your ballroom, so the show never waits on the venue's Wi-Fi.
Three or four judges, one announcer, a trophy table, and a schedule that has to hold. Everything runs on hardware in your ballroom, so the show never waits on the venue's Wi-Fi.
The judge scores. The announcer runs the room. The trophy table already knows. All three are views of the same live state, so no one is waiting on a runner with a clipboard.
No password and no setup. The roster seats them, so identity comes from the show — and a device can never call itself someone else.
Every slider move, chip, ink stroke, and second of audio lands on the device the instant it happens, then syncs. Nothing has to reach a network to be safe.
A set stays marked provisional until it's locked, so a runner never counts trophies from totals that can still move. Then the announcer and the trophy table advance the same ceremony, one award at a time — nobody is handed the wrong trophy.
Every competition system fails eventually. The difference is what happens in the next sixty seconds — and whether anyone in the audience ever knows.
Nothing is lost with it. Every input was written to that device the moment it happened, and everything already synced is on the room hub.
No pairing, no configuration, no account. It joins the room and asks one question.
The roster already seats them, so the device inherits the person rather than the person signing into the device.
“Resuming at #1490 · 2 of 4 scores in”
If it ever wakes up, it can't write. Two devices never fight over one seat, and the audience never learns any of this happened.
A judge, an announcer, the room tech, the director, and the runner at the trophy table all need different things from the same afternoon. Each gets a surface built for the job, not a role toggle on someone else's screen.
These are the real values from the screenshot above — the same routine, carried through the system without anyone retyping it.
Five parameters on your rubric, in 0.05 increments. Costume opens full and is deducted from, exactly as on paper.
The judge sees the panel projection while they judge — four judges scoring out of 30 each, so the composite is out of 120.
The level that composite currently lands on, from your configured cutoffs — with the distance to the next rung, 2.70 to Platinum.
Nothing reaches a cart while it can still move. Once the set locks, the trophy table sees the level, the entry, the studio, and how many medals that group size needs.
The announcer's script and the trophy tablet advance together, so the runner is already holding the right trophy when the name is read.
Rooms share their running order and their real pace, so a dancer due on two stages minutes apart is flagged on both announcers' screens — with the move that fixes it, before anyone is standing in the wings.
The recording meter is drawn from audio that actually reached the disk, not from the microphone signal. It is the difference between a screen you can glance at and a screen you have to double-check.
A meter driven by the microphone signal draws the healthy waveform in both cases, because the microphone is fine — it's the disk that stopped. The judge would find out at the end of the day; the studio would find out when the file never arrived.
The chart every table works from states the rule correctly, then tabulates it as 16-second spans for a 15-second block — so the last second of each printed row really belongs to the next one. Read literally, it under-deducts by one block on 17 specific seconds of every competition day.
0.1 per judge for every 15 seconds, or any portion of one, past the limit — after a 15% allowance for machine calibration error.
At exactly 4:00 the printed chart lists the same second twice, in two rows, with two different answers — 0.8 as the end of one and 1.2 as the start of the next. The formula gives 1.2. All 21 rows are encoded as test fixtures, and the same fixtures run against both the TypeScript hub and the Swift judge app, so the two can never quietly disagree.
A number with no explanation is the most common complaint about a competition weekend. Every routine goes home with the judge's own voice attached to it.
Recorded per routine and per judge, starting when the routine does. A file is never named by a human — the name comes from the show, so it can't be misfiled.
The critique as text, so a studio can search a weekend's feedback instead of scrubbing audio for the one note they remember. Transcription runs on the room's own hub, so a minor's audio never leaves the building. Not shipped yet — it's waiting on release wording, not on code.
The pencil marks made on the sheet during the routine, delivered alongside the audio rather than thrown away with the tablet.
No scoring parameter, cutoff, buffer, or award level is written into the software. They live in a versioned config per event, which is why a new season's scale is an edit rather than a release — and why this runs for organisations whose rules look nothing like each other's.
Five rungs here. Another event's config draws a different number of them, in its own order, with its own names — and every screen follows.
A show simulator runs a scripted 186-entry day over the real protocol, with the failures deliberately switched on. It has to stay green, so a change cannot quietly break "run a full day."
| Simulated day | 186 entries over the real WebSocket protocol, up to 100× speed |
|---|---|
| Chaos, deliberately | Kill a client mid-score · drop the network for 60 seconds · kill the hub mid-set |
| Invariants checked | Replay equality, idempotency, and no lost work — every run |
| Domain tests | 399, at roughly 100% branch coverage |
| Hub tests | 172, including 46 multi-client integration tests |
| Judge app tests | 120, against the same shared fixtures as the hub |
| State machines | Every transition tested — including every illegal one |
Nothing happens. The room hub in your ballroom is the source of truth and sits on its own network, so the internet isn't in the path of the show at all. Cloud backup and remote monitoring are extras that can fail without the day noticing.
Hand them a spare and they tap their own name. It resumes at the routine the room is on, with the scores they'd already submitted intact, and the dead device goes read-only if it ever comes back. Target is under sixty seconds, box to scoring.
It reboots by replaying its own log and comes back in the state it died in. Judges keep scoring through the outage on their own devices, and their queued work delivers itself when the hub answers again.
Then you go to paper — it's a written procedure, not an improvisation, and it's rehearsed in the pilot runbook. Because history is append-only, re-entering that block afterwards adds to the record instead of overwriting it, so nothing already captured can be corrupted by the catch-up.
Yes, and that's the intended path. Parameters, increments, cutoffs, deductions, buffers, and ceremony order are all versioned config. Nothing about a rubric is compiled into the software.
The escalation ladder, in order: a blip self-heals · a dead device hot-swaps · a dead hub replays on boot · paper only when digital can't be restored in time.
The fastest way to judge this is to watch a room run — routines advancing, four judges scoring, a set locking, and the awards cart filling itself in. It takes about fifteen minutes.