Inspiration

It's 2pm on Saturday at Riverside. It's 38°C, there are 15,000 people on site, two first-aid volunteers haven't turned up, and the water queue is 40 deep. Mo, the safety lead, is on foot with a radio earpiece and a phone in his pocket.

Right now every incident reaches Mo by radio, so he becomes a human switchboard. He has to hear the call, work out where it is, figure out who is closest with the right skills, radio them, and remember who is already busy. Meanwhile the radio is short and noisy and gone once it's said. Most of the 300 volunteers are students who won't read long messages. And incidents arrive faster than one person can track them.

We wanted to take the switchboard job off Mo so he can go back to leading safety for the whole site. We also wanted every decision about people's safety to stay with a person, as the brief requires.

Ideas we considered

  • A radio-to-log tool or a roster builder on its own. Useful, but it doesn't help in the moment, and it reads as another dashboard.
  • A control-room dashboard. This was our first build. We dropped it because Mo isn't at a desk. He's walking the site.
  • Mo approving every job. It sounds safe, but he leads the whole site, and approvals would bury him at peak times.
  • One phone per named volunteer. It was hard to follow, so we switched to four general volunteer types.

We chose AI dispatch. The AI does real work: it reads messy reports and turns them into action. People still make the decisions.

What it does

Riverside Ground Control is an AI dispatch app that runs on phones.

  1. A report comes in. It might be a garbled radio call or a camera alert like "person down near Stage B" from CAM 14. (In the demo, these are typed or picked from a simulator strip.)
  2. The AI triages it. Claude reads the report and picks which of Mo's playbooks it fits. It also pulls out the location, severity, a 12-word alert for volunteers, 2 to 3 steps, and one calm sentence for Mo's earpiece.
  3. Mo's playbook decides who goes. Each playbook was written for Mo, and each one sets how many people go, which checked skills they need, and whether Mo is needed. There are playbooks for serious medical, minor medical or heat, water pressure, lost child, scuffle, crowd move or evacuation, and unclear report.
  4. The nearest qualified volunteers get buzzed in rings. Roamers are rung before fixed posts, and a post is only asked to help if it has people to spare. Phones under 10% battery are skipped, and their team lead radios them instead. Specialists are kept free, so medics aren't sent to fetch water.
  5. Claim and lock. The first volunteer to tap "I've got it" takes the job, and everyone else stands down. One incident never wakes the whole site.
  6. Mo only hears what needs him. Urgent jobs go to his "Now" tab and his earpiece, spoken in a calm, natural voice. Routine jobs that the playbooks handle go to "Later". For serious medical, Mo is asked to attend. For a crowd move, nobody moves until Mo approves.
  7. Triple zero (000) is always Mo's call. The app never calls emergency services. The on-site medical team can tell Mo an ambulance is needed. Mo decides, calls from his own phone, and logs it.

The demo shows seven phones side by side: Mo, a team lead, an on-site service (medical or security), and four volunteer types (medic, first aider, crowd steward, general volunteer). There's also a venue map built to City of Melbourne requirements.

How we built it

  • Plain HTML, CSS and JavaScript, with no build step and no installs. It's published as a Claude artifact.
  • AI triage: Claude reads each report through the artifact's built-in "ask Claude" capability. It returns a structured ticket, and the app routes that ticket into a playbook. If Claude isn't available, keyword rules produce the same kind of ticket, so the demo never breaks.
  • Dispatch logic in its own file. It handles skill checks (only checked skills count), distances on the map, ring sizes, and the fallback from medics to first aiders.
  • Mo's earpiece voice uses the ElevenLabs API (an AI text-to-speech service) to turn each line into a calm, human-sounding voice instead of a robotic one. Urgent lines cut in, and the rest wait their turn.
  • Venue map of a hypothetical 576 m by 240 m site on the north bank of the Yarra (Birrarung). We sized it to Victorian event guidelines and City of Melbourne permit rules: 3 first aid posts, 170 toilets in 6 blocks, about 100 drinking taps across 8 water stations, 4 emergency exits, an ambulance lane, a storm shelter and an assembly area.
  • Research into running a 15,000-person event legally in Melbourne, covering permits, first aid rules, licensed security, lost child processes and volunteer safety. That research shaped the playbooks.
  • Testing in a headless browser (a browser run by code, with no window) that clicks through every emergency, the main story and the voice lines.

