How to Design Part Numbering for the AI Era

Part 4 of the Part Numbers and AI series. The practical one.

Part numbering for the AI era comes down to one move: use automatic, non significant part numbers in item catalogs, and let connected data carry classification, suppliers, revisions, and CAD links. The principle in a line: do not design a smarter number, design a smarter system around a simple number.

This is the fourth and final article in my series on part numbers and AI, and it is the one I have been waiting to write, because it is the one that has to survive contact with Monday morning. The first three articles cleared the ground. This one has to tell you what to actually build on it.

A quick recap, because the progression matters. In the first article, Will AI Kill the Part Number?, I argued that AI will not kill the part number, because manufacturing still needs a stable identity. ERP needs item numbers, purchasing needs traceability, quality needs control, and suppliers, drawings, and orders all need an anchor that does not move. What AI kills is the smart part number, the overloaded string whose only real justification was that the systems around it could not answer questions on their own.

In the second article, Where Should the Part Number Live?, I followed the obvious next question. If the meaning does not live in the number, where does it go? The answer came straight out of onboarding sessions: into catalogs, item properties, BOM relationships, CAD links, supplier records, and revision history. The meaning never disappeared. It only changed address.

In the third article, Why Part Numbers Became Smart, I tried to be fair to the other side. Engineers did not encode meaning into numbers because they lacked discipline. They did it because systems were disconnected, expensive, and weak at search, so the part number quietly became a poor man’s hyperlink. It carried clues because the real data was rarely one click away.

Three articles of saying stop putting meaning in the number. Fair enough. But in every onboarding meeting, the moment the principle lands, someone asks the only question that actually matters. Fine. If not the number, then what do we set up?

Here is the whole answer in one line, and the rest of this article is just the long version of it.

Do not design a smarter number. Design a smarter system around a simple number.

How should companies design part numbering for the AI era? Use stable, automatically generated, non significant part numbers managed in item catalogs, and move every other kind of meaning into connected data. Concretely: let the system generate the number instead of engineers inventing it; make the item catalog the identity layer rather than the BOM, CAD file name, or a spreadsheet; store classification, material, process, and lifecycle state as metadata; keep your company part number separate from manufacturer and supplier part numbers; treat revision as a state rather than a new identity; connect CAD files and BOMs to item records instead of crowning the file name; preserve legacy numbers and apply cleaner rules only to new items; and expose meaning through search, links, and AI rather than encoding it in the digits. The principle in one line: do not design a smarter number, design a smarter system around a simple number.

Start With One Rule: Identity Is Not Meaning

The biggest mistake in part numbering is asking one field to do every job at once. A part number should answer exactly one question. Which item is this? It should not also be expected to tell you what type of part it is, where it is used, who supplies it, what it is made from, which revision is current, which CAD file defines it, which BOM contains it, or which ERP item it maps to. Those questions are all important. None of them belong inside the identifier.

This is the rule that makes the next nine decisions easy, so it is worth stating cleanly. The part number is identity. The metadata, the relationships, the files, the revisions, and the supplier records are meaning. Once you accept that identity and meaning are different things that belong in different places, the part numbering debate stops being a debate. You stop trying to design a clever code, and you start designing a clean information model, which was the real work all along.

Engineers already have a vocabulary for this, even if the part number debate rarely uses it cleanly. An intelligent, or significant, part number tries to describe the thing. A non significant part number, the kind a PDM or PLM system generates, simply identifies it and lets the specifications live in metadata. The entire series has been one long argument for the second approach, and what follows is how you actually build it.

I want to be honest about something here. The AI era does not relax this discipline. It raises the bar on it. A model can only help you if the data underneath it is structured, connected, and trusted. A clever number has never been a substitute for clean item data, and in front of an AI agent the difference becomes obvious immediately. So everything below is less about numbering and more about giving each kind of meaning a proper home.

Let the System Generate the Number: The Case for Automatic, Non Significant Part Numbers

The first practical move is the simplest. Stop asking engineers to invent part numbers by hand.

