TrayWise

How many portions should tomorrow's kitchen prepare?

In TrayWise's fictional demo, the answer changes from 104 to 113 portions when an operator gives running short three times the penalty of a leftover portion. The forecast stays the same. The preparation decision changes because the operator's priorities change.

TrayWise helps small cafeterias and community kitchens make that daily decision with a learned forecast, visible uncertainty, and a tradeoff they control. Enough for lunch. Room for uncertainty.

Inspiration: sales can hide unmet demand

A kitchen that prepares 97 portions and serves all 97 has recorded a sellout, not necessarily demand of 97. Training blindly on that number can teach a model to repeat the shortage.

TrayWise starts by separating complete observations from lower bounds. A sold-out day with no complete request count stays visible, but is excluded from exact-target training and error scores. If the operator recorded every request, including unserved requests, that count can be used. The distinction is central to the product, not a cleanup step hidden behind a prediction.

What it does

Open the live app and use the labeled fictional history, or import a CSV for one kitchen, menu category, and daily service. Review the observation-quality flags, choose the next service date and a pre-known event flag, then adjust the shortage penalty. TrayWise returns an integer preparation quantity and the historical-error scenarios behind it.

The evidence view compares the learned model with two simple baselines. Warnings call out weak coverage, unfamiliar events, extrapolation, and cases where the selected model loses. An export preserves the inputs, split dates, coefficients, residuals, per-day results, and decision so another person can audit the recommendation. Underpowered data produces an insufficient-evidence state instead of a plan.

How it was built

The application is plain JavaScript, HTML, and CSS, with fitting and inference in the browser and no runtime dependencies or external AI API. CSV contents remain in tab memory; exports download locally. Static assets are hosted on GitHub Pages.

The genuine ML component is ridge regression with learned coefficients for weekday, calendar-day trend, and a pre-known event indicator. It competes against a same-weekday median and a recent-seven-known-days mean. Training-only expanding-window evaluation selects a candidate; ties prefer the simpler baselines. A chronological 60% training / 20% calibration / remaining holdout split keeps later outcomes out of model selection. All three models remain frozen for the holdout.

Signed calibration residuals form historical-error scenarios. An integer optimizer balances surplus and shortfall penalties, with the operator choosing the shortage penalty. Its nominal 80% interval is accompanied by observed held-out coverage; it is not a guarantee about tomorrow.

What the evidence shows

On the public fictional sample, ridge's held-out mean absolute error is 8.81 portions, versus 11.88 for the weekday median and 16.20 for the recent mean. Its interval covers 14 of 21 known holdout outcomes, below the nominal 80% level. These are synthetic results, not evidence of real kitchen savings.

A separate evaluator created six synthetic stress worlds and a NumPy implementation. The original sealed engine matched that independent oracle. The adverse results are preserved: every model had 0/18 interval coverage under abrupt shift, and the training-selected model did not always win on unseen data. A later adversarial audit found a floating-point tie case in the optimizer; the fix passed 5,509 post-inspection regression assertions. The published app also passed 20 development tests and four real-browser tests, including desktop/mobile interaction and import/export checks.

The full evaluation report is linked in the app and included in the repository. Test passes demonstrate implementation behavior, not general forecasting reliability.

Climate fit and next steps

TrayWise addresses the AI + Climate prompt's resource-use goal at the preparation decision, where overproduction can become avoidable food waste. Its intended value is helping an operator examine waste and service tradeoffs before cooking, while keeping the final choice human-controlled.

The current prototype has no measured food, carbon, financial, or user outcomes, and no real-kitchen pilot. The next step is a prospective, consented pilot that records complete requests, leftovers, and service shortfalls, compares the existing planning process, and checks whether recommendations are useful. Richer accounting for donations, spoilage, and staff meals would be needed before expanding the scope.

Hackathon disclosure

Built for ForgeHacks Online 2026, AI + Climate, after the October 3 prompt release. AI-assisted coding and AI-generated narration were used. The application core, UI, and fictional demonstration data were created for this entry; no earlier campaign application core or dataset was reused. Solo entry by Sharon Basovich.

Built With

• css3
• github
• html5
• javascript
• machine-learning
• node.js
• numpy
• playwright
• python
• ridge-regression