Why it matters
If one SKU lists "1/2 in", another "0.5 inch", and a third "12.7mm", an LLM cannot reliably answer "half-inch JIC fittings in stock". The three rows describe the same thread size, but the engine reads three different strings. Normalized attributes collapse that into one unit and one format, so the catalog becomes answerable. Without it, your filters miss stock, your AI answers hedge or skip the part, and a buyer assumes you do not carry it.
Normalized vs raw attributes
Raw attributes are whatever each supplier feed, spec sheet, or hand-keyed row happened to contain. Normalized attributes apply rules on top of that source data:
- One unit per field. Pressure in PSI, not a mix of PSI and bar.
- One value format. "0.5" everywhere, not "1/2", "0.5", and ".50".
- A controlled allowed-values list per attribute. "NBR", not "NBR", "Buna-N", and "nitrile" for the same seal material.
In practice
A hydraulics distributor pulls fitting data from a dozen manufacturer feeds. Thread size arrives as inches, fractions, and millimeters; material arrives under three names. They map every variant to one canonical value in the PIM, then publish that to the storefront and the AI layer. Now "half-inch JIC, stainless, in stock" returns the right SKUs, and the answer engine can quote a clean spec instead of guessing across inconsistent strings.