Tools we used

  • Claude (in Cowork): planning, building, testing and research.
  • Claude via the artifact capability: live triage inside the app.
  • ElevenLabs API: Mo's earpiece voice (AI text-to-speech).
  • Playwright: headless browser testing.

Challenges we ran into

  • Deciding what the AI should decide. Early on, the AI was effectively choosing who went to each job. We moved to a stricter split: the AI only classifies the report, and Mo's playbooks decide the response. That's easier to trust and easier to explain.
  • Classifying emergencies from messy, custom radio calls. Real radio calls don't follow a script. They're short, half-heard and full of slang, and people describe the same thing in very different ways. Getting the AI to read a call someone wrote themselves and land on the right playbook was harder than handling our ready-made scenarios.
  • Over-classification. Sometimes one word in a report pushed it into a more serious playbook than it deserved. A report about someone who felt faint but was now sitting up and talking could be flagged as a serious medical emergency because of a single trigger word. Keyword rules were the worst for this, since they react to individual words rather than the whole sentence. We drew clear lines between playbooks (for example, "unresponsive or not breathing" versus "unwell but talking"), and anything with an unclear location goes to "Unclear report" so a team lead can ask the caller to repeat it.
  • Filling the brief's gaps realistically. The brief mentions no paramedics or security, only first-aid volunteers. Under Victoria's Private Security Act, though, only licensed crowd controllers can control crowds. So we added on-site licensed medical and security teams, and our volunteers act as "crowd stewards" who guide people rather than control them.
  • Designing for a pocket and an earpiece. Every screen had to work at a glance, and every alert had to fit in about 12 words.
  • A late-claim bug. Volunteers couldn't claim a job after every ring had gone out, even though they were still holding the alert. We found it in testing and fixed it.
  • Robotic voices. The browser's built-in voices sounded like a robot, which isn't something you want in your ear during an emergency. We switched to ElevenLabs so Mo hears a natural, human-sounding voice.
  • Lead times. Real approvals for an event this size take 6 to 12 months, much longer than the brief's ten weeks. We assumed approvals were lodged when Jess won the contract.

Accomplishments that we're proud of

  • It works end to end across seven emergencies, with or without live AI.
  • Mo isn't asked to approve routine jobs. Only serious medical calls and crowd moves need him.
  • Safety decisions stay with people. Triple zero is Mo's call, crowd moves wait for his approval, and volunteers never do security work.
  • The venue map and playbooks are built on real Melbourne rules, not guesses.
  • A lost child process based on council guidance: every gate held, two adults with a found child (one with a Working with Children Check), and police after 15 minutes.

What we learned

  • The best use of AI here wasn't the biggest decision. It was turning messy, noisy input into something clean that rules written by a person can act on.
  • Classifying real-world input is hard, and erring on the side of caution has a cost too. Over-flagging pulls Mo and the medics away from jobs that actually need them.
  • Designing for someone on foot changes everything: short words, a spoken voice, and only the urgent things.
  • Real regulations are a design tool. They told us who can do what, and that shaped the product.
  • "It works" needs proof. Automated browser tests caught bugs we would have missed.

What's next for Riverside Ground Control

  • Live camera and radio input: camera models and speech-to-text feeding reports in directly.
  • Sign-up with certificate checking, so volunteers' skills are verified before the event.
  • A phone for the volunteer coordinator: roster building and fixing no-shows on the day.
  • Real push notifications and earpiece hardware.
  • Privacy by design for cameras: analyse live, keep almost nothing, save clips only when an event triggers, no face matching, and an off switch.

Built With

Share this project:

Updates

Submission history