Every OpenBOM implementation eventually arrives at the same question:
“What Part Number schema should we use?”
And every time, the discussion becomes surprisingly emotional.
Part Numbers are not just numbers. For many engineers and manufacturing companies, they represent order, discipline, accumulated experience, and sometimes company identity. Some organizations have run the same numbering system for decades. Some engineers can read a part family, a supplier, a material, or a manufacturing process straight off the number. This is why Part Numbering arguments feel almost religious. The topic sits at the intersection of engineering, manufacturing, purchasing, and ERP, and everyone in that intersection has been burned by a bad scheme at least once.
I really enjoyed a recent LinkedIn discussion started by Mohammad Safarabadi about Part Numbers. It reminded me how alive this debate still is. He laid out a hierarchical numbering system where the Part Number mirrors the assembly structure: a project gets a number, the first subassembly extends it, the parts inside continue the hierarchy. By looking at the number, an assembler can see where a part belongs in the machine without leaning on the BOM. For freelance work and small custom machines, he argued, this is fast and practical, and it spares him from adapting to a different company standard on every project.
It is an honest, bounded position, and he defended it well. He never renumbers standard or purchased parts. He treats the assembly Part List as the real source of truth. He keeps the method inside the scope where it works. That scope is the whole point, because the comments quickly showed where the edges are.
Smart Numbers Become Dumb
The most upvoted reply in the thread put it in five words: smart numbers soon become dumb. The reasoning was concrete. People order or group parts based on what they have today. A year later a new part needs to sit at a specific point in the series, there is no space for it, and the scheme breaks the moment it meets reality. Another commenter offered the more general version: every numbering system works until it doesn’t.
The failure mode is almost always reuse. A hierarchical number looks clean when the product structure is stable, but product structures are rarely stable. Assemblies change. Subassemblies get reused. A component designed for one machine turns out to be useful in another. A purchased part gets a second approved supplier. The instant the same part lives in two assemblies, a number that announces it belongs to Assembly A is lying about Assembly B. A number carrying a project code misleads the moment the part is reused in the next project.
The more meaning you compress into the number, the faster it goes wrong. That is the paradox of significant numbering: the smarter the number tries to be, the sooner it becomes false.
Several engineers in the thread named the deeper problem precisely. One noted that the moment you need a decoder to understand a number, you have built a failure point for confusion, even when the scheme is simple. Another drew the line that matters most: this kind of numbering is fine for projects, but a no-go for products. Engineering-to-order can live with project-based numbers. The moment a company moves toward reuse, variants, and configuration, the same scheme starts working against it.
There is also a quieter cost that most Part Number debates miss. A significant number leaks information. If your scheme encodes assembly structure, supplier, or process, then anyone holding a drawing can read your product architecture straight off the identifier. Significant numbering does not just become fragile over time. It can also hand a competitor a map.
Identity Is Not Structure
The vocabulary for this has existed for years. Engineers call the two approaches significant and non-significant numbering. Significant numbers try to describe the thing. Non-significant numbers, typically generated by a PDM or PLM system, just identify it, and let the specifications live in metadata.
Underneath that distinction is a principle worth stating plainly. The biggest mistake in most Part Numbering systems is mixing identity and relationships.
A Part Number should identify the item. A BOM should define where the item is used. Metadata should describe what the item is. Supplier records should define how and where it is bought. Revisions should define how it changes over time. These are related, but they are not the same, and the Part Number is the wrong place to store any of them except identity. When you encode structure into the number, you are forcing one field to carry a job that belongs to the relationships around it. It holds up for a single top-down project and falls apart the moment the item participates in more than one relationship at once.
This is why mature PDM, PLM, ERP, and BOM systems lean toward automatically generated, non-significant numbers. The number becomes a stable anchor. The meaning lives in connected data. None of this is new. It was true long before anyone connected an AI model to a product record. Which raises the obvious question about what, if anything, AI actually changes here.
AI Removes the Last Excuse for Smart Numbers
For decades, significant numbering survived one honest objection from its defenders: humans need to read something off the number, because the systems around them were bad at answering questions. If search was weak, if drawings lived in folders, and if ERP data was hard to reach, then a number that told you machined part, project four, sheet metal was doing real work. The Part Number had quietly become a human search interface.
That was always the strongest argument for smart numbers. It was never that the architecture was right. It was that the alternative, asking the system, did not work well enough to trust.
AI removes that argument. When a system connected to BOMs, CAD files, suppliers, revisions, and change history can tell you where a part is used, which assemblies share it, what changed between two revisions, and whether a similar part already exists before you create a duplicate, the number no longer has to carry that meaning. You stop reading identity and start asking questions, in plain language, against the actual product data. The last reason to encode structure into identity disappears. What remains is what the number should have been all along: a stable, non-significant ID, with meaning living in the connected data around it.
This is the real shift, and it is narrower and sharper than “AI changes everything.” The data architecture principle is old. What AI changes is the economics of following it. Significant numbering was a workaround for systems that could not answer smart questions. Once the system can answer them, the workaround is just debt.
It is worth being fair to the thoughtful middle ground here, because the thread had one. Some engineers use process-based prefixes, a letter for machined, sheet metal, weldment, bought-in, and then sequential numbers after that. Others argued for semi-smart numbers that carry only a broad category and push everything else into metadata. These are genuinely better than full hierarchical encoding, and the people using them know exactly why. But even a broad category erodes. Parts get reclassified. Processes change. A part moves from machined to cast. And once the system can simply tell you the category on request, the honest question is whether any embedded meaning still earns the brittleness it introduces. The bar for keeping intelligence in the number keeps rising, and AI raises it again.
AI Will Not Kill the Part Number
So, will AI kill the Part Number?
No. Manufacturing needs a stable identity. ERP needs item numbers. Purchasing needs traceability. Quality needs control. Service organizations need spare parts. Suppliers, drawings, orders, invoices, and change processes all need a stable anchor that does not move. The Part Number is not going anywhere.
What AI kills is the smart Part Number. It removes the need for humans to design complex, meaningful, fragile schemes whose only real justification was that the surrounding systems could not answer questions on their own. The future is not “no Part Numbers.” It is simpler, automatically generated Part Numbers attached to rich, connected product data: BOM relationships, CAD models, supplier records, revisions, and change history.
This is exactly the shift we see at the start of most OpenBOM implementations. Companies open with the Part Number debate because the number is visible and everyone has an opinion. But the more useful question is not what intelligence to pack into the identifier. It is how to build connected product data clean enough that the identifier never needs to carry intelligence at all. OpenBOM generates Part Numbers automatically, keeps identity stable, manages relationships in the BOM, links supplier and purchasing data, and connects engineering to manufacturing, so that searching, filtering, and understanding the product never depends on decoding a string. Increasingly, AI sits on top of that data and answers the questions people used to answer by reading the number.
The Part Number becomes less visible. The product data becomes more intelligent. Engineers stop caring what the number means and start caring what the system knows.
There is a deeper version of this idea worth flagging for a future article. A smart Part Number is really an engineer stuffing knowledge into an identifier because there was nowhere better to put it. The instinct is right; the storage location is wrong. Giving that knowledge a proper home, as durable product context rather than a clever string, is a larger topic, and the subject of where this series is heading.
For now, the practical conclusion is enough. Part Numbers have always mattered because they were one of the few stable anchors in a messy process. They will keep that job. What they will lose is the burden of meaning. And maybe, finally, that will end one of the most religious debates in engineering data management, not by declaring a winner, but by making the argument unnecessary.
Want to experiment with Part Numbers in OpenBOM?
REGISTER FOR FREE and check how OpenBOM keep both worlds together – smart part numbers you still want to keep and automatically generated part numbers.
Best, Oleg
Join our newsletter to receive a weekly portion of news, articles, and tips about OpenBOM and our community.