Manual numbering looks harmless and quietly taxes everything. Every new item starts with a small negotiation about what the number should mean, whether a range still has room, and which half-remembered rule applies. Multiply that by a few thousand parts and you have built a tax on item creation that pays for nothing. Worse, you have made the identifier depend on tribal memory, which leaves the company the day a key engineer does.

In OpenBOM, the pattern that holds up is to use item catalogs with automatic part number generation. You define a catalog, or a few of them, and the system assigns the next number when an item is created from CAD, from an import, or by hand. Automatic part numbering does three useful things at once. It makes item creation fast, because engineers design products instead of naming them. It reduces duplicates, because creation runs through a controlled catalog that can check whether something already exists. And it produces consistency, because the number is governed by the system rather than by whoever happened to create the part that afternoon.

A prefix or a range is fine if it helps you route and recognize items, mechanical in one catalog, electronics in another, purchased parts in a third. The line to hold is that the prefix routes, it does not narrate. The moment the prefix becomes a language people decode by eye, you have rebuilt the smart number under a new name.

Make the Item Catalog the Identity Layer

This is the decision most companies get wrong, and it is the one that quietly determines whether reuse will ever work.

The question underneath part numbering is where items actually live. In many companies, identity gets created wherever it is convenient. In a spreadsheet, which then becomes an uncontrolled identity system. In a CAD file name, which makes the file the master even though files and items are not one to one. Inside a single BOM, which ties identity to one assembly and makes the same part painful to reuse anywhere else. Each of these works for a while, and each of them breaks in the same place, which is reuse.

A BOM describes how items are used together. A CAD file describes geometry and design intent. A supplier record describes how an item is bought. A revision describes the state of an item at a point in time. All of those are relationships and attributes. None of them is the item. The item needs a home that exists independently of any single BOM, file, project, or supplier, and that home is the catalog.

This matters more in the AI era, not less. AI needs stable objects to reason about. It has to know that the same bracket is the same bracket across five assemblies, that the same purchased component has three approved sources, and that one item moved through revisions A, B, and C without becoming three different things. Without a catalog as the identity layer, AI sees a pile of fragments. With one, it can connect them. A simple part number sitting on a well-formed catalog item is worth far more to an AI agent than a clever string sitting on a loose file.

Put Classification in Metadata, Not in Digits

Classification is genuinely valuable, and nothing here argues against it. Companies need to classify by type, function, material, process, sourcing strategy, product family, lifecycle state, and compliance category, because classification drives reuse, reporting, cost analysis, and procurement. The argument is only about where classification lives.

The reason it cannot live in the number is that classification changes and the identifier must not. A part that started as machined gets cast. A supplier part gets brought in house. A component built for one product line gets reused in another. A company reorganizes its families, or a new compliance rule introduces a category nobody imagined when the number was minted. If that classification is welded into the part number, every change leaves you with two bad options. Keep the number and accept that it now lies, or rename the part and break its history. Neither is acceptable, and you should never have to choose between them.

Store classification as properties, item types, catalog membership, tags, and lifecycle states instead, and the problem dissolves. The number stays put while the classification evolves around it. This is also the form AI works with best. A model does not want to reverse engineer your numbering folklore. It wants explicit fields it can read, filter, compare, and reason over. Give it part type, material, process, lifecycle state, and preferred source as data, and it can find similar parts, flag duplicates, and answer questions. Bury those in the digits and you have hidden the very information you want the system to use.

Your Part Number Is Not Your Supplier’s Part Number: Internal vs Manufacturer Part Numbers

One of the most common and most expensive mistakes is collapsing internal identity and external identity into a single field.

Three different things tend to get confused here, and the difference between a manufacturer part number and an internal part number is the one that costs the most when it gets lost. Your company part number is your internal identity for the item. A manufacturer part number is the number assigned by whoever makes the component. A supplier part number is how a distributor references and sells it. For standard and purchased parts, one internal item routinely carries several approved manufacturers and several supplier sources at once. A single connector might have your internal number, a manufacturer part number from the original maker, and distributor numbers from DigiKey, Mouser, Newark, or Arrow.

