Product Codes We Normalize

Yes. The table above shows macro-level ASTM/EN specifications, but the engine normalizes down to individual grades, classes, schedules, ratings, and sizes. For example, ASTM A182 covers dozens of grades (F304, F316, F321, F11, F22, F91 and more), each with multiple size and class combinations. All of these are handled as distinct normalized product codes.

The table shows the product families currently covered by the normalization engine. We are actively expanding coverage to structural steel, joints, and pipe supports. If you need a category not listed here, get in touch and we will evaluate adding it to the roadmap.

Yes. When engineering uploads MTO descriptions that are inaccurate, reference non-existent products, or have incomplete specifications, the engine flags them automatically. Instead of silently passing bad data downstream, it proposes a default value for review so the procurement team can correct it before issuing the RFQ. This way, MTOs always leave complete and consistent, reducing clarification rounds with suppliers and avoiding costly ordering mistakes.

That's the core of what the engine does. A supplier might write "6in WN RF flge A105", another "FLANGE WN 150# 6" RAISED FACE SA-105". Both map to the same normalized code. The engine parses free-text descriptions against a rules database covering all standard abbreviations, formats, and conventions used across piping procurement. No AI guessing, just deterministic rule-based parsing.

A fully normalized product description can be very long, too long for ERP material code fields. SAP's Material Master (MM), for example, allows a maximum of 18 characters for material numbers in classic configurations. We need a way to compress a full description into a short, fixed-length code while guaranteeing that every unique product gets its own unique code. That's where SHA-256 comes in. It's a cryptographic hash function, the same algorithm used in digital signatures, blockchain, and certificate verification. It takes any input and produces a fixed-length fingerprint that is deterministic: the same product always generates the same code, every time, on any machine. We use a 3-letter product prefix (e.g. PIP, FLG, VLV) followed by 15 hex characters from the hash. Those 15 digits alone give 16¹⁵ = 1.15 quintillion possible combinations, more than enough to cover every product variant in the global piping industry with a unique code. As for collisions (two different products generating the same code): with the birthday problem formula, at 3 million product codes the probability is roughly 1 in 256,000. At 10 million codes, about 1 in 23,000. In practice, it is virtually impossible for two different products to end up with the same code.

MESC (Material Equipment Standards and Code), developed by Shell, covers only a fraction of the product variants we handle. MESC is also a closed, proprietary system with limited access and licensing restrictions. Our goal is different: we want to offer the industry an open codification standard that any EPC, supplier, or software vendor can adopt freely. Piping procurement today is a tower of Babel where every company uses its own codes, abbreviations, and formats. Instead of relying on MESC Shell's restricted catalog, we built an open, deterministic system that covers all piping product families and that everyone in the industry can speak.