EventWaste Scout

Inspiration

It started with something small and annoying - the trash bags after every single school event, which we the catering club, had to clean up. Parent evenings, sports days, science fairs, it didn't matter which one. There were always boxes of untouched sandwiches and stacks of unopened juice going straight into the bin, every single time, like nobody had learned anything from the last event.

So we asked the obvious question: why does the same mistake keep happening? The answer was just as obvious once we looked for it - Nobody was tracking it and using the data. The person ordering food for Tuesday's event has no memory of what happened at the last five events, because there's no system holding onto that information for them. They're guessing every single time, and guessing badly, because guessing is all they have with the lack of any data.

That's the gap we wanted to close. Not with another awareness poster about food waste being bad, everyone already knows that , but with something that actually sits between "I'm about to order food for the event" and "I just threw away 40 sandwiches" and says, wait, here's what actually happened last time.

What it does

EventWaste Scout is a pre-event food audit tool built for student council coordinators, eco-club members and catering club members planning school events.

You type in the event type, expected attendance, time of day, and the food items you're planning to order. The Scout compares your plan against a history of past events and flags anything that looks like it's been over-ordered, based on real per-head consumption patterns rather than guesswork. Then it gets specific. It doesn't just say "you ordered too much" — it tells you the exact recommended quantity, calculates how many kilograms of food waste you'd prevent by listening to it, and how many meals that surplus could provide if redirected instead of binned. Then it gives you an actual contingency plan — what to do with the surplus, when, and where to send it, including a list of real food banks and charities in Qatar.

After the event, you log what was actually eaten. That number gets folded back into the history. The next audit for that event type is a little sharper than the one before it. The system is built to get better the more it's used, not just sit there as a static calculator.

We built it around Direction A of the brief — Food Waste Rescue Radar — and made sure every part of it followed the required flow: Input → AI Insight → Action. No dashboards that just show numbers and leave you to figure out what to do with them.

How we built it

We kept the architecture deliberately simple because we had a brutal timeline and zero room for error for things that could break on demo day.

Frontend: React with Tailwind, structured as a single-page app. We went through two complete visual redesigns — the first version used flat rectangles, thin borders, monospace data labels but it felt cluttered and a little juvenile. We rebuilt it in a smooth, soft cards and big colored alert boxes— because we wanted it to look like something you'd trust with real decisions, not a school project.

The Reasoning Layer: This is the part of the architecture we are proudest of. We completely rejected the idea of a "black box" that blindly spits out optimization numbers with no context, and we intentionally avoided heavy cloud LLM wrappers to keep the application 100% private, free, and functional offline. Instead, every single evaluation runs a transparent, client-side telemetry sequence that narrates its own math step-by-step. Instead of hiding the logic, our local expert engine openly maps out its exact execution path for the coordinator:

Historical Baseline Extraction: It displays exactly which past school events it extracted from localStorage to build the core trend baseline, making the data foundation completely verifiable.

Context-Aware Demographic Scaling: It breaks down the precise metabolic calibration applied to the raw headcount—openly explaining why a primary school cohort was scaled down to a 0.65x baseline to prevent over-ordering, or why a teen athlete group required a 1.35x multiplier to account for sports training schedules.

Allergen Safety Firewall Intercepts: It unmasks the algorithmic scoring penalties used by our logistics router. The system explicitly details why an open-campus space was downgraded due to cross-contamination liabilities, and why a certified cold-chain node like Hifz Al Naema was dynamically prioritized.

By putting the logic front and center, EventWaste Scout treats sustainability as a transparent data science problem. The user doesn't just get a number—they get the exact operational story behind the math, running entirely on their own machine.

The unit problem: Early on we realized "1 water bottle" means nothing without knowing the size, so we built a lightweight unit system — food, drink, or snack, each with a few realistic size presets — that lets us actually calculate kilograms and litres instead of vague unit counts.

The impact numbers: We pulled water-footprint and CO₂e figures from FAO and WRAP reference data so the kg/litres/meals numbers we show aren't invented — they're grounded in publicly available environmental data, just applied at a very local scale.

Challenges we ran into

The unit ambiguity problem was the one that nearly slipped through. We had the whole anomaly detection logic working and only realized halfway through testing that "80 units" of something is meaningless without knowing whether that's 80 sandwiches or 80 litres of juice. We had to go back and rebuild the data model to carry unit and size information through the entire pipeline — form, history, and the impact calculator — without making the form itself annoying to fill in under time pressure.

