MaydAI

Page for coordinator - lets Mo (or other coordinators) to receive and respond to incidents
CCTV Mock - Any input CCTV system gets shown as such
Coordinator page with alert received of incident
Page for volunteers - A dispatched volunteer receives notification and instructions

Inspiration

Riverside will have 15,000 people a day, 5 staff and 300 volunteers: one for every 50 people. That's enough people. The problem is the minutes between someone noticing something and the right person doing something about it.

Today, those minutes depend on a radio and one person's memory. Mo, the safety lead, is on foot with an earpiece and a phone in a pocket. Radio messages are gone as soon as they're said. While walking through the crowd, Mo has to remember who's trained in what, who's already busy, and where the nearest extinguisher is. That works at a club night. At 15,000 people a day, it breaks down. And Fieldday can't hire its way out: if it falls behind, paying for a takeover would wipe out the company.

Our first ideas were everyday frustrations: losing your friends, a flat phone, long queues. But you can recover from those. The moments you can't recover from all follow the same pattern: something is noticed → someone decides what to do → the right person gets there. MaydAI makes that whole sequence take seconds.

What it does

Our demo is a fire backstage that nobody notices. The crowd is facing the stage, and the smoke disappears into the haze machines.

Detect: A camera spots the fire about a second after it takes hold.
Plan: Mo's phone shows the photo, the one fact that matters most ("two extinguishers behind the sound desk; the stage manager can pause the show"), and two ranked options.
Approve: Mo taps once. The nearest fire-trained volunteer gets a briefing that says exactly where to go, and nobody else is disturbed.
Debrief: When the incident closes, MaydAI writes the case note. Today, Fieldday writes these up by hand the next morning.

Fire is just our proof of concept. The product is the response system behind it, and that system works with any input:

Volunteer reports: a volunteer sees someone collapse but doesn't know CPR. They say what they see, and MaydAI finds the nearest CPR-trained volunteer for Mo to send.
Outside alerts: an earthquake alert, or a tsunami warning at a coastal event, comes in from news or emergency feeds and becomes a plan for the whole site.
Other detectors: crowd-density detectors, storm warnings or radio transcripts can all send incidents through MaydAI's open API.

Where AI is used, and why

We only used AI where a fixed rule or a dashboard would fail.

Step	What the AI does	Why a simple rule can't do it
Detect	A vision model watches every camera	Five people can't watch every camera, and a colour or motion rule would go off at every stage light.
Understand	Speech-to-text and a language model turn a panicked voice note or a photo into an incident type, how urgent it is, and the skills needed	Reports are messy. "He's down near the bar, breathing but not answering" doesn't contain the words "medical" or "CPR".
Plan	A language model reads the whole event and drafts two ranked plans	Every incident is different. Who to send depends on who's free, what they're trained for, what else is happening, the heat and the headliner's set times. No lookup table can weigh all of that.
Debrief	A language model writes the case note from the timeline	A template can list what happened and when, but it can't say what went well or what to change.

What the AI deliberately doesn't do is decide or act. Sending volunteers, checking each step is safe, and the backup plans are handled by ordinary code that behaves the same way every time. Messages from volunteers can't give the AI instructions, and it never sends a volunteer to confront anyone. If the AI is down, MaydAI keeps running on standard plans. The AI makes the judgement calls, the code makes sure nothing unsafe gets through, and Mo makes the final decision.

Three layers of protection

Layer	What it catches
1. The detection model raises the alert	Fires nobody has noticed
2. The AI checks the photo against what's happening on site	False alarms (stage lights, a fire photo held up on a phone) and patterns, such as the same prank repeated
3. Mo approves, edits or rejects the plan, and makes any call to 000	Anything the AI gets wrong

A false alarm costs Mo a glance, not a wasted trip across the site. A real fire gets a plan in seconds, not minutes.

How the AI thinks

It sees the whole event, not just the alert. The AI gets:

two camera photos taken 15 seconds apart, so it can tell whether the fire is growing
every volunteer report, with first-hand reports counting for more
site notes on extinguishers, exits and gas shut-offs
the weather and set times
who's free and trained nearby
every incident from the last 90 minutes

That's why it treats a third collapse in one zone on a hot night as heat, not as three unrelated cases.

It's prompted for someone walking through an incident:

short answers in a fixed format
exactly two genuinely different options
the actual extinguisher or exit named
no claim that anything has happened unless it has
advice that changes only when the facts change

How we built it

Three live screens in the browser (coordinator, volunteer and camera), built with Node.js, Express and Socket.IO
Fire detection: a YOLO26n model trained on the FASDD fire dataset, running in the browser with ONNX Runtime Web and WebGPU, so video never leaves the device
Triage, planning and case notes: a language model that can read images, answering in a fixed format limited to actions the server can actually carry out
Voice reports: open-source Whisper turns speech into text
Real phones: volunteers join through ngrok by scanning a QR code
Open to other inputs: any detector can send incidents through the open API, and adding a new type of incident takes one line in a config file
Built in 48 hours with AI coding assistants, and tested on realistic made-up data for the site, the volunteers and the weather

Challenges we ran into

Readable while walking. Early plans were long, or offered the same idea twice. We rewrote the prompts until every word helped Mo act.
Leaving out crowd-crush detection. We didn't have good training footage, so we chose not to demo something we couldn't back up in 48hours.

Accomplishments that we're proud of

It works end to end on real phones: a camera alert or voice report becomes a plan, then a volunteer's briefing, in seconds.
It reasons rather than matching keywords: it linked a hot evening to a collapse and treated it as heat illness, without being told to.
It can't be fooled by a fire photo on a phone, and it notices when someone tries again.

What we learned

The technical people learned how to pitch, and the commerce people learned how AI products are really built. The biggest lesson: AI works best when it gives a few people the eyes of many, not when it replaces them.

What's next for MaydAI

More inputs into the same system: crowd density, weather, emergency alerts and radio (this means more context!)
An end-of-day debrief that spots patterns across all the case notes
Beyond festivals: stadiums, the F1 Grand Prix and community events