What does normalization mean in piping procurement?

Normalization is the process of converting any piping material description into a single, unique product code. The same 6" seamless A106 Gr.B pipe can appear in an MTO in many different formats. Our engine recognizes all variants and maps them to one unique code, enabling automated comparison, budgeting, and bid tabulation.

How does the engine handle different languages?

The engine maintains lookup tables for piping terminology in 12+ languages. Italian, German, and English descriptions all resolve to the same normalized output. Language detection happens at the field level, so a single RFQ can mix languages across columns and the engine still works.

Core Technology

The Normalization Engine

Q: Why not use AI or machine learning for normalization?

Piping specs require 100% accuracy. AI/LLM models are probabilistic and can hallucinate. Our rule-based engine is deterministic: same input always produces the same output, every rule is traceable, and results are audit-ready. In piping procurement, 95% correct is not acceptable.

Q: What happens when the engine can't identify a line item?

It flags the item for manual review instead of guessing. If a description is too ambiguous, has conflicting specs, or refers to a product outside the supported range, the engine marks it clearly and tells you why. No silent failures, no invented codes.

Q: How does the engine handle size conversions (metric vs. imperial)?

The engine uses dimensional tables from ASME, EN, and ISO standards to resolve sizes. A pipe described as 168.3mm OD x 7.11mm WT and one described as 6 inch SCH40 are the same product. The engine maps both to a single code because it knows the actual values from standard tables, not from pattern matching.

Q: What is the unique product code?

A deterministic hash (SHA-256) generated from the normalized technical attributes of a product. Two descriptions that look completely different but describe the same pipe, fitting, or valve will always produce the same code. Over 3 million unique codes are currently mapped.

3M+ product codes. 98% precision. 100% deterministic.

Why It Matters

No matter how a client writes an RFQ, the Engine reads it, matches it to your catalog, and prepares the quote.

RFQ_Offshore_Platform.xlsx

Tag No.	Pipe Type	Material Grade	OD	Thk	Length (m)
L-101	Seamless	A106 Gr.B	168.3	7.11	500
L-102	Welded	A312 TP316L	60.3	3.91	120

Engine output

Line Item	Normalized Code	Normalized Description	Qty	Unit Price	Total Price
1	PIP-7F3A9E2B	PIPE SMLS A106 GR.B 6" SCH40	500m	$12.40/m	$6,200
2	PIP-4B2C8D1A	PIPE WLD A312 TP316L 2" SCH40S	120m	$28.60/m	$3,432

Products

Pipes, fittings, flanges, valves, gaskets, bolts

Languages

English, Italian, German, Arabic, Chinese, and more

Deterministic

Rule-based. No AI hallucinations. Industry rules behind.

AI Can't Normalize Reliably

LLMs are probabilistic: same input, different output. You'd spend a fortune in API tokens and still not trust the result. Try it: feed an RFQ and your inventory to AI and request a match. Good luck.

AI / LLM

Probabilistic

"Maybe 95% correct"

Hallucinations on edge cases
Different output each run
"Why?" → "I don't know"
Can't pass audit

Rule-Based Engine

Deterministic

100% consistent

Traceable: see exactly which rule matched
Reproducible: same input = same output
"Why?" → exact rule reference
Audit-ready documentation

No black boxes. No probabilistic guessing. No unexplainable results.

3 Million Products. Normalized.

The largest piping classification database in the industry.

Pipes

Valves

Fittings

Flanges

Gaskets

Bolts

Sizes 1/8" to 80" | Standards ASME · API · EN · ISO · MSS | Materials CS · SS · Duplex · Nickel Alloys

Product Codes

Languages

Precision

Engine Backed by Piping Deep-Knowledge

The engine catches technical errors before they become expensive problems.

WN Flange Without Schedule

Weld-neck flanges require bore schedule. Missing = wrong bore diameter = weld defect.

EN Dimensions on ASME Product

DN 150 x 6.3mm on ASME B36.10 pipe. Standards don't mix. Product doesn't exist.

Schedule S on Carbon Steel

SCH 5S, 10S, 40S are stainless steel schedules. Carbon steel uses SCH 5, 10, 40.

Wrong Material for Service

A105 fittings with A312 pipe? A105 is carbon steel forging, A312 is stainless. Mismatch.

Non-Standard Dimensions

6" SCH 30 doesn't exist in B36.10. Someone invented a schedule that no mill produces.

Incompatible Pressure Class

Class 150 flange mated to PN 40 valve. Different drilling patterns. Won't bolt up.

Under the Hood

Built in Python. Backed by PostgreSQL. 6 years of development time.

Lines of code

Test coverage

REST API

JSON in, JSON out

<200ms

Per line item

Python

PostgreSQL

Docker

CI/CD

4,200+ Tests

ASME / EN / ISO

~500,000 Piping Codes. 50+ Years of History.

MESC Started Codes Standardization.

We Finished it.

Shell's MESC pioneered piping product standardization with ~500,000 piping codes. We took that vision further: an open system with 3M+ codes, covering every standard, every material, every size. No licensing restrictions.

Read the full MESC story

Common Questions

Technical questions about the engine.

What does the engine actually do?

RFQs and MTOs come in every format imaginable: different languages, abbreviations, column layouts, units. The engine parses each line, interprets what product is being described, detects errors (wrong schedules, impossible sizes, incompatible ratings), and matches it to your inventory. It doesn't just read text. It understands piping: it knows that SCH 30 doesn't exist in B36.10, that a Class 150 flange won't bolt to a PN 40 valve, and that "A106 Gr.B" and "P235GH" are not interchangeable. Both the RFQ and your inventory are normalized the same way, so matching is automatic: the engine finds what you have in stock, generates the quote, and flags what's missing.

Why not use AI or machine learning for normalization?

Try it yourself: upload an RFQ and your inventory to ChatGPT and ask it to match items and generate a quote. You'll get a result that looks convincing but is full of wrong matches, invented specs, and missed items. LLMs are probabilistic, so every time you run the same request you get a different output. You'd have to review every single line manually, which defeats the purpose. Our engine is deterministic and rule-based: same input, same output, every time. Every match is traceable, every error is flagged, and the quote is generated automatically.

How does the engine handle messy descriptions?

Real RFQs are full of abbreviations (SMLS, BW, RF, SW), typos, OCR artifacts, truncated descriptions, and inconsistent formatting. "A106 GR.B", "A106-B", "A106 Grade B", "ASTM A 106 GRB" are all the same material. The engine doesn't do simple string matching. It parses each description semantically, recognizes known abbreviation patterns, tolerates common misdigitations, and resolves ambiguities using piping industry rules. If something is genuinely unreadable, it flags it instead of guessing.

What happens when the engine can't identify a line item?

It flags the item for manual review instead of guessing. If a description is too ambiguous, has conflicting specs, or refers to a product outside the supported range, the engine marks it clearly and tells you why. No silent failures, no invented codes.

How does the engine handle size conversions (metric vs. imperial)?

The engine uses dimensional tables from ASME, EN, and ISO standards to resolve sizes. A pipe described as "168.3mm OD x 7.11mm WT" and one described as "6 inch SCH40" are the same product. The engine maps both to a single code because it knows the actual wall thickness and OD values from standard tables, not from pattern matching.

What is the unique product code?

A deterministic hash (SHA-256) generated from the normalized technical attributes of a product. Two descriptions that look completely different but describe the same pipe, fitting, or valve will always produce the same code. This is what makes automated matching possible: if the code matches, the product matches. Over 3 million unique codes are currently mapped.