SurplusSync

Schools often overprepare meals, while food banks hear too late. SurplusSync tells schools how many meals to prepare and gives food banks early notice to coordinate safe, human-approved recovery.

Comment

Inspiration

School cafeterias must decide how many meals to prepare before they know exactly how many students will attend or choose to eat that day.

Attendance can change because of field trips, exams, early dismissals, weather, school events, sports absences, and even menu popularity. Preparing too many meals creates avoidable food waste, but preparing too few can create a shortage risk for students.

There is also a second problem. Even when usable surplus remains, food banks and recovery organizations may learn about it too late to arrange capacity, transportation, volunteers, storage, and food-safety checks.

We realized that reducing cafeteria waste requires more than a dashboard that reports what was thrown away. Schools need support before meals are prepared, and food-recovery partners need visibility before a possible pickup becomes urgent.

That inspired SurplusSync: an AI-assisted decision-support platform that helps schools determine how many meals to prepare and gives recovery partners earlier visibility into potential surplus—while keeping preparation, food-safety, partner selection, and pickup decisions under human control.

What SurplusSync Does

SurplusSync supports two connected decisions:

  1. How many meals should the cafeteria prepare?
  2. How can possible surplus be identified early enough for safe recovery planning?

The platform forecasts expected meal participation, displays an uncertainty interval, recommends a preparation quantity, estimates shortage probability, and shows how much avoidable surplus could potentially be prevented.

The recommendation is not treated as an automatic command. Cafeteria staff can inspect the evidence, correct operational assumptions, simulate changes, and approve or reject the recommendation.

When possible surplus is identified, the recovery workflow provides early planning visibility. Before any partner action can proceed, authorized staff must confirm that surplus actually exists and complete the required operational and food-safety prerequisites.

The food bank sees this only as an early planning signal. It must contact and confirm with the cafeteria manager before treating any quantity as available, safe, reserved, or ready for pickup.

SurplusSync does not automatically contact food banks, reserve capacity, declare food safe, schedule transportation, or confirm a completed transfer.

Local Demonstration

Our reproducible demonstration focuses on a synthetic operational scenario:

  • School: Lincoln Heights Public High School, Chicago
  • Date: Thursday, March 12, 2026
  • Normal preparation plan: 730 meals

The initial forecast estimates:

  • Expected attendance: 528
  • Uncertainty interval: 497–557
  • Recommended preparation: 562 meals
  • Estimated preventable surplus: 168 meals
  • Estimated shortage probability: 4.1%
  • Risk level: High

Instead of showing only a confident-looking number, SurplusSync displays the range of plausible attendance outcomes and the tradeoff between reducing waste and protecting students from shortages.

In the demonstration, a staff member receives corrected attendance information and updates the expected attendance to 540. The system recalculates:

  • Updated uncertainty interval: 512–568
  • Updated preparation recommendation: 575 meals
  • Updated preventable surplus: 155 meals
  • Updated shortage probability: 3.4%
  • Safety floor: 540 meals

The change is first presented as a pending proposal. It does not alter the operational plan until an authorized human approves it.

All figures in this scenario are synthetic and demonstration-only. They are not claims about the performance of a real Chicago school.

How We Built It

SurplusSync is organized as three connected services.

1. Web Application

The user experience is built with TypeScript, React, and TanStack Start and includes:

  • a Command Center for the school-day workflow;
  • a Forecast Horizon Ribbon;
  • a Surplus Radar;
  • a Decision Canvas;
  • uncertainty and shortage-risk displays;
  • an Evidence Drawer;
  • attendance what-if simulations;
  • an Approval Gate;
  • a recovery-partner map;
  • a food-safety and operational checklist;
  • a pickup-planning timeline;
  • an Impact Ledger;
  • an append-only Audit Storyline;
  • partner and administration views;
  • a guided demonstration.

Browser requests pass through same-origin server routes so private service credentials and optional AI model keys are not exposed to the client.

2. Forecasting Service

The forecasting service is built with Python, FastAPI, CatBoost, Pandas, NumPy, and scikit-learn-compatible evaluation tools.

It uses three CatBoost regressors:

  • a point attendance model;
  • a lower-quantile attendance model;
  • an upper-quantile attendance model.

The model considers structured school-day factors including:

  • weekday and calendar information;
  • enrollment and meal eligibility;
  • field trips;
  • examinations;
  • early dismissals;
  • assemblies and sports absences;
  • weather conditions;
  • menu type and popularity;
  • recent seven-day and fourteen-day attendance patterns.

