Same dimension, twelve ways to write it

A plumbing buyer types a PO: "send 3 of the 6 inch brass elbows." The next day a different rep at the same shop sends: "3 × BR-ELB, 1/2 ft each." Same elbow. Same catalog item. Two different shapes the matcher has to recognize.

Before this week, SideQuest's parser treated those as different things. The catalog stores items as BR-ELB-6-IN. "6 inch" found the match through the description path. "1/2 ft" didn't. The match score dropped, the line got flagged for review, the CSR retyped it. Friction we built into the product by accident.

v0.15.8 ships a unit normalizer. Every line item gets scanned for dimensional values, and each value gets converted to the family's canonical unit before the matcher runs. The catalog item never moved; the customer's phrasing now translates to it.

What the normalizer covers

Length units flatten to inches. Weight flattens to pounds. Volume flattens to gallons. Inside each family, every common spelling maps to one code. You don't have to teach customers your house style.

Fractions are handled the same way decimals are. 1/2 becomes 0.5. 3/4 becomes 0.75. Mixed numbers like 1 1/2" and 1-1/2 in both resolve to 1.5 inch. Whoever wrote the PO doesn't have to use a calculator.

Why metric matters even on US-only catalogs

You don't carry meter-rated parts. Doesn't matter. The buyer might paste a spec sheet from a Mexican supplier, copy a metric dimension out of habit, or quote a fitting in mm because the original drawing was metric. SideQuest normalizes the metric value to inches before matching, so your BR-ELB-6-IN catalog item still wins the match against a PO line that says 152 mm brass elbow.

Kilometers and miles don't show up in plumbing POs. They show up in cable spec lines for electrical distributors, hose runs for irrigation suppliers, and tape measures for industrial MRO. The normalizer treats them like any other length unit. 2.5 miles of 12-gauge wire resolves the same way 13,200 feet does.

How it shows up in a draft

Each PO line now carries a dimensions field — a list of every dimensional value the parser found, with both the original phrasing and the canonical form. The matcher uses the canonical form to look up your catalog. The operator UI shows both, so when you scan a draft for review you see exactly what the customer wrote and exactly what SideQuest is going to compare against.

{
  "line_number": 1,
  "customer_part": "",
  "description": "1/2 foot brass elbow NPT thread",
  "quantity": "3",
  "dimensions": [
    {
      "value": "0.5",
      "unit": "foot",
      "family": "length",
      "canonical_value": "6.0",
      "canonical_unit": "inch",
      "raw": "1/2 foot"
    }
  ]
}

A description-only line that mentions a dimension is still flagged for review per the v0.15.6 rule — you don't auto-submit a line that has no part number. The difference is the reviewer no longer has to translate the unit. The match candidates SideQuest surfaces have already been ranked using the canonical inch value.

What's not in scope

The normalizer doesn't try to be a unit converter for everything. Currency conversion stays off the table — if your buyer puts £8.50 on a PO line, the parser strips the currency symbol and uses 8.50 as the unit price as-typed. The reviewer decides whether to convert.

Time units (days, weeks, months) aren't in the length/weight/volume families and aren't normalized. They show up in the parsed header as need-by anchors, not as line dimensions.

Temperature, pressure, electrical (volts, amps, ohms) are coming. The pattern is the same — pick a canonical unit per family, write the conversion table, run the regex. If you have a vertical where one of these matters today, send a sample PO and we'll prioritize.

Try it

Paste any PO body with mixed dimensions into the parser playground. The "What SideQuest sees" panel surfaces every dimension found alongside its canonical form. The same parser runs in production — what shows up there is what the matcher sees.