What does the normalization engine do for piping stockists and mills?

It reads buyer RFQs and MTOs in any format, parses each line, identifies the product, and matches it against the supplier catalog using deterministic rules. Stockists get matches against current stock, mills get matches against production range. The engine then applies the supplier's pricing rules and returns a ready-to-send quote, with unmatched items flagged for review.

How does the engine handle RFQs in different languages?

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

What happens when an item is not in the supplier catalog?

The engine flags it for manual review instead of guessing. If a description is too ambiguous, has conflicting specs, or refers to a product outside the supplier's stock or production range, the engine marks it clearly and explains why. No silent failures, no invented codes, no wrong prices going out to buyers.

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

Sizes are resolved using dimensional tables from ASME, EN, and ISO standards. 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 standards, not from string patterns. Suppliers can keep their catalog in their preferred unit system.

Core Technology

The Normalization Engine

Q: Why not use AI or machine learning to read RFQs?

Piping quotes require 100% accuracy: a wrong match becomes a wrong price sent to the buyer. AI/LLM models are probabilistic and can hallucinate specs that do not exist. Our rule-based engine is deterministic: same input always produces the same output, every match is traceable, and results are audit-ready. For a supplier preparing commercial offers, 95% correct is not acceptable.

Q: What is the unique product code?

A deterministic hash (SHA-256) generated from the normalized technical attributes of a product: type, material, dimensions, end finish, schedule, rating. Two descriptions that look completely different but describe the same pipe, fitting, or valve always produce the same code. When the code on a buyer RFQ line matches a code in the supplier catalog, the products match. 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

How the engine reads buyer RFQs and turns them into quotes from your catalog.

What does the engine do for a stockist or mill?

An RFQ from a buyer arrives in any format: different languages, abbreviations, column layouts, units. The engine parses each line, identifies the product, detects errors (wrong schedules, impossible sizes, incompatible ratings), and matches it against your catalog. It does not just read text. It understands piping: it knows that SCH 30 does not exist in B36.10, that a Class 150 flange will not bolt to a PN 40 valve, and that "A106 Gr.B" and "P235GH" are not interchangeable. Both the incoming RFQ and your inventory are normalized the same way, so matching is automatic. For stockists, the engine finds what you have in stock. For mills, it checks your production range. Then it applies your pricing rules and returns a ready-to-send quote, with anything unmatched flagged for your team.

Why not use AI or machine learning to read RFQs?

Try it: upload a real buyer RFQ and your inventory list to ChatGPT and ask it to generate a quote. The output looks plausible but is full of wrong matches, invented specs, and missed items. Run the same request twice and you get two different answers. Your sales team would still have to verify every line, which kills the time savings. Our engine is rule-based and deterministic: same input, same output, every time. Each match is traceable, each error is flagged, and the quote is produced without anyone having to second-guess it.

How does it handle the messy way buyers write descriptions?

Real RFQs from EPCs and traders are full of abbreviations (SMLS, BW, RF, SW), typos, OCR artifacts, truncated lines, and inconsistent formatting. "A106 GR.B", "A106-B", "A106 Grade B", "ASTM A 106 GRB" all describe the same material. The engine does not do simple string matching. It parses each line semantically, recognizes piping abbreviation patterns, tolerates common misspellings, and resolves ambiguities using industry rules. If a line is genuinely unreadable, it gets flagged instead of guessed, so your sales team never sends out a wrong price.

What happens when an item is not in my catalog or production range?

The engine flags it for manual review and tells you exactly why: item not in your stock, ambiguous description, conflicting specs, or product outside your production range. Matched and unmatched items appear side by side in the quote, so your team only spends time on the unmatched ones. Nothing is silently misclassified, no codes are invented, no buyer gets a wrong price by accident.

How does it handle sizes in metric vs. imperial?

Buyers describe products in whatever convention they are used to. A pipe written as "168.3mm OD x 7.11mm WT" and one written as "6 inch SCH40" are the same item. The engine maps both to the same product code using dimensional tables from ASME, EN, and ISO standards, not pattern matching. Your catalog can stay in your preferred unit system, and the engine converts on the fly when matching incoming RFQs.

What is the unique product code?

A deterministic hash (SHA-256) generated from the normalized technical attributes of a product: type, material, dimensions, end finish, schedule, rating. Two descriptions that look completely different but describe the same pipe, fitting, or valve always produce the same code. When the code on a buyer RFQ line matches a code in your catalog, the products match, and the line is priced automatically. Over 3 million unique codes are currently mapped.