The forecasting layer returns an expected attendance value and an uncertainty interval.

A separate safety-oriented recommendation policy combines the point forecast, upper uncertainty estimate, safety buffer, safety floor, and eligibility constraints to recommend a preparation quantity.

For impact estimates, the prototype calculates preventable surplus as:

Preventable surplus = normal preparation − recommended preparation

For the initial demonstration:

730 − 562 = 168 meals

This produces an estimated preventable surplus of 168 meals.

However, a recommendation is not automatically counted as meals saved. SurplusSync keeps forecast, proposed, approved, scheduled, and confirmed outcomes separate.

3. AI Assistant and Proposal Service

The assistant service is built with TypeScript, Node.js, Express.js, and the Google Gemini API.

It explains forecast evidence, answers operational questions, runs simulations, and can create pending proposals.

The assistant does not create the underlying attendance forecast and cannot approve its own proposals.

Optional generative AI converts verified system evidence into plain-language explanations. When generative output is unavailable, SurplusSync uses a deterministic explanation fallback. Forecasting and safety controls continue to work independently of the language-generation layer.

Consequential actions are revalidated by server-side rules before approval. These rules check:

  • user authorization;
  • proposal freshness;
  • current operating mode;
  • surplus confirmation;
  • checklist completion;
  • recovery windows;
  • partner eligibility;
  • cancellation or reset conflicts.

System Architecture

The platform follows a clear operational flow:

School-day and operational inputs
        ↓
Attendance and meal-demand forecasting
        ↓
Uncertainty interval and shortage-risk calculation
        ↓
Safety-oriented preparation recommendation
        ↓
Human review and approval
        ↓
Surplus confirmation and recovery prerequisites
        ↓
Human-approved partner coordination
        ↓
Impact and audit tracking

The system contains three main services:

TanStack Start Web Application
        ↓
Same-Origin Server Gateways
        ↓
FastAPI Forecasting Service
        +
Node.js AI Assistant and Proposal Service

Service credentials, tokens, and optional Gemini keys remain on the server rather than being exposed to browser code.

Data and Evaluation

Because we did not have permission to use private school cafeteria records, we created a synthetic dataset covering school business days from August 2023 through June 2026.

The synthetic records model plausible relationships among:

  • attendance;
  • enrollment;
  • school events;
  • field trips;
  • examinations;
  • weather;
  • recent attendance trends;
  • menu popularity;
  • normal preparation behavior.

No private or student-level personal data is used.

On the synthetic holdout set, the point attendance model produced:

  • Training rows: 551
  • Test rows: 138
  • Mean absolute error: approximately 13.84 students
  • Root mean squared error: approximately 19.71
  • R²: approximately 0.619
  • Approximate 80% interval coverage: 78.99%
  • Mean interval width: approximately 42.23 students
  • Weekday-only baseline MAE: approximately 24.50 students

These results suggest that the model learned useful interactions beyond a simple weekday-only rule.

However, they remain synthetic-data results and must not be interpreted as validated performance in a real school.

The current shortage probability is also a prototype heuristic rather than a fully calibrated production probability.

Responsible AI Design

The most important risk in SurplusSync is under-preparation.

A model that focuses only on minimizing waste could recommend too few meals and negatively affect students. We therefore designed the system around uncertainty, safety constraints, and human judgment rather than maximum waste reduction.

Our safeguards include:

  • visible uncertainty intervals;
  • shortage-probability estimates;
  • an explicit safety floor;
  • a preparation safety buffer;
  • evidence and assumption displays;
  • what-if simulation before execution;
  • role-based approval gates;
  • proposal-expiration and freshness checks;
  • a strict manual operating mode;
  • server-enforced recovery prerequisites;
  • deterministic fallback behavior;
  • append-only operational audit history.

The AI is not authorized to:

  • finalize meal preparation by itself;
  • deny meals to students;
  • declare surplus food safe;
  • contact recovery partners automatically;
  • reserve partner capacity;
  • schedule or confirm pickups;
  • confirm that a transfer was completed;
  • delete audit history;
  • bypass manual mode or human approval.

This division is intentional: machine learning helps forecast uncertain demand, while humans remain responsible for safety, context, and consequential action.

Impact

SurplusSync addresses food waste at two stages.

Prevention

It helps cafeterias avoid preparing meals that are unlikely to be needed while preserving a safety buffer against shortages.

