When a store or partition has too little sales history to trust its own size curve, Toolio borrows the size curve from a wider scope that has enough data. This is called Level Hopping. The block keeps its own sales volume in the backend. Only the split across sizes changes (based on fallback weights assigned).

This article walks through every step with a single small example, so you can see why a value changed and which setting to adjust.

Go to Settings > Intelligence > Size Curves and click Add, or right-click a curve and click Edit. The settings appear in the Dynamic section, below Exclude Markdown Sales.

Changes to Min Threshold %, Prioritization, partition attribute order and like sizes are re-applied to the current curve without regenerating it. The update runs in the background, so the new values show once it finishes. A curve last generated before Level Hopping was turned on needs one generation first. Changes to Minimum Sales per Choice or to which partition attributes are used take effect at the next generation.

Every step below uses the same small curve:

Toolio runs the steps in this order. The location test only looks at partition groups that passed Step 2. The size tests in Step 4 use all of the curve's data, including partitions and locations that failed.

Before any test runs, Toolio adds up each choice's sales across all locations, within the curve's time frame and filters. A choice that sold less than Minimum Sales per Choice is left out of the curve completely. We only use the remaining larger choices for size curve calculations.

This total is taken before the Good Weeks filter. If no choice reaches the minimum, the curve is empty and shows a warning.

Each partition group's total sales and total data points are compared with the average partition group in the curve. A partition group must pass both.

Mens · Outerwear has enough data points but too few sales, so it fails. Because it fails, every Mens · Outerwear block in every store borrows its size curve in Step 5. Its data is also kept out of every wider scope calculation, so it never affects another block.

Within each partition group that passed, each store is compared with the other stores in the same channel that sell that partition. A store is judged per partition, not on its overall size.

Womens · Tops, Retail stores

Womens · Dresses, Retail stores

Store C sells very few Tops but plenty of Dresses. Its Tops block borrows a size curve, while its Dresses block keeps its own and can be used by other blocks.

Store D shows why data points matter. It sold 500 Dresses, which clears the sales threshold, but those sales came from only 150 choice-weeks, for example a few big promotion weeks. That is too little evidence to trust, so its Dresses block borrows a size curve too.

The Ecom location is only compared with other Ecom locations, never with Retail stores.

The sizes are tested in two ways.

Each size's total sales and data points across all locations and partitions are compared with the average size.

A size that fails here is too thin almost everywhere, so borrowing from a wider scope won't fix it. Toolio marks it as insufficient data, shows a warning, and recommends a like size (Step 7). It is left out of the per-block size test below, so XS alone does not make every block fall back.

Within each block, each size's share is compared with its share of the whole curve. A size fails if its share in the block is below 20% of its curve share. This is checked on sales and on data points, and a size must pass both. XS is left out, because it already failed across the whole curve.

Store A × Womens · Tops, sales (block total 2,000)

Store A × Womens · Tops, data points (block total 2,400)

Store A is a strong store and Womens · Tops is a strong partition. The block still borrows a size curve, because one size inside it is too thin. A size with no history at all in a block counts as 0 and fails the same way.

A block that failed any test hops up a ladder of wider scopes. It stops at the first scope that has sales. Only blocks that passed every test feed these scopes, so thin data never spreads to other blocks.

The ladder depends on Prioritization and on the partition attribute order. For our curve (Gender, then Category):

Store C failed the location test for Tops (Step 3), so its 200 units need a size curve from somewhere else.

With Hop Product First, Store C borrows from its own Dresses, because Store C × Womens · Tops failed and Dresses is the only Womens partition left in that store. With Hop Location First, it borrows from the other Retail stores' Tops. Store A is not in that pool, because its Tops block failed the size test in Step 4.

Every Mens · Outerwear block failed in Step 2. With Hop Location First, steps 1 and 2 (Channel and All locations × Mens · Outerwear) are empty, since none of those blocks passed. The block moves on to step 3, Location × Mens, and borrows from the store's own Mens · Tops.

If no step on the ladder has any sales, the block keeps its own size curve and a warning message is shown.

The block keeps its own total. Every size in the block, not only the one that failed, takes the borrowed size curve.

New value = block total × (size sales in wider scope ÷ total sales in wider scope)

Store A × Womens · Tops, filled from step 1 of Hop Product First (Store A × Womens). The only Womens block in Store A that passed is Dresses, which sold 900 units.

The store still gets 2,000 units' worth of weight, so its volume compared with other stores doesn't change. XXL is fixed. XS is still 0, because nobody sells XS in this scope either. Step 7 handles that.

A size that is still thin after hopping, like XS here, can borrow from a similar size. Open the curve with Edit and expand the Size Summary section. Sizes marked Insufficient data are the ones to fix.

In every block, the size gets its like size's value × the ratio. Then the whole block is scaled back to its own total.

Store A × Womens · Tops, XS = S × 0.5

Rules for like sizes:

On the curve's spread view, a System % of TTL cell that was filled by Level Hopping or a like size shows an info marker in its corner. Hover over it to see where the value came from:

A warning banner above the spread grid explains problems with the curve:

In the Edit dialog, a yellow banner lists the sizes that don't have enough data and points you to Size Summary. Once every thin size has a like size, it changes to Like sizes assigned. Save to recalculate the size curve.

Your own edits always win. Toolio uses the value in this order:

Level Hopping never overwrites an adjusted value. To go back to the system value, right-click and use Remove Overrides.

The size test runs inside every block (Step 4). A strong store in a strong partition still borrows if one size in that block is far below its usual share. Check the size with the lowest share in that block.

The size is thin across the whole curve, so no wider scope can fix it. Assign it a like size and ratio in Size Summary. You can also lower Min Threshold %, or remove the size and build a separate curve from the products that carry it.

A stored adjusted value now counts as an override even when it equals the system value. Older curves can have these values from earlier edits. Use Remove Overrides to clear them.

Attributes are used in the order you select them in Partition Attributes. The last one is dropped first while hopping. To change the order, remove the attributes and select them again in the order you want.

Not within one curve. Level Hopping can drop every partition attribute, so a Mens block can end up borrowing a size curve built from Womens sales at the All partitions steps. Putting Division first in Partition Attributes only makes it the last attribute dropped. It does not stop the hop.

When sizes sell very differently across an attribute, build a separate curve for each value. For example, create one curve with the filter Division equals Mens and another with Division equals Womens. Each curve then only borrows within its own division.

Yes. The tests work the same way, on both sales and data points. Good Weeks only changes which weeks are counted as data points: only good weeks when it is enabled, and every week with a sales or inventory record when it is not.

Changes to Min Threshold %, Prioritization, attribute order and like sizes are re-applied without regenerating, once the background update finishes. This needs the curve to have been generated at least once with Level Hopping on. Changes to Minimum Sales per Choice or to which partition attributes are used apply at the next generation.

Not to keep them working. Existing curves keep working as they do today once Level Hopping is turned on. To use Level Hopping, a curve needs one generation: either its next scheduled update, based on Update Cadence, or right-click and click Generate. Until then, changes to the Level Hopping settings wait for that generation. New settings start at their defaults, and your overrides are kept.

Lower it when too many blocks borrow and you trust your stores' own size curves. Raise it when noisy, small stores are distorting allocations.