Inspiration
Reducing food waste should never mean leaving people without a meal.
Every day, school and institutional kitchens face a difficult decision: how much food should they prepare? Producing too much creates avoidable surplus, while producing too little risks leaving diners unserved.
We realized that measuring food waste is only part of the solution. Kitchens also need to understand historical patterns, evaluate future uncertainty, compare preparation strategies, and determine what actually happened after a decision was made.
That inspired MealLoop OS, an evidence-aware food waste decision-support platform built around four connected actions:
Measure. Forecast. Decide. Verify.
Our goal was to turn fragmented waste measurements into transparent, testable operational decisions without confusing predictions, assumptions, and observed outcomes.
What it does
MealLoop OS combines four working modules in one web application.
1. Waste Intelligence — Understand the problem
The platform analyzes 155 days of real food waste measurements from a secondary school in Finland.
It presents plate waste, kitchen and serving waste, daily trends, menu-level analysis, and per-diner measurements.
The system preserves missing observations and conflicting source values rather than silently correcting them. Every calculation remains traceable to its original dataset.
2. Forecast Lab — Predict with evidence
Forecast Lab evaluates historical waste-per-diner forecasting using chronological validation.
We compared three baseline approaches and two Ridge regression models. The recent 10-day mean performed best on the combined validation metric, achieving:
- 12.55 g/diner validation MAE across 75 predictions.
- 8.73 g/diner holdout MAE across 18 eligible observations.
Rather than selecting a more complicated model simply because it uses machine learning, MealLoop OS retains the method supported by the evaluation results.
The platform also makes forecasting limitations visible, including the small dataset and uncertainty about generalization to other kitchens.
3. Decision Studio — Optimize meal preparation
This is the central decision-making component.
Users define possible demand levels, their probability weights, production capacity, batch sizes, portion mass, and minimum service reliability.
A deterministic optimization engine evaluates feasible production quantities and identifies the plan with the lowest expected surplus while respecting the specified service constraints.
In our interactive synthetic demonstration:
- The original plan prepares 480 portions.
- At a 95% service-reliability target, the optimizer recommends 440 portions.
- Expected modeled surplus falls from 30.4 kg to 14.4 kg, a potential difference of 16 kg (52.63%) under the specified assumptions.
- Reducing the reliability target to 70% changes the recommendation to 400 portions, with 12 expected unserved portions.
This reveals the trade-off between minimizing surplus and ensuring sufficient meals.
The 16 kg result is a modeled scenario difference, not verified food waste prevention.
4. Impact Ledger — Track what actually happens
Decision-making does not end when a production quantity is selected.
Impact Ledger records prepared and served portions, leftover food destinations, measurement methods, and supporting operational evidence.
It distinguishes donated, retained, repurposed, discarded, and unaccounted food. It also prevents portion-based estimates from being mistaken for physical scale measurements.
Records with unknown or inconsistent food destinations cannot be finalized as complete accounting evidence.
An append-only revision history preserves corrections and supports transparent review.
How we built it
MealLoop OS is a full-stack web application.
Frontend: React, TypeScript, Vite, Tailwind CSS, and Recharts.
Backend: Python, FastAPI, Pandas, NumPy, scikit-learn, SQLAlchemy, SQLite, and Alembic.
Decision engine: Deterministic, constraint-based optimization using exact enumeration of feasible production quantities.
Deployment: GitHub and Render, with an isolated public demonstration environment.
The architecture separates measured data, statistical predictions, assumption-based optimization, and operational records.
We implemented a read-only public demonstration mode where judges can interact with real calculations without modifying stored records. The application does not require specialized hardware, paid AI APIs, or a separate cloud database for its public demo.
Development and testing included AI-assisted coding tools; the actual forecasting and optimization engines use reproducible statistical and mathematical calculations rather than LLM-generated decisions.
Challenges we ran into
One major challenge was data quality. The original dataset includes missing and conflicting measurements. We had to preserve the source information while enforcing strict eligibility rules for forecasting.
Another challenge was avoiding data leakage. Forecast methods were selected using chronological baseline validation, with the final holdout evaluated separately.
Perhaps the most important challenge was recognizing that historical food waste does not directly reveal future demand or the optimal number of portions to prepare. We therefore designed Decision Studio around explicit, editable demand assumptions instead of inventing production information.
Finally, creating a safe public demo required separating local writable operations from anonymous, nonpersistent previews.
Accomplishments we're proud of
- Developed four integrated, functioning modules rather than disconnected prototypes.
- Built an interactive optimization engine with transparent feasibility constraints and sensitivity analysis.
- Preserved scientific provenance, data quality issues, and reproducible evaluation results.
- Implemented operational accounting with explicit measurement boundaries and correction history.
- Passed 398 automated backend tests in the verified release.
- Published the source code and deployed a publicly accessible, interactive HTTPS demonstration.
Most importantly, MealLoop OS does not hide uncertainty behind impressive-looking numbers. It explains what each result means and what evidence would be needed to support a stronger conclusion.
What we learned
A sophisticated model is not automatically a better model. Our simple recent-history forecasting baseline outperformed the evaluated Ridge alternatives.
We also learned that minimizing surplus alone is insufficient. A useful decision-support system must account for service reliability, data quality, and the possibility of unmet demand.
Transparency is not just documentation. It is a product feature.
Theme Track — Waste impact and how we would measure it
MealLoop OS targets avoidable overproduction and poorly measured food waste in school and institutional kitchens. Its current contribution is a working, testable system for comparing preparation plans and recording operational outcomes; real-world waste prevention has not yet been demonstrated. To evaluate effectiveness, we would conduct a prospective kitchen pilot comparing compatible services under predefined operating conditions. We would record prepared and served portions, independently observed diner counts, unmet demand, and separately weighed discarded surplus, plate waste, and preparation waste. Results would be reported in kilograms per service and grams per diner, alongside measurement coverage and service reliability. Donation and retained food would be accounted for separately from discarded food. Any claim of reduction would require comparable measurements and consideration of attendance, menu changes, and other confounding factors.
What's next
Our next milestone is a real-world kitchen pilot with consistent measurement procedures and operational feedback.
Future development could include demand estimation from prospective data, multiple-menu optimization, shared inventory constraints, and independently evaluated operational outcomes.
MealLoop OS aims to make food waste decisions measurable, explainable, and actionable — without losing sight of the people those meals are meant to serve.
Built With
- alembic
- fastapi
- github
- numpy
- pandas
- python
- react
- recharts
- render
- scikit-learn
- sqlalchemy
- sqlite
- tailwind-css
- typescript
- vite
Log in or sign up for Devpost to join the conversation.