Recovery Readiness

When surplus may still occur, the platform makes that possibility visible earlier so authorized school staff and recovery organizations can prepare for a potential transfer instead of discovering it too late.

This earlier visibility can help recovery partners assess:

  • available capacity;
  • transportation;
  • volunteers;
  • storage;
  • operating hours;
  • food-handling requirements;
  • appropriate pickup windows.

This visibility does not confirm a donation. The recovery partner must verify the actual quantity, food-safety status, and pickup window directly with the cafeteria manager before proceeding.

Verified Outcomes

The Impact Ledger distinguishes among:

  • forecast impact;
  • proposed preparation changes;
  • approved preparation changes;
  • scheduled recovery;
  • confirmed recovery;
  • nonrecoverable surplus.

A recommendation is not automatically treated as meals saved, and a scheduled pickup is not treated as a completed delivery.

Environmental and carbon figures are presented as estimates rather than measurements. Projected or annualized values are clearly labeled and are not reported as observed real-world impact.

Challenges We Faced

Balancing Waste Reduction With Student Protection

The easiest way to display a large waste-reduction number would have been to recommend an aggressive preparation cut. That would not be responsible.

We had to design the recommendation around uncertainty, shortage probability, and a safety floor rather than optimizing only for waste reduction.

Making Synthetic Data Useful Without Making False Claims

Synthetic data allowed us to demonstrate the complete system without collecting private student records.

The challenge was ensuring that every metric, model result, and impact estimate remained clearly labeled as synthetic, calculated, estimated, or projected.

Separating AI Assistance From Operational Authority

An assistant that can explain recommendations is useful. An assistant that can silently change preparation quantities or schedule pickups would create serious risks.

We created a proposal-and-approval architecture so the assistant can explain, simulate, and suggest without approving itself or executing consequential actions.

Representing Real Recovery Constraints

Surplus recovery is not simply matching a school with the nearest food bank.

Actual recovery depends on:

  • whether surplus really exists;
  • whether the food is safe;
  • whether required checks are complete;
  • whether the partner is eligible and available;
  • whether the partner has enough capacity;
  • whether pickup can occur within an appropriate recovery window.

We built these prerequisites into the workflow instead of presenting recovery as automatic.

Keeping Three Services Consistent

The frontend, forecasting API, and assistant service all had to display the same scenario, assumptions, terminology, and lifecycle states.

We created a contract-locked canonical demonstration and automated validation checks to prevent contradictory numbers across the interface, APIs, tests, screenshots, and video narration.

What We Learned

We learned that uncertainty should not remain hidden inside a model. It must shape the product interface, recommendation policy, and approval workflow.

We also learned that prediction alone does not create impact. A forecast becomes useful only when it is connected to a specific decision, a responsible human, and a realistic operational process.

Most importantly, we learned that responsible AI is not a disclaimer added at the end of a project. It affects the architecture itself:

  • what the model is allowed to calculate;
  • what the assistant may explain or propose;
  • what the server must validate or block;
  • what only an authorized human may approve.

Accomplishments That We Are Proud Of

We are proud that SurplusSync is more than a food-waste visualization.

It provides:

  • an uncertainty-aware forecasting pipeline;
  • comparison with a simple weekday baseline;
  • a safety-oriented preparation recommendation;
  • human correction and approval workflows;
  • server-enforced recovery safeguards;
  • deterministic fallback behavior;
  • lifecycle-aware impact tracking;
  • an append-only operational storyline;
  • a reproducible guided demonstration;
  • a unified, testable repository containing the web, assistant, and forecasting services.

What Is Next

The next step would be a controlled pilot with a willing school cafeteria and a local food-recovery organization.

Before production use, we would:

  • replace synthetic training data with authorized, aggregated historical records;
  • validate and calibrate forecasts across multiple schools;
  • calibrate shortage probabilities using real outcomes;
  • compare performance with additional non-AI baselines;
  • adapt safety floors to district requirements;
  • add production authentication and durable audit storage;
  • monitor model drift and seasonal changes;
  • validate food-safety and donation workflows with local experts;
  • test accessibility and usability with cafeteria staff and recovery coordinators;
  • measure preparation accuracy, shortage frequency, recovery lead time, and confirmed outcomes.

SurplusSync is not intended to replace cafeteria staff or food-recovery professionals. It is designed to give them earlier, clearer, and safer information so they can make better decisions before food becomes waste.

Built With

Share this project:

Updates