How we should handle food inputs not present in the database - We decided using a base value of 1.01 per head until more data was fed to the app by making more entries

We also went back and forth a lot on the contingency plan. Our first version was the same templated checklist every single time, which felt hollow once we looked at it critically — a judge running two audits would notice it never changed. We rebuilt it so the local engine adapts based on time of day and which items were flagged, and the AI-powered version writes a genuinely new plan each time and can recommend country-specific food banks based on what's actually surplus.

Since we intentionally avoided using a heavy cloud database to keep the app lightweight and free, we initially relied on hardcoded seed data to build our historical trend baselines. However, during testing, we realized that whenever we added or updated the underlying baseline structure in our code, the browser would aggressively read old, cached mock data from localStorage instead of our fresh array.

Building a food redistribution leaderboard sounds simple, but food safety laws are incredibly strict. If our app recommended sending surplus meals containing major allergens like nuts or dairy to open campus common spaces, it created a massive public health liability. We needed a way to make our logic "responsible" without relying on a slow, black-box AI model.

Accomplishments that we're proud of

We're proud that this doesn't feel like an awareness tool. It would have been easy to build a dashboard that shows waste statistics and call it done — the brief specifically warns against that, and for good reason, because that kind of tool changes nothing. Every screen in Scout ends in a decision someone can actually act on.

We're proud of the transparency panel. A lot of AI tools — even ones built by professionals — hide their reasoning and data behind a confident-sounding output. We built ours so a skeptical teacher or judge can click one button and see exactly why the system flagged what it flagged, in plain language, every time.

And we're proud that the numbers we show aren't just for show. Telling someone "you over-ordered" doesn't move anyone. Telling them "this prevents 4.2kg of waste, and could provide 8 meals" gives them something concrete to actually care about.

What we learned

The biggest lesson was that "AI-powered" is a very low bar to clear and a very high bar to clear well. It's trivial to wrap an API call around a form and call it AI. It's much harder to make the AI's reasoning visible, useful, and honest about its own uncertainty — and that's the part that actually matters for whether anyone trusts and uses the tool.

We also learned that synthetic data is fine to start with, but it has to be honestly framed. We were initially a little embarrassed that our seed history was invented rather than pulled from a real school's records. Then we realized that's not a weakness to hide — it's a design decision to explain. The system is built to replace synthetic assumptions with real logged data over time, and that's a more interesting story than pretending we had real data from day one.

And practically: build the thing that works with zero dependencies first. That decision is the reason our demo never had a moment of "please work, please work" anxiety.

What's next for EventWaste Scout

Looking ahead, our immediate next step is to introduce a hybrid cloud LLM routing layer as an optional toggle for institutions with stable internet access. While our current local engine excels at deterministic math, integrating a lightweight large language model via API will allow EventWaste Scout to parse highly unstructured, natural language inputs—such as copy-pasting an email from a catering coordinator or uploading a messy menu screenshot. The LLM won't replace our core logic; instead, it will act as an intelligent front-end translator, extracting headcounts and allergen lists automatically before passing them down to our trusted, client-side reasoning matrix for final verification.

Looking ahead, our second major architectural expansion is the integration of a real-time Geolocation API to dynamically update our food recovery routing hub. Right now, our platform relies on a carefully hardcoded registry of local networks like Hifz Al Naema. By connecting a live mapping and location-services API, EventWaste Scout will automatically detect the user's campus coordinates anywhere in the region. The engine will then instantly query active, verified food banks within a strict radius, calculating real-time transit windows and filtering options based on active operating hours. This turns our regional prototype into a scalable, globally deployable infrastructure network.

Beyond that, we'd want to extend the history model from a single school's events into a shared, anonymized dataset across multiple schools in the same district — so a brand-new school using Scout for the first time doesn't have to start from cold synthetic data, it starts from real patterns other schools have already logged.

And longer term, we think the same core engine — predict, flag, recommend, redirect — applies directly to Direction B of this brief. The same anomaly-detection logic that catches over-ordered sandwiches could just as easily catch a spike in after-hours energy use or an unusually high week of single-use plastic, which means Scout's architecture isn't just a food-waste tool, it's a template for local environmental decision-making more broadly.