Model the Product Domain
Modeling the product domain is the process of defining:
- where a company’s products belong;
- which product categories exist;
- what information must be collected for each category;
- how products are identified and named;
- how product models and variants are organized;
- who may create, review, and publish category models.
A well-designed product domain makes product creation faster and keeps product data consistent across companies, catalogs, imports, languages, and integrations.
The process is:
Link the company to existing categories
→ Link company brands to Brand categories
→ Create a category proposal when a category is missing
→ Design the category and its effective template
→ Review and approve the category
→ Publish the category
→ Create and maintain products
Start with the Company’s Product Scope
Before creating products, a company should identify the categories in which it operates.
An authorized company user opens Company Categories and links the company to relevant concrete categories.
A company may link itself to:
- broad Family-level categories that describe its product domain;
- Product-level categories in which its products will be created;
- multiple related categories across one or more communities.
For example, a gas-sensor manufacturer may link the company to:
Sensor
Gas Sensor
Nondispersive Infrared Gas Sensor
The first two categories may organize the domain and provide inherited rules. The final Product-level category is where actual products are created.
A company-category relationship does not make the company the owner of the category. Categories are shared parts of the Actualog product taxonomy.
Select the Company’s Role in the Category
When linking a company to a category, select the role that describes the company’s relationship with that product domain.
Typical roles include:
- Designs — the company develops or designs products in the category;
- Manufactures — the company manufactures products in the category.
The relationship should describe the company’s real activity, not merely its interest in a category.
Company-category relationships can be added to both Family-level and Product-level concrete categories. However, products are created only in Product-level categories.
Link Brands to Brand Categories
Every Product-level concrete category has an identity mode:
- Brand category;
- Standard category.
Brand categories
Use a Brand category when products are identified by their brand, commercial model, or product series.
Examples include:
Nondispersive Infrared Gas Sensor
Magnetic Resonance Imaging System
Industrial Robot
Electronic Controller
Power Tool
For each Brand category, the company should link the brands for which it has valid Brand Owner authority.
Example:
Company: MIPEX Technology
Category: Nondispersive Infrared Gas Sensor
Brand: MIPEX
The brand relation is then used for:
- product authority;
- product identity;
- generated product names;
- Product Overview access;
- approval and publication rights.
Brand is a relationship, not a normal category attribute.
Do not create attributes such as:
Brand name
Brand owner
Manufacturer
Company
Supplier
Actualog manages these concepts through company, brand, and product relationships.
Standard categories
Use a Standard category when product identity is defined by a specification rather than a brand.
Examples include:
Stainless Seamless Steel Pipe
Standard Bolt
Steel Plate
Chemical Grade
Generic Cable
Pipe Fitting by Standard
A Standard product may be manufactured or supplied by several companies while remaining the same canonical product.
Its identity may depend on:
Standard
Material grade
Diameter
Wall thickness
Nominal size
Pressure class
Purity
Concentration
A company may link itself to a Standard category, but no brand is required to define the canonical product.
Search Before Creating a Category
Actualog uses a shared product taxonomy. Before creating a category, search for an existing category that describes the same product type.
Search by:
- preferred category name;
- synonyms;
- alternative technical terms;
- standards terminology;
- parent and child categories;
- related product examples.
Check whether the required category already exists under another name or in another part of the taxonomy.
Do not create a duplicate merely because:
- another company uses a different term;
- a supplier spreadsheet uses an abbreviated name;
- the category has a different translated label;
- the existing category is not currently linked to the company.
When a suitable category exists, link the company to it instead of creating another category.
When the Required Category Does Not Exist
When no suitable category exists, create a category proposal.
The proposal should describe a real reusable product type, not one company’s private catalog section or one individual product.
Correct category:
Nondispersive Infrared Gas Sensor
Incorrect category:
MIPEX-02-4-I-1.1
The second example is a manufacturer order code for a product or variant, not a category.
A new category proposal should include:
- category name;
- clear definition;
- synonyms and alternative terms;
- examples of products that belong to it;
- proposed concrete parent;
- Family-level or Product-level classification;
- Standard or Brand identity mode;
- suggested Universal categories;
- required and optional attributes;
- proposed attribute groups;
- proposed variant axes;
- proposed name templates.
Who Can Create Categories
Actualog separates category proposals from governance of the shared taxonomy.
| User | Category capability |
|---|---|
| Authorized company user | Proposes a missing category and provides product examples, specifications, and business justification. |
| Category Expert | Creates and edits category drafts within the assigned category scope, reviews proposals, and develops the category template. |
| Application Administrator | Creates and manages categories globally, resolves taxonomy conflicts, and publishes approved category models. |
| Ask Hex AI Assistant | Searches for existing categories, prepares proposals and drafts, recommends attributes and templates, and explains its reasoning. |
A company user does not directly publish a new shared category.
A Category Expert or Application Administrator must review the proposed model before it becomes available for general product creation.
Actualog may require a second qualified reviewer for important or high-impact taxonomy changes.
Ask Hex to Find or Design the Category
Ask Hex can assist at the beginning of the process.
A user can provide:
- a product name;
- a manufacturer catalog;
- a product datasheet;
- a supplier spreadsheet;
- a website;
- several representative product examples;
- a description of the company’s product range.
Hex first searches Actualog for:
- an existing concrete category;
- possible synonyms;
- related parent and child categories;
- existing Universal categories;
- existing library attributes;
- related Standard or Brand category models.
If a suitable category exists, Hex recommends linking the company to it.
If no suitable category exists, Hex prepares a category draft.
Hex should explain:
Why the category is needed
Why an existing category cannot be used
Where the category belongs in the concrete taxonomy
Whether it is Family-level or Product-level
Whether it is Standard or Brand
Which Universal categories should be attached
Which attributes can be reused
Which new attributes are still required
How products should be named
Which attributes should define variants
Hex may create a complete draft, but it does not approve or publish its own proposal. A Category Expert or Application Administrator remains responsible for the final decision.
Design the Category Model
Every concrete category must be designed along several independent axes.
Concrete or Universal
This decision answers:
What role does this category play?
Concrete category
A Concrete category is a node in the main product taxonomy.
Examples:
Sensor
Gas Sensor
Nondispersive Infrared Gas Sensor
Pipe
Seamless Steel Pipe
Magnetic Resonance Imaging System
Concrete categories may have concrete parents and children.
Universal category
A Universal category is a reusable semantic bundle that can be attached to many unrelated concrete categories.
Examples:
Equipment
Electronic Device
Instrument
Medical Equipment
Commercial Model
Standardized Commodity
Metal Stock
Universal categories are flat and independent.
They:
- are not concrete taxonomy parents;
- do not inherit from other Universal categories;
- do not have Universal children;
- are not used directly for product creation;
- provide reusable attributes to concrete categories.
Incorrect:
Nondispersive Infrared Gas Sensor
Parent: Electronic Device
Correct:
Concrete parent: Gas Sensor
Attached Universal categories:
- Electronic Device
- Instrument
- Commercial Model
Family-level or Product-level
This decision answers:
Can actual products be created in this category?
Family-level category
A Family-level category organizes narrower concrete categories and provides shared inherited rules.
Examples:
Sensor
Gas Sensor
Pipe
Tomograph
Products should not normally be created directly in a Family-level category when a more specific subtype is required.
Place attributes on a Family-level category when they are shared by all relevant descendants.
Example:
Gas Sensor:
- Detected gas
- Measurement range
- Response time
Product-level category
A Product-level category is specific enough for actual product records.
Examples:
Nondispersive Infrared Gas Sensor
Stainless Seamless Steel Pipe
Magnetic Resonance Imaging System
Membrane Filter Cartridge
A Product-level category must have a complete effective template and stable product identity rules.
Standard or Brand
This decision answers:
What makes two products the same or different?
Brand category
Choose Brand when two technically similar products from different brands must remain different canonical products.
Typical identity:
Brand
Model
Product series
Configuration
Standard category
Choose Standard when products with the same specification should be the same canonical product regardless of manufacturer or supplier.
Typical identity:
Standard
Grade
Material
Dimensions
Class
Rating
This decision is mandatory for Product-level categories.
Select the Concrete Parent
Every new concrete category should be placed under the most appropriate concrete parent.
The parent provides:
- taxonomy navigation;
- shared definitions;
- inherited attributes;
- inherited rules;
- inherited Universal category attachments.
Example:
Sensor
└── Gas Sensor
└── Nondispersive Infrared Gas Sensor
Use the highest parent that is true for all products in the child category.
Do not use a Universal category as a concrete parent.
Place a shared attribute on the concrete parent when it belongs only to that taxonomy branch.
For example:
Detected gas
belongs on Gas Sensor if it is shared by all gas-sensor technologies.
An attribute such as:
Operating voltage
may belong to the Universal category Electronic Device because it is reused across many unrelated concrete branches.
Attach Universal Categories
A concrete category can use several Universal categories.
Example:
Nondispersive Infrared Gas Sensor
Universal categories:
- Electronic Device
- Instrument
- Commercial Model
Each Universal category should provide a meaningful reusable attribute bundle.
For example:
Electronic Device:
- Operating voltage
- Current consumption
- Power consumption
- Output type
- Communication interface
Instrument:
- Measured parameter
- Measurement technology
- Measurement range
- Accuracy
- Resolution
- Response time
Commercial Model:
- Product series
- Model lifecycle status
- Introduction year
- Warranty
Attach a Universal category at the highest concrete level where it is valid for all relevant descendants.
Do not create Universal categories that are merely:
- one attribute;
- a visual attribute group;
- another name for a concrete parent;
- a company-specific grouping.
Reuse Library Attributes
Actualog maintains a shared library of canonical attributes.
Before creating a new attribute, search the library by:
- name;
- synonyms;
- definition;
- value type;
- measure;
- unit;
- allowed values.
Reuse an existing attribute when it has the same meaning.
For example, do not create separate attributes named:
Operating voltage
Working voltage
Operational voltage
when they describe the same concept.
A library attribute should have:
- a clear canonical name;
- a precise definition;
- value type;
- measure or dimension where applicable;
- default measurement unit;
- allowed values where applicable;
- validation rules;
- multilingual terms and synonyms.
Create a new library attribute only when no semantically equivalent attribute exists.
Hex should search the library automatically and explain why an existing attribute can or cannot be reused.
Decide Where Each Attribute Belongs
Every attribute should be stored at the highest reusable level where its meaning remains correct.
Use this order:
Concrete parent attributes
+
Universal category attributes
+
Direct Product-level category attributes
=
Effective product template
Put the attribute on a concrete parent when:
- it is shared within one concrete taxonomy branch;
- it is not broadly reusable in unrelated product domains.
Put the attribute on a Universal category when:
- it is reused horizontally across different concrete branches;
- it belongs to a stable semantic bundle.
Put the attribute directly on the Product-level category when:
- it is specific to that final product type;
- it is not already inherited;
- it is needed to compare, validate, identify, or name products.
Actualog deduplicates the final template by canonical Attribute ID.
Do not create duplicate direct attributes merely to control their display order.
Organize Attributes into Groups
Attribute groups organize the product form and Product Profile.
They make large technical templates easier to read.
Typical groups include:
Identity and Classification
Product Model
Performance
Measurement
Electrical Characteristics
Mechanical Characteristics
Dimensions and Weight
Materials and Construction
Environmental Conditions
Interfaces and Connectivity
Compliance and Standards
Packaging and Logistics
Attribute groups are presentation structures.
They are not:
- concrete categories;
- Universal categories;
- inheritance rules;
- product identity rules.
Each attribute should appear in the group where users naturally expect to find it.
Avoid creating too many small groups. A group should normally contain several related attributes.
Define Requiredness and Validation
For each attribute, define how Actualog should use it.
Possible rules include:
- required for every product;
- required only under a condition;
- optional;
- single value or multiple values;
- allowed-value list;
- numeric range;
- minimum or maximum value;
- measurement unit;
- searchable or filterable;
- included in comparison;
- included in identity;
- included in a generated name.
Required attributes should represent information genuinely necessary to identify, compare, validate, or publish products.
Do not make an attribute required merely because one supplier happens to provide it.
Configure Variant Axes
Variant axes define how variants differ inside one shared product model or group.
Examples include:
Size
Capacity
Voltage
Power rating
Diameter
Wall thickness
Length
Material grade
Detected gas
Measurement range
Configuration
A variant axis must:
- already exist in the effective category template;
- represent a meaningful purchasable or technical difference;
- help distinguish one variant from another;
- use a structured value type;
- be stable across products in the category.
Prefer one to three clear axes.
Do not use:
- brand;
- manufacturer;
- supplier;
- long descriptions;
- unstructured marketing text
as variant axes.
Brand-category example
Variant group:
MIPEX 02
Possible axes:
- Detected gas
- Measurement range
- Output configuration
Standard-category example
Variant group:
Stainless seamless steel pipe, ASTM A312, grade 316L
Possible axes:
- Outside diameter
- Wall thickness
- Length
Configure Name Templates
Name templates generate consistent product names from structured data.
Actualog can use separate templates for:
- standalone product names;
- variant group names;
- variant names.
Brand-category name templates
A Brand category normally uses a brand relationship token and commercial model information.
Example product template:
[Category] [Brand] [Model]
Example group template:
[Brand] [Model group]
Example variant template:
[Group name] [Variant axis values]
The group name contains the stable identity shared by all variants.
The variant name adds values that distinguish the individual variant.
Manufacturer order codes should be stored in their dedicated identifier fields. They should not automatically replace the canonical product or group name.
Standard-category name templates
A Standard category normally uses specification and dimensional attributes.
Example group template:
[Category] [Standard] [Material grade]
Example variant template:
[Group name] [Nominal size] [Key dimensions] [Class]
Do not include a Brand token in a Standard category name template unless the category has explicitly been designed as Brand-based.
Preview the Effective Template
Before submitting the category, review its final effective template.
The effective template combines:
Attributes inherited from concrete parents
+
Attributes inherited from attached Universal categories
+
Attributes added directly to the category
-
Duplicate Attribute IDs
=
Final Product-level template
The preview should show:
- every resulting attribute;
- where each attribute is inherited from;
- attribute group and display order;
- requiredness;
- value type;
- measurement unit;
- validation rules;
- identity participation;
- search and filter behavior;
- name-template participation;
- variant-axis participation.
The preview should also identify:
- duplicate attributes;
- conflicting measurement units;
- incompatible value types;
- missing required definitions;
- name-template tokens that are not available;
- variant axes that are not part of the template;
- attributes placed at the wrong inheritance level.
Hex can analyze the preview and propose corrections before review.
Test the Category with Representative Products
Before approval, create or simulate several representative products.
Include:
- a typical product;
- a simple product;
- a complex product;
- a product with variants;
- products from more than one brand for Brand categories;
- products from more than one manufacturer for Standard categories.
Confirm that users can:
- classify each product correctly;
- enter its specifications without workarounds;
- generate a meaningful name;
- distinguish variants;
- compare products;
- identify missing information;
- avoid irrelevant attributes.
A category should not be approved solely because its taxonomy name looks correct. Its effective template must work for real products.
Category Review and Approval
When the category draft is complete, submit it for review.
The reviewer checks:
- whether a duplicate category already exists;
- whether the category definition is clear;
- whether the concrete parent is correct;
- whether it is Family-level or Product-level;
- whether the Standard or Brand decision is correct;
- whether Universal categories are used correctly;
- whether library attributes are reused;
- whether direct attributes are genuinely category-specific;
- whether units and validation rules are correct;
- whether attribute groups are understandable;
- whether variant axes are appropriate;
- whether name templates generate stable names;
- whether representative products fit the model.
The reviewer may:
Approve
Return for correction
Reject as duplicate
Merge with an existing category
Request additional expert review
An AI-generated category follows the same review process as a human-created category.
Publish the Category
Approval confirms that the category model is accepted.
Publication makes the category available in the shared taxonomy.
A published Product-level category can be used for:
- company-category relationships;
- brand-category relationships;
- product creation;
- product import;
- product classification;
- Product Overview;
- Product Stewardship;
- search and comparison;
- catalogs and integrations.
Publishing a Product-level category activates its effective template.
A company that requested the category can then link itself and its applicable brands to the published category.
Draft and unapproved categories should not be used for normal product creation.
Updating a Published Category
Published categories continue to evolve.
When a Category Expert changes:
- inherited categories;
- Universal category attachments;
- attributes;
- units;
- validation rules;
- name templates;
- identity rules;
- variant axes;
Actualog creates or prepares a new category revision.
The currently published model remains active while the revision is reviewed.
After the revision is approved and the new effective template is activated:
- new products use the new template immediately;
- existing products are checked and updated asynchronously;
- safely convertible values are updated;
- names and identity are recalculated where required;
- products that need human decisions are placed in the appropriate work queue.
Existing product data is never silently reinterpreted under a new template.
See Asynchronous Product Updates After Template Changes for the complete update process.
Example: Modeling Nondispersive Infrared Gas Sensors
A company manufactures NDIR gas sensors under the MIPEX brand.
Step 1: Search
The company searches for:
Nondispersive Infrared Gas Sensor
NDIR Gas Sensor
Infrared Gas Sensor
If a suitable Product-level category exists, the company links to it and adds the MIPEX brand.
Step 2: Create a proposal when no category exists
Hex analyzes representative MIPEX products and proposes:
Category:
Nondispersive Infrared Gas Sensor
Category role:
Concrete
Concrete level:
Product-level
Identity mode:
Brand
Concrete parent:
Gas Sensor
Step 3: Attach Universal categories
Electronic Device
Instrument
Commercial Model
Step 4: Reuse inherited and library attributes
From Gas Sensor:
Detected gas
Gas concentration measurement range
Response time
From Electronic Device:
Operating voltage
Power consumption
Output type
Communication interface
Direct NDIR-specific attributes:
Infrared source type
Optical path configuration
Optical chamber type
Step 5: Configure groups
Product Model
Gas Measurement
Optical System
Electrical Characteristics
Performance
Environmental Conditions
Dimensions and Weight
Step 6: Configure variants and names
Group name template:
[Brand] [Model group]
Example:
MIPEX 02
Variant axes may include:
Detected gas
Measurement range
Output configuration
Variant name template:
[Group name] [Detected gas] [Measurement range] [Output configuration]
Manufacturer order codes remain stored separately from the canonical generated name.
Step 7: Review and publish
A Category Expert reviews the inheritance, attributes, units, axes, and templates.
After approval and publication:
- MIPEX links its company and brand to the category;
- products can be created or imported;
- Actualog generates consistent names;
- product data is validated against one shared effective template.
Rules That Keep the Product Domain Clean
- Search before creating a new category.
- Link companies to existing shared categories instead of creating private duplicates.
- Link brands only to Brand categories where brand defines product authority and identity.
- Use concrete parents for vertical taxonomy inheritance.
- Use flat Universal categories for horizontal reusable attribute bundles.
- Create products only in Product-level categories.
- Decide Standard or Brand for every Product-level category.
- Reuse library attributes before creating new ones.
- Keep brand, manufacturer, company, and supplier as relationships, not category attributes.
- Use attribute groups only to organize the interface.
- Use existing structured attributes as variant axes.
- Keep stable shared identity in the group name and variant differences in the variant name.
- Test the effective template with real representative products.
- Let AI prepare and explain drafts, but require human governance for approval and publication.
- Update published categories through controlled revisions rather than changing live product semantics silently.
Result
A completed product-domain model gives the company:
- the correct category relationships;
- the correct brand authority;
- reusable category inheritance;
- complete and consistent product templates;
- faster product creation and import;
- reliable product names and variant structures;
- comparable product data;
- controlled approval and publication;
- a foundation for automation and AI-assisted product management.
The objective is not to reproduce a company spreadsheet inside Actualog.
The objective is to create a shared, governed product model that many companies can use while preserving clear ownership, expert control, and one consistent version of product truth.````