Clickable
Demos
The proposed screens, running. These are real HTML built on the Food4Life design system —
not images — so you can look at them at any size and read every number.
Interactive prototype
Working software, not a picture. Plan a week, watch compliance re-score as you edit, ask for a
fix and apply it, and walk a count sheet end to end.
Plan a week
Move between weeks, add and remove items from any day, toggle service.
The compliance panel recalculates on every change — real USDA arithmetic over the real
recipe catalogue.
Ask for a fix
Open any shortfall, see ranked options with every side effect, preview
without committing, then apply and watch the week’s score move.
Walk a count
Kitchen mode: tap through a storage area, see variance the moment a
number differs, hit the every-line gate, then submit and lock.
Run the approval
Submit a menu, switch role to District Manager in the sidebar, send it
back with a required reason, then approve and publish. The rail tracks where it is.
Fix the catalogue
Library shows real crediting coverage and the four recipes with
impossible values. Edit one that’s on the July menu and the week re-scores.
Check the evidence
Records is the locker. Lock a count in Kitchen mode and it appears here,
with an amendment path a District Manager approves.
The numbers are real. The engine reproduces the production compliance
calculation exactly — weekly grains 1.25 against a 5.00–5.50 target, M/MA 2.50 against
5.00–6.00, and all five daily metrics passing on July 1 — matching what staging shows
today. It scores against the real NSLP requirement table and the real 32-recipe catalogue.
What the prototype exposed. Four recipes in the production catalogue carry
crediting that cannot be right for one K–5 serving — a vegetable side crediting
12 oz eq of grain, a pizza crediting 46 cups of starchy vegetable.
Eight more have no nutrition data at all, so their side effects can’t be computed. The engine
refuses to suggest from any of them and says why, which leaves 20 of 32 recipes
usable. Open any shortfall to see the exclusions.
Static screens
The four surfaces as designed, for reference. Each opens full-size below.
What’s real here. The menu contents, every compliance value, and the
catalogue counts come from the live staging API. The production-record and count states, the
work-queue split and the sidebar badges are illustrative — staging holds no production
records or submitted counts to measure.
The design system, running
Taher’s own Food4Life kits, for comparison against the proposal above.
What comes next
Where these demos are heading.
-
Done
Static screens. The four surfaces, pixel-accurate in the real design
language, with real data.
-
Done
Clickable flows. Week navigation, add and remove items, live re-scoring,
ranked fixes with preview and apply, and the full Kitchen count loop — including the
every-line gate and submit-and-lock. Front-end only; seeded from real staging data.
-
Done
The rest of the surfaces. Home, Menus with the full approval lifecycle,
Library with a crediting editor that moves the menu’s score, and Records. Plus a role
switcher, so the Director and District Manager views can be compared directly.
-
Done
Sites and portfolio scale. The org tree, editable order schedules, the
holiday calendar, and a twelve-site district roll-up where every figure is scored by the
same engine that scores one school — drill into any site and back out again.
-
Next
Wired to staging. The same screens reading the real API instead of seeded
data, so the demo becomes the product. This is where the phasing in document 3 begins,
and where the aggregate endpoint for district scale is actually needed.