The Retail Report: Forecasting Without History

Aquerius Mercury is an Agentic Operations System (OS) for mid-market retail operations. One of its core capabilities is a Demand Planning workbench, built on top of a temporal semantic knowledge graph that includes an ensemble planning algorithm. 

A False Assumption

Forecasting has been a core process for businesses to make various kinds of predictions that support business decisions. Legacy forecasting systems are built on the assumption that the best predictor of future demand is prior year's data. Within these legacy systems, a planner generally uploads a prior year's sales history, the system applies a seasonality curve or growth rate on top of it, and a forecast is created. This works reasonably well for an established product with several years of stable sales behind it and continued interest in the product ahead of it. It offers nothing at all for a product that has never been sold before.

When launching a new product, a core aspect of the process requires predicting demand, revenue, and other factors that can tie into sales, brand power, and projected interest. New products generally don't have previous year sales data, because the product is brand new. Where most people trip is thinking that the forecasting problem for a new product is a harder version of the forecasting problem for an established one. This is incorrect. It is a different problem entirely, and most legacy systems are not equipped to handle it

The Two Workarounds

Legacy systems tend to handle this gap in one of two ways: 

1. Borrow Sales History of Analogous Product. Most planners lean towards borrowing the sales history of an existing product and treating it as a proxy for the new one. The success of this approach depends entirely on the planner's judgment of which product truly serves as a proxy. Decisions like this are usually made once, early in the process of launching, under severe time pressure, and are rarely revisited. When a new product behaves differently from its assigned proxy, the proxy's forecast quietly diverges from reality, and by the time the difference becomes visible in the sales data, the decisions the proxy was meant to inform have most likely already been made.
2. Forecast Blind Until Data is Collected. Another approach is to forecast blind for the first several selling cycles, so essentially operating without the system's help until enough real sales data accumulates to make it usable again. This solves the data problem eventually, but only after the period it was needed for has passed. By the time a new product has generated enough of its own history to forecast reliably, the important decisions tied to that launch have already been made in the absence of any real forecasting support.

Why Timing Matters

Both workarounds expose the same limitation. A system built to project a known history forward has no real system for reasoning about a product for which no history exists. It can only wait for history to accumulate or ask a human to approximate it artificially.

When this happens, it is more than a simple inconvenience. The launch window is the period in which a new product carries the least room for error and the highest cost of getting demand incorrect. Overcommitting inventory on a launch that underperforms leaves a brand carrying dead stock on a product it has no sales history to justify discounting intelligently against. Undercommitting on a launch that succeeds leads to a brand missing the exact window in which early sales momentum, retailer confidence, and customer attention were most available to capitalize on. Either error is more expensive at launch than it would be for an established product, because there is no accumulated history to soften the miss or inform a speedy correction. In other words, legacy forecasting is least capable exactly when a brand needs it most.

How Aquerius Helps

Built on top of Aquerius platform, Mercury treats new product forecasting as its own problem, not a data gap to wait out.

Mercury replaces the single analyst's analogue guess with a systematic similarity search. At launch, it scores every existing SKU against the new product. It compares price tier, category, channel mix, seasonal profile, and attribute overlap. It blends the top matches into one baseline forecast, weighted by similarity, not by recency.

Mercury also pulls in external signals at the time of launch. It reads Google Trends data for the product's keyword cluster. It reads pre-order and reservation volumes. It reads wholesale sell-in from distributor EDI feeds. It reads category-level POS trends from retail panel data.

Mercury combines these signals in a Bayesian ensemble model. The model holds a wide uncertainty range before launch. It narrows that range fast once real sales data arrives, typically within the first two to four weeks. Each new week of sell-through data updates the forecast. Mercury does not wait for a full demand cycle to complete.

‍