The trouble starts the instant you let any of that external identity become your internal identity. Put the supplier number in your part number and you lose control the day you change suppliers. Put the manufacturer number in it and you have a problem the moment you approve a second source. Use the distributor’s catalog number as your own and you have handed your identity model to someone whose catalog you do not control.

The clean pattern is to keep your company part number stable and connect everything commercial to it as related data, managing manufacturers, approved vendors, prices, and lead times through product sourcing rather than through the identifier. Purchasing then evolves without forcing engineering to rename anything. And the payoff in front of AI is direct. A model can compare sources, flag single source risk, and surface missing supplier data, but only when supplier data is modeled as supplier data instead of hidden inside a string.

Connect CAD and Revisions, Do Not Encode Them

I covered both of these in the onboarding article, so I will keep it short and only sharpen the point, because they are two versions of the same instinct done wrong.

A revision is a state, not a new identity. The question I hear most in onboarding is whether the revision should be part of the part number, and the answer is no. A part number identifies the item, a revision identifies the state of that item over time, and the two travel together without being the same field. The moment you mint 12345-A, 12345-B, and 12345-C as separate identities, the identifier starts moving every time the design changes, and an identifier that moves is no longer doing its one job. Keep the number stable and let the revision move from A to B to C. The harder call, whether a change earns a new revision or a new number, is a configuration management question answered by interchangeability, not a numbering rule. If the new version can replace the old one without anyone downstream needing to know, it is a revision. If it cannot, it may need a new part number.

The CAD file follows the same logic. Many teams start by assuming the file name should be the part number, because a file has a name and a part has a number, so why keep two things. It works until it does not. One file can hold many configurations, some of which are real variants and some of which are only design states. Some files are assemblies, some are parts, and one item can own several drawings, a STEP file, and a PDF. File names answer to the CAD system and its references. Part numbers answer to BOMs, catalogs, purchasing, and ERP. The right move is to connect CAD to managed item records and BOMs, let CAD properties carry the part number, description, and revision, and let the catalog and structure hold the broader context. That connected graph, where AI can walk from a file to an item to a BOM to a supplier to a change, is far more powerful than any naming convention.

Do Not Renumber the Past, and Let People Keep Their Labels

A practical article has to deal with reality, and reality has two parts here.

The first is legacy. Almost no company starts from a blank page. Most carry thousands or hundreds of thousands of part numbers, smart and semi-smart and random, pulled from ERP, drawings, CAD, suppliers, acquisitions, and a spreadsheet built a decade ago by someone who has since left. The worst advice you can give these companies is to renumber everything. Mass renumbering breaks references across ERP, purchasing, drawings, quality records, and service history, and it consumes enormous energy to produce risk. The better path is evolutionary. Keep the existing numbers, import them, respect them as historical identity, and define a cleaner rule for new items going forward. Legacy numbers are part of the company’s memory. You do not erase memory. You connect it. The goal is not to fix the past. It is to stop making it worse.

The second reality is gentler. Some people will still want readable numbers, and they are not wrong to. Humans talk. They need shortcuts in meetings, on the shop floor, and on supplier calls, and a readable reference is easier to say and remember than a random ID. The mistake is not allowing readable references. It is making the readable reference the permanent identity. If your team wants project codes, drawing numbers, customer item numbers, or familiar nicknames, store them as additional properties, make them searchable, and show them in views and reports. Let people keep the labels they think in. Just do not make every label an identity. That single distinction ends most of the religious arguments without anyone having to lose.

Design for Questions, Not for Decoding

Here is the change that ties the whole series together. In the AI era, the part number is no longer the main interface to product knowledge.

For decades, understanding a part meant decoding its number, or asking the one person who knew the schema, or searching a spreadsheet, or opening a drawing, or pinging purchasing. The number was the interface because nothing better was reachable. That is over. The interface now is a search, a link, and a question. People should be able to ask where a part is used, whether something similar already exists, which supplier provides it, what the latest revision is, which BOMs a change will hit, which items have no approved vendor, and what changed between revision A and revision B, and get an answer from connected data instead of a clue read off a string.

That single shift rewrites the design goal. The goal was never to make the part number smarter. The goal is to make the product data more connected, because a simple number attached to rich, searchable, linked data beats a clever number attached to scattered files every single time. The intelligence does not belong in the identifier. It belongs in the graph around it.

