Devices
Product objects best understood as self-contained operational units that perform a recognizable role without necessarily centering on reading or highly specialized technical handling.
Catalog branch
Types as a direct product-identity path
Types are one of the clearest and most practical classification paths in this catalog because they answer a very basic but important question: what kind of thing is this product, structurally and conceptually, before broader context or narrower details complicate the picture? The type lens is not mainly about who uses the product, where it is used, or what market it belongs to. It is about the product’s direct object identity. That makes the Types branch especially useful when a visitor already has a rough understanding of the concept but needs a stronger way to describe the product itself before moving further into categories, families, form factors, applications, environments, or features.
This matters because product discussions often become vague very quickly when a team keeps talking about what a product does without agreeing on what sort of object it actually is. Some concepts are best understood as devices because they are coherent product units built around controlled operation. Others fit better as instruments because they are strongly tied to reading, measurement, inspection, or more focused technical use. Some concepts are better understood as containers because their primary identity comes from holding, protecting, staging, or organizing other things. Others belong under accessories because they add support, extension, mounting, handling, attachment, or product-adjacent utility without becoming the main primary object themselves.
That is why the Types branch works so well inside the broader catalog. It gives visitors a direct object-level lens that complements the other branches. A product can be a medical product, part of a portable family, handheld in form factor, designed for field use, and still most honestly be called an instrument. Another concept can belong to the same broad category yet be better understood as an accessory or container. The type lens helps visitors resolve that question cleanly. The current type paths are: Devices, Instruments, Containers, and Accessories.
Role Object identity Types answer what kind of product-object the concept most honestly is
Current hubs 4 The first four type routes create a practical object-level browse layer
Best use Clarification Visitors use Types when broad category language is true but still not specific enough
Current type routes in this branch
These pages represent the first object-level type routes in the catalog. Each one helps visitors describe the product more precisely before they continue into narrower or adjacent branches.
Instruments
Products whose identity is more closely tied to measurement, inspection, monitoring, reading, controlled task execution, or other precise technical-use logic.
Containers
Product objects whose primary identity comes from holding, protecting, organizing, separating, staging, or transporting other items or contents.
Accessories
Product objects that extend, support, attach to, complement, or make another product more usable without becoming the main system by themselves.
How visitors should use the Types branch
Types are most useful when the concept already feels real enough to describe as an object, but the visitor still needs a cleaner noun before going deeper into the rest of the taxonomy.
Use types when object identity matters most
If the strongest open question is whether the concept is best described as a device, an instrument, a container, or an accessory, the Types branch is usually the best next move.
Use types to resolve vague product language
Many concepts are described too loosely at first. Type routes help visitors move beyond generic language and decide which product noun most honestly fits the object they are classifying.
Continue into narrower lenses afterward
Once the product type is clearer, the next step is often into Form Factors, Applications, Environments, or Features depending on what matters next.
Common starting questions and the best type-level path
Visitors often know something important about the product-object itself before they know the exact broader or narrower path that should follow. This table gives them a cleaner first step.
What the visitor knows
Why that matters
Best first page
The product feels like a self-contained working unit
Some concepts are easiest to place first as complete operating objects before any narrower technical distinction is made
The product is closely tied to reading, measuring, or controlled technical use
A more specific type label helps when exactness, inspection, or focused technical action is central to the product identity
The product mainly holds, protects, or organizes other things
Some concepts become clearer as containment objects before category, feature, or environment questions take over
The product mainly extends or supports another product
Support objects often need a separate type path so they are not misclassified as full primary systems
Why types matter in a product taxonomy
Types matter because product discussions become unhelpfully loose when teams avoid naming what the product-object actually is. Broad category language can still be true, but it often leaves too much ambiguity. A product can be medical, industrial, or consumer and still be more honestly described as a container, a device, or an accessory. A family page can explain recurring structure, but it still may not answer the direct object-identity question. Type routes help fill that gap. They give visitors a sharper noun before the rest of the classification work continues.
That makes the Types branch especially practical for real-world product work. Engineers, founders, buyers, and researchers often need a clearer product noun before they can compare concepts, write briefs, or decide which deeper path matters next. This branch gives them that object-level clarity without pretending it is the only truth the taxonomy needs.
How Types connects to the rest of the structure
Types sits in a useful position between the broad logic of Categories and Families and the narrower refinements that often follow through Form Factors, Applications, Environments, and Features. A visitor may come from a broad category page, use Types to clarify what the object really is, and then continue into those narrower routes with less confusion.
From there, they can still move outward into Products for canonical product pages, Collections for curated groupings, Library for deeper explanation, or Updates when there is something new worth tracking in that area of the product landscape. That relationship keeps the Types branch practical, specific, and scalable.