Inspiration
I created Backfill for Track 3: Ground Control.
Riverside is a three-day riverfront festival with up to 15,000 visitors per day, supported by 300 volunteers and a five-person events company. I focused on Mo, the safety lead, and the volunteer coordinator when the planned roster breaks during the event.
My starting point was the challenge's Saturday afternoon scenario: it is 38°C, two first-aid volunteers have not arrived, and the water station has a queue of 40 people.
The difficult part is finding replacements without creating another staffing gap, overloading someone, or losing track of whether the replacement actually arrived.
CPU scheduling inspired my approach. Tasks compete for limited resources, have priorities and deadlines, and incur a cost when resources move between tasks. I adapted those ideas to people with different qualifications, availability, locations and rest requirements.
What it does
Backfill helps coordinators repair an existing volunteer roster when circumstances change.
The prototype supports the following workflow:
- Enter a short staffing report as text.
- Review the extracted location, headcount and named volunteers. Missing locations trigger a clarification question.
- Confirm the record and its risk level. The queue is ordered by risk, then deadline; long-waiting items receive a review reminder.
- Generate a proposed allocation across the open vacancies, considering recorded qualifications, availability, existing assignments, rest rules and minimum coverage at source posts.
- Review a short explanation of each proposed move, then approve, edit or reject it.
- Follow the move through message review, volunteer confirmation and arrival check-in.
Declined or unanswered requests return for replanning. Unfilled slots remain visible rather than being hidden.
For reports about queues, the coordinator first confirms whether the issue is staffing or supply and equipment. A supply problem should not automatically trigger a staff move.
How I built it
I built a browser-based prototype using vanilla HTML, CSS and JavaScript, with a phone-friendly interface and a seeded synthetic dataset of 300 volunteers.
The assignment engine is a custom JavaScript search using constraint checks and branch-and-bound. It considers open vacancies together and evaluates assignment costs, including disruption to staffed posts, walking time, previous workload and role preferences. It can show partial proposals when all vacancies cannot be filled.
Explanations, volunteer message drafts and the basic incident record are generated from structured fields using templates.
Three preset scenarios demonstrate a no-show, a replacement declining, and simultaneous shortages at two posts. The interface displays planning time, roster changes, remaining unassigned slots and arrival status.
Tools used include HTML, CSS, JavaScript, Claude Code, and an optional Claude API integration for online language processing.
How AI is used
The optional Claude API integration converts free-text reports into structured staffing records and can organise the event log into a draft incident record.
The default offline mode uses a rule-based parser and templates. This keeps the demonstration runnable without API access and makes the distinction between live AI and offline behaviour visible.
The language model does not assign volunteers. The JavaScript assignment engine checks the configured constraints, while a person confirms the input, reviews the risk level and approves staffing changes.
Volunteer messages, replies and arrival checks are simulated in this prototype. It does not send real SMS messages or dispatch real volunteers.
Ideas I considered
I considered a dashboard that only flags shortages, a chatbot over the roster, nearest-person-first allocation, and a complete initial rostering system.
I chose day-of roster repair because it gives a clear user a focused workflow: turn a reported shortage into a reviewed proposal and follow it through to arrival.
Considering vacancies together also helps avoid using a scarce qualified volunteer for a role that another available person could cover.
Challenges I faced
Adapting CPU scheduling required accounting for differences between volunteers. Qualifications, travel, rest and source-post coverage all affect whether a proposed move is appropriate.
I also had to handle incomplete reports and distinguish staffing shortages from other operational problems. Editable extraction and clarification questions keep the coordinator involved.
Another challenge was separating a proposed assignment from a completed move. Approval, a volunteer saying yes, and arrival are different events, so each has its own state.
Keeping the interface brief was also important: Mo needs to review useful information on a phone while moving around the festival.
What I learned
I learned that a useful scheduling product needs both an allocation algorithm and a process for confirming that its recommendations were carried out.
I also learned to make system boundaries explicit. Language processing can help organise reports, while staffing constraints and approvals need to remain inspectable.
The CPU scheduling analogy helped me structure the problem, but the human context determined the rules and interface.
Limitations and next steps
This is a demonstration using synthetic data and browser memory, rather than a deployed volunteer management system. Online AI requires API access; messaging and replies are simulated.
Next, I would add persistent records, verified credential data and a real messaging integration. I would also develop a rehearsal mode to test the roster against scenarios such as multiple no-shows, extreme heat and a storm warning.
Built With
- ai-tools
- html