The Practical OpenBOM Pattern

If you want the whole recommendation in one place, here are the part number best practices I give companies during onboarding, in the order they usually unfold. 

1. Create item catalogs for the main classes of items you manage, and let each catalog generate part numbers automatically so identity is fast, stable, and consistent. 
2. Keep those numbers simple, non significant, or only lightly structured with a routing prefix, and push every kind of meaning outward into its proper home. 
3. Classification, type, material, process, and lifecycle state become metadata. 
4. Manufacturer and supplier part numbers become connected sourcing data, kept separate from your internal identity. 
5. Revisions become item states rather than new numbers. CAD files, drawings, and BOMs connect to item records instead of crowning a file name as the master. 
6. Existing part numbers come in as legacy identity and stay untouched, while new items follow the cleaner rule. 
7. And on top of all of it, search, links, views, and AI expose the meaning that used to be trapped in the digits. 
8. The item catalog ends up as the stable identity layer for engineering, manufacturing, procurement, and the business systems downstream. 

None of this is theory. It is what OpenBOM onboarding does, week after week, once the room stops arguing about the schema and starts designing the data model.

Design a Smarter System Around a Simple Number

So here is where the series lands. Part numbers are not going away, and they are not getting less important. They matter precisely because identity matters. What changes is that identity stops pretending to be intelligence.

For decades, companies made part numbers smart because they had nowhere better to put meaning. They compressed category, structure, supplier, revision, and process into a string because the surrounding systems could not carry the context. Connected data, cloud collaboration, search, links, and AI finally remove that excuse. The number gets to become what it should always have been, a stable identifier, while the intelligence moves into the product graph around it, where items know their properties, BOMs know their relationships, files know what they define, suppliers know how parts are bought, and revisions know how items change. That connected graph, the durable home for not just the data but the decisions and the reasoning behind it, is what I have been calling Product Memory, and it is the real destination this whole series has been walking toward.

Stop designing the number. Design the system around it.

Do not design a smarter number. Design a smarter system around a simple number.

Want to put this into practice with your own parts, catalogs, and BOMs? 

REGISTER FOR FREE and see how OpenBOM keeps identity simple and the connected data intelligent.

Best, Oleg

Frequently Asked Questions

How should you design part numbers for the AI era? Use automatically generated, non significant part numbers managed in item catalogs, and keep meaning out of the identifier. Classification, suppliers, revisions, CAD links, and lifecycle state belong in connected metadata and relationships, where AI and search can use them. The number identifies the item. The connected data explains it.

Should part numbers be automatic or manual? Automatic. Manual numbering taxes every new item with a small decision, depends on tribal memory, and invites duplicates. System generated numbers from a catalog are faster, more consistent, and safer, while still allowing a lightweight prefix to route mechanical, electronic, and purchased parts to different catalogs.

Where should classification live if not in the part number? In metadata. Store type, material, process, product family, and lifecycle state as item properties, types, and catalog membership. Classification changes over time, and embedding it in the identifier forces you either to keep a number that has become false or to rename the part and break its history.

Should the company part number include the supplier or manufacturer part number? No. Keep your internal part number stable and connect manufacturer and supplier part numbers as related sourcing data. One internal item often has several approved manufacturers and distributors, and folding any of them into your identity means losing control the moment a source changes.

Do we need to renumber our old parts? No, and you should not. Mass renumbering breaks references across ERP, purchasing, drawings, and service records for little benefit. Keep legacy numbers as historical identity, import them as they are, and apply a cleaner numbering rule to new items going forward.

Further Reading

• Will AI Kill the Part Number? (Part 1)
• Where Should the Part Number Live? Lessons From Real OpenBOM Onboarding Sessions (Part 2)
• Why Part Numbers Became Smart, and Why Search, Sharing, and AI Will Change Their Role (Part 3)
• Why Intelligent Part Numbers Must Die in the Future PLM / ERP Data Management Best Practices (Beyond PLM)
• Interchangeability, Revisions, and New Part Number (Beyond PLM)