A family grocery that runs on data now.

Toast POS captures every transaction. What it doesn't do is tell you where revenue is headed. For a family grocery with perishable inventory, a bread delivery schedule, and weather-sensitive foot traffic, flying blind on a Tuesday with $4,000 of milk in the walk-in is not a neutral position.

The pipeline ingests nightly from the Toast REST API, builds a medallion architecture on Databricks - Bronze raw JSON, Silver cleaned line items, Gold aggregated daily summaries - and then runs Meta's Prophet forecasting model, tuned to the specific weekly and seasonal patterns of a coastal New England store. The output lands in email before the store opens.

Prophet's out-of-the-box seasonality assumptions aren't built for a shop that does three times the volume in July that it does in February. The model was extended with a New England regional prior, exponentially-weighted recent actuals blended in for the first two weeks, and a horizon-based bias correction derived from 1,409 validated forecast-vs-actual pairs. The result: a model that learns from what actually happened last week instead of blindly extrapolating a trend line.

Toast has an inventory system. It also has a POS system. What it doesn't have is a live view of current stock that accounts for both what was received and what was sold since the last count. Out of the box, that gap grows by however many units you've rung up today - silently, invisibly.

The inventory pipeline ingests every RECEIVE, COUNT, DAMAGE, and INITIAL event from the Toast Retail API every morning at 1am. It then depletes each item's last-known position by every unit sold since that event, using the Silver order items table. The result is a live estimated on-hand quantity that reflects what's actually on the shelf, not what was there the last time someone counted.

Par levels are the second half of the problem. Most SKUs in a specialty grocery don't have configured reorder points - there are too many items and they turn too fast. The pipeline auto-computes suggested par levels from 60-day sales velocity: minimum order quantity is a week of stock, maximum is two weeks. For items with configured levels, those take precedence. Every SKU gets an actionable number.

The tricky part was the items that stopped being tracked entirely. Kneady Mama bread - one of the store's best-selling local vendors - was showing negative 387 units on hand. The inventory system never got a RECEIVE event after January 2026 because the store stopped entering them. The solution: detect items with no recent receive events and flag them as "not tracked" rather than computing absurd phantom quantities. Ninety-three items now correctly show as untracked instead of catastrophically negative.

A specialty grocery's biggest margin leak isn't shrinkage - it's slow-moving product that nobody's watching. A jar of imported jam that sold well in November and sat untouched through February doesn't trigger any alert. It just quietly moves toward waste while its slot on the shelf could be earning its keep.

The Move It dashboard is built on the same daily inventory refresh as the stockout dashboard, but turns the lens in the other direction: instead of what's running out, it surfaces what isn't moving. Every tracked SKU with a last-sold date is ranked by recency and velocity. Items that were selling well six weeks ago and have gone cold show up at the top. Items that have been sitting since before the last inventory count get flagged explicitly.

The supplier-level view is where this earns its keep for buying decisions. Seeing that three of the four products from a particular importer are in the bottom quartile of velocity is actionable intelligence for the next reorder conversation - the kind of thing you'd normally only notice from a gut feeling that the section never quite moves.

Shelf life and category context make the ranking meaningful rather than mechanical. A Bordeaux that's been on the shelf for 90 days is not the same problem as a wheel of brie that's been there for 14. The taxonomy built into the item catalog - category group, category, supplier - lets the dashboard filter down to where the actual decisions happen.

Three dashboards, one underlying system. Every data source - Toast orders, Toast inventory events, Open-Meteo weather - is ingested on a nightly schedule, deduplicated with idempotent MERGEs, and promoted through a medallion architecture that keeps raw data raw and derived data derived. Nothing overwrites anything that shouldn't be overwritten.

The pipeline runs at 2:59am ET. By the time the store opens, the forecast is in the inbox, the inventory positions are recomputed, and the par-level suggestions reflect last night's sales. If anything in the chain fails, the owner gets an email before anyone walks through the door.