Forecast

Review demand, position, and the next buy for each product.

Run 195 · 365d

Updated 2026-09-01

How to read this page. Everything below is rendered from the live feeds and RPC that the shipped workbench already uses (sources listed on each module). Tags: Current already on main, keep; Fix a real bug on the live page; Lift taken from the retired forecast-tab build (hd/src/components/forecast-tab); New not in either build. Switch to the Customer view to see the same page with no annotations.

Locked 2026-09-01 Forecast list · handed to a separate build session · click to open tiles are the filters · brand / supplier / class / season · SKU and supplier on every row · search by SKU

234 products

Fix Search matches SKU, master SKU and the Amazon title, not only the house name and ASIN. Live page: typing 10263 returns "No products match" because the feed carries no SKU at all (product keys are asin, title, klass, units, revenue; source: forecast_table.json) and the filter only reads title and ASIN (ForecastProductList.tsx). Try it here: 10263, MOM-10263, black suspenders. Fix is two lines in build_forecast_table.py (it already reads raw.product_skus and drops the sku) plus the filter.

New One control: the counts are the filters. Click a tile to filter the list to that queue; the counts recompute inside whatever brand, supplier, class or season window is selected below, so "Need a buy" under Xin Kui is the Xin Kui buy list. Counts come from worklist.json, which the page already loads for dollars at risk but never summarises; brand is raw.products.brand with the SKU prefix as fallback; supplier is raw.product_skus.vendor; season window is worklist timing.

New Each row carries the decision ("Buy 1,728 by Sep 20", "19 days past", "Confirm 3 old POs", "Covered 82 days"). Every field is already in worklist.json; the live row shows only next-3-month units and dollars at risk, so the operator has to open every drawer to find out whether anything needs buying. SKU and supplier sit under the name because that is how the business refers to products.

What is left: the drawer, element by element

Everything below the agenda is the drawer for Suspenders - Black on live data. Numbers link to each element. My recommendation is on the right; you keep, cut or change each one.

Product forecast

Opens as the right-side drawer on the live page; shown inline here so both views fit on one link.

no photo on file yet

New Product photo, top right, from the Amazon listing. No files to store: the catalog already keeps Amazon-hosted image links for 145 of 616 master SKUs and Amazon serves them in any size; the rest get pulled the same way. Suspenders - Black has no link on file yet, so the slot is honest here. Same thumbnail, smaller, on each list row.

New The buy call: one number, one date, one button. If the number rests on overdue purchase orders, one line says so and links to the table; nothing else. Live page for this product shows "Review required · Check open purchase orders" with no quantity and no date, and the recommendation never carries an order-by date at all (orderBy is hard-coded to null in forecastWorkbench.ts). The plan counts 7,200 units from two purchase orders that are 11 months and 7 weeks past their ETA (source: raw.purchase_orders), so the answer is 1,728 if those units are still coming and 8,928 if they are not. Saying both, with the dates, is what makes the number trustworthy. Lead time 63 days is the Xin Kui row in SUPPLIER_LEAD (agents/build_worklist.py), derived from PO history, and is labelled as such.

New Seventh fact: AWD and warehouse stock, the third supply pool next to FBA and inbound. Across the catalog 52 of 220 planned products hold AWD stock (29,222 units) and 13 hold warehouse stock (2,049 units), against 39,714 FBA available; this product holds none. Last-year comparison added under the two plan months (feed ly_units). Source: forecasts.po_recommendations latest run, 2026-09-01.

Supply plan Lift

Projected on-hand at the plan, drawn down week by week, until an order placed today lands.

Lifted from the retired SupplyPlan.tsx, upgraded to show both supply cases. This is the "when do I run out and when must I order" picture that the design note called the biggest gap. Weekly plan is the served p75 daily series from the RPC summed by week; supply cases are FBA available + inbound (confirmed) and the same plus counted open orders (what the recommendation uses). October is the peak month (12,209 units at plan), and the confirmed-only line runs out before it.

Demand Current

Two years agoLast yearPlan

Kept as shipped (Season / Timeline / 13 weeks with Units / Revenue, buyer-language labels from the 2026-09-01 corrections). Rendered here as a static season view only. One delta: the comparison table says next 90 days is 18,346 units while the order math below says 18,146; the two windows should be computed once, from the same run, so the page never shows two 90-day demands.

Current Equation unchanged. Added the plain-English line under it, which the live page lacks. The class policy table (strategy view): . The model's September range for this product runs from . Source: forecasts.class_quantile; forecasts.predictions run 198.

How we got this order Current

Order to a service level Lift

Slider, as asked: 50 to 90 in steps of 5, edge to edge. The model produces bands at 50, 55, 65, 75, 85 and 90; 60, 70 and 80 sit on a straight line between the two nearest bands. Demand is the next 13 weeks, less counted supply, rounded up to the 144-unit case. Bold stop = this class's policy. At 75% it reads 1,872 units here against 1,728 in the order math because the two use slightly different 90-day windows (18,346 vs 18,146 units); the spec makes that one number. Source: forecasts.predictions run 198, forecasts.class_quantile.

Lift Profit verdict replaces the Economics panel. Ace's own ask on the retired build: "sometimes we keep ordering things that lose money, putting a number on it would be amazing." The numbers here are the realised P&L from raw.profit_daily_history (sales less ads, COGS, Amazon fees and refunds), not a modelled margin. Fix The live Economics panel prints unit cost "$1" and net margin "$5" because usd() rounds to whole dollars; the real values are $0.75 and $4.55. And that $4.55 (price less unit cost less ad spend, from forecasts.po_recommendations) ignores Amazon fees and refunds entirely; the realised figure for the last 12 closed months is $2.49 per unit. "Potential missed margin" and dollars at risk inherit the overstatement.

Lift Track record replaces the "Forecast confidence" statistics. The live panel prints "typical error 18.414%" and "within the expected range 75% of the time". The 2026-09-01 presentation doctrine for the customer surface says never a bare accuracy percentage: show what was planned against what happened. Same data (the RPC's canonical-month backtest: 4 closed months, 3 inside the planned range, August surged past it). The raw MAPE and in-band figures stay in this strategy view.

Purchase orders and shipments Current

New Table is unchanged except for the last column: a per-line Close / Confirm action so the operator can resolve a stale line without leaving the product, which is what unblocks the buy above. Every earlier Xin Kui PO in raw.purchase_orders closed at "FBA Check-In"; PO 2138 has sat at that stage since Sep 2025, so it has almost certainly been received and never closed.

Change forecast Current

Reason-gated, versioned override form unchanged (month, units, reason of at least 8 characters, optional evidence, save with version check). Collapsed here only to keep the lab short.

Proposed 10x modules 10x pass

From the game-changing-features pass (session doc: .claude/docs/ai/forecast-workbench/10x/session-1.md). Each is built on real data where it exists and badged where it is not. Not shown in the Customer view until you keep it. Already cut by you on the retired build and not re-proposed: driver strip, Amazon-vs-Sticky, ad-pace.