Normalization
One meaning per field, with the original kept beside it.
Normalize labels, units and number formats across suppliers using family-aware rules — and keep the raw label, value and unit so every transformation can be checked.
Draft model public · mapping on request
The problem
Where normalization
usually goes wrong
Most errors come from rules that are applied globally when they only hold for one family or one source.
- 01
Global string rules
“B means width” works until it meets a thrust bearing specified by height, or a supplier who uses B for total width.
- 02
Lost originals
Once the raw label and unit are overwritten, nobody can audit or reverse a mapping decision.
- 03
Silent unit and format drift
Decimal commas, inch values and missing units turn into plausible-looking but wrong millimetre numbers.
Worked example
Three “widths”,
three different fields
Synthetic rows from three suppliers. The rule that maps a label depends on the bearing family and the source’s documented semantics.
Raw
Supplier labels
- S1
- “B” = 12
- S2
- “Width” = 0.472 in
- S3
- “B” = 9 (thrust)
Context
Family + source
- S1
- radial · B = ring width
- S2
- radial · width = ring width
- S3
- thrust · B = height
Normalized
Target fields
- S1
- ring_width = 12 mm
- S2
- ring_width = 11.99 mm
- S3
- height = 9 mm
Open
Kept for review
- S2
- inch → mm rounding
- S3
- source semantics unconfirmed
- all
- raw label retained
Note: S2 converts 0.472 in to 11.99 mm. Whether that should be presented as 12 mm is a presentation rule, not a data change — the stored value and the original both stay available.
Method
Rules you can read,
outputs you can audit
Every normalized value records which rule produced it and from which original.
Inventory labels
Collect every distinct label, unit and format per source and family.
Define target fields
Use the family schema: separate ring width, total width, component widths and height.
Write scoped rules
Rules are conditional on family and source; no universal string-to-field mapping.
Convert carefully
Explicit unit conversion with stated precision; decimal and thousands formats parsed per source locale.
Flag what does not fit
Values outside rules go to review, not into the nearest field.
Outcome and limits
What you get — and what you don’t
Normalized attributes you can filter and compare across brands, each with the raw label, raw value, unit and rule that produced it.
| Detail | |
|---|---|
| Included | Per-family label mapping with written rules |
| Included | Unit and number-format conversion with precision noted |
| Included | Raw label/value/unit retained per attribute |
| Included | List of unmapped or ambiguous columns |
| Not included | A public, universal mapping table |
| Not included | Changes to manufacturer-published values |
| Not included | Engineering interpretation beyond documented semantics |
Delivery options
How it is delivered today
- Preview
Draft family model
Inspect the record envelope and field status model.
View schema - On request
Mapping assessment
We map one category of your files and deliver the rules plus results.
Request - Planned
Reusable mapping library
Versioned per-family rules as part of a maintained service.
Related
Keep reading
Do you change the values manufacturers publish?
No. Normalization changes representation — field, unit, format — and records how. The original stays attached.
Can I get the mapping rules, not just the output?
Yes. In an assessment the rules are part of the deliverable, so your team can review and reuse them.
Send us your worst column.
We’ll show how we’d map it.
Describe the fields that refuse to line up across suppliers. We will reply with a mapping approach and what evidence it would need.