Classification, and what it is actually for

What it is, and what it is not

A hierarchy of classes where each level contributes attribute definitions, and a part sitting at a leaf carries the union of everything above it. A captive screw has a part number and mass because it is a part, a manufacturer and MPN because it is hardware, a thread and drive because it is a fastener, and a retention type because it is captive.

It is not a folder structure. A part belongs to one class, but the class is a statement about what the part *is* rather than about where it is filed — and the attributes that follow are the point, not the browsing.

It is also not a substitute for search. People find parts by searching; classification is what makes the search results comparable, because two parts in the same class have the same attributes to compare on.

The mechanism: inheritance and class-specific attributes

Each class defines attributes that everything beneath it inherits. That gives one place to add a field that should exist on every purchased part, rather than forty places to add it and thirty-eight to get right.

Class-specific attributes are the more interesting half. Retention type is meaningful on a captive screw and meaningless one level up. Putting it on Fastener would give every bolt in the tenant a permanently empty field, and a schema full of empty fields is how people learn to ignore fields.

Required attributes are enforced at the class, which is what makes them meaningful. A part cannot be released without the attributes its class declares mandatory — so the completeness rule lives with the definition of what the thing is, rather than in somebody's checklist.

Reclassification is a preflighted operation, not a dropdown. Moving a part to a different class changes which attributes apply, which values become orphaned, and which required fields are suddenly empty. Preflight reports that against real data before anything moves, and bulk reclassification is a change like any other.

The failure it prevents

An engineer needs an M3 captive screw. Search returns nothing useful, because the existing part is described as HW-0451 · M3 x 8 captive screw, SS and they searched for screw M3 8 stainless.

So they create a new part, add a supplier, raise a qualification, and move on. Twenty minutes, and it felt like the right thing to do — the search genuinely did fail them.

With classification, the same search is a class filter with attribute comparison: fasteners, thread M3, length 8, stainless. The three near-identical parts appear side by side with their differences visible, and the engineer chooses instead of creating. The duplicate problem is not solved by telling people to search harder; it is solved by making the search answer comparable.

How it meets the rest of the product

The Parts Agent's strongest reuse signal is classification plus attribute equality — same class path, same values on the attributes that define the class. It is exact, cheap and finds the easy cases, which are far more common than anyone expects. Semantic similarity and shared AML entries are the other two signals.

Compliance rollups depend on classes reaching materials, because substance data attaches to material rather than to a part number. A taxonomy that stops before it reaches material composition cannot roll anything up.

Search facets come from class attributes, so the filters offered on a result set are the ones that actually distinguish those parts rather than a fixed list. Saved views built on class filters stay correct as parts are added.

Classes are tenant configuration alongside object types and lifecycles — versioned, diffable, promoted from a sandbox with rollback. A taxonomy is never right the first time, and the cost of changing it is what determines whether it gets maintained.

How it meets your ERP

Classification is engineering's and stays here. ERP item categories exist for a different purpose — planning, costing, tax treatment, reporting — and mapping one onto the other produces a taxonomy that serves neither well.

Where a connector exposes a category field, Manufacturing PLM can publish a mapped value from the class path, so the ERP gets the grouping it needs without engineering's taxonomy being flattened to fit it. The mapping is per connector and stated in the field map.

The genuinely useful crossing is the other way: class-specific attributes are what make MPN matching work. A part whose class declares manufacturer and MPN carries the identifiers your ERP and the component feeds both match on, which is why classification quietly underpins the whole supply-risk story.

Where the boundary is

Manufacturing PLM does not ship a standard taxonomy, and does not intend to. Published classification standards exist and are excellent for the industries that wrote them; imposing one on an electro-mechanical manufacturer who does not use it produces a hierarchy nobody recognises and everybody works around.

It also will not classify parts for you automatically at import. The Parts Agent proposes a class with its reasoning cited, and a person accepts it. Bulk auto-classification produces a taxonomy that looks populated and is wrong in ways nobody discovers until a compliance rollup depends on it.