Help Topic: Concrete Category (Specific Category Node)

A Concrete Category is a specific, meaningful product-type category inside the taxonomy that represents a coherent class of things (for example: Pipe, Valve, Bearing, Tomograph, Centrifugal Pump).

A concrete category is “concrete” because it describes a real, recognizable product type (a technical class), not just a broad industry domain.
However, a concrete category can be either:

• Abstract (structural) — used for grouping and inheritance (no product creation), or
• Product-level — used to create canonical products (product creation is enabled).

In other words:

• “Concrete” describes specificity and meaning.
• “Product-level” describes whether products can be created here.

Concrete Category vs Universal Category

Universal categories are the highest-level, domain grouping blocks (for example: Medical Equipment, Electrical Equipment).
They are always abstract and are used for broad organization and reusable attribute blocks.

Concrete categories are lower in the tree and represent a specific product type, such as Pipe or Tomograph.
They are the “real product class” structure that users expect to browse and search through.

Concrete Category vs Abstract Category

An Abstract Category is any category where products are not created directly (structural only).
All Universal Categories are abstract, but not all abstract categories are universal.

A Concrete Abstract Category is a very common pattern:

• it is specific (e.g., Pipe) but still structural,
• it exists to organize and share rules across multiple product-level children.

Example:

• Abstract (concrete): Pipe
  • Product-level (concrete): Seamless Stainless Pipe
  • Product-level (concrete): Welded Stainless Pipe
  • Product-level (concrete): Copper Pipe

Concrete Category vs Product-Level Category (the key distinction)

A Product-Level Category is a concrete category where Actualog allows you to create canonical products because:

• the attribute template is stable and repeatable,
• mandatory fields are realistic,
• identity rules can be defined deterministically,
• variants (if any) can be defined via variant axes.

A Concrete Category may be product-level, but it may also be abstract. The reliable rule is:

• If products are created here → it is product-level.
• If products are not created here → it is abstract (even if it’s concrete and specific).

What Concrete Categories are used for

Concrete categories are used to:

• provide a clear, technical browsing structure (“Pipe → Seamless Stainless Pipe”),
• support AI-assisted classification by narrowing the search space step-by-step,
• share reusable attribute groups and rules down the subtree,
• define where product-level templates should exist (leaf nodes where the template is stable),
• give experts a place to maintain a coherent “product type vocabulary” that scales.

How to decide where “Pipe” ends and “Seamless Stainless Pipe” begins

Keep a category abstract (structural) if it is still too broad to have one stable template. Make it product-level when:

• you can define a single, stable set of attributes that fits most products in the category,
• identity rules can be defined without ambiguity,
• you can explain clearly what belongs here vs what belongs to sibling categories.

Best practices

• Use singular names (e.g., “Pipe”, not “Pipes”).
• Ensure each abstract concrete category has meaningful children (it should not be a dead-end).
• Do not create products in abstract categories.
• Put identity rules and variant axes on product-level categories (leaf categories).
• Avoid “pseudo-duplicates” in taxonomy: use synonyms and clear descriptions instead of multiple near-identical categories.

Typical examples

• Universal (abstract): Medical Equipment

  • Concrete abstract: Imaging Equipment
    • Concrete product-level: MRI Tomograph
    • Concrete product-level: CT Scanner

• Concrete abstract: Pipe

  • Concrete product-level: Seamless Stainless Pipe
  • Concrete product-level: Welded Stainless Pipe
  • Concrete product-level: Copper Pipe