Flow
What each key field did in this change
1Category label
Two labels for one family now map to one shared key.
2Size in the name
Sizes in product names are dropped so they can't split the family.
3Store
Stays in the key. Each store sees only its own sales.
4Case size
Stays in the key.
5Price
Was in the first version. A second change the same day took it out.
6Owner
An empty sibling borrows only when exactly one owner exists.
The planner thought one product family was two. In my test, sales sat behind one definition, and the rest came up empty with no way to share.
Two labels, two families
The catalog files this family under two labels that sit side by side. I'd guess the buyer sees one family. Each definition picks its sales by label, and each named just one. So the planner built two IDs and saw two families.
Then it got stuck. Every definition had to claim its own product with sales before the review could pass. My test case has a few definitions and one product with sales. With the old rules, one would get it, the rest would get nothing, and the review would fail. I'd guess the real review broke the same way. The math was fine. The idea of "same" was wrong.
One reviewed pair instead of fuzzy matching
I skipped fuzzy matching. It merges things nobody checked, and a wrong merge still gives totals you'd believe. So the change names just those two labels as one family. New decisions that pick either label get both. Sizes in product names are dropped so they can't split the family. Only definitions with the full pair share a key. All else works as before.
One owner or none
The family now needs one product with sales, not one per definition. An empty sibling can borrow from one owner, as long as that owner covers all of the sibling's stores. If two could be the owner, it borrows from none. The planner does the same per store.
An empty line takes the owner's evidence only when there is exactly one owner.
Price in the key
My first try still put unit cost in the keys. I'd treated price as part of who a line is, just because it was there. My read is that a line at a new price couldn't find its owner and stayed empty. Pools split by price could also each get the same sales, which doubles demand. The commit that fixed it names that case. A second change that day took cost out.
Per-store sales, and the old saved reviews
The tests check that the family shares one key, that one definition owns the product while the rest point at it, one at a new price, and that a second store gets only its own sales. The tests I added don't cover the two-owner case or the double count.
New key rules change what old reviews mean. So the saved format got a new version, and I wrote a one-time script to move old reviews over. It needed a couple of patches, and it was gone the same day.
Other split families
Any other pair the catalog splits gets nothing from this change, and nothing here will flag one for me.