Sector-Aware Catalogs: Separating Product Structure from Navigation

A retailer may sell trainers, televisions, vitamins and garden furniture through the same commerce platform. They share commercial concepts such as identity, price and availability, but they do not share the same descriptive structure.

Trainers need size system, width, upper material and intended activity. Televisions need panel technology, resolution, ports and refresh rate. Vitamins need ingredients, dosage and regulatory information. Furniture needs dimensions, materials, room placement and assembly requirements.

A catalog that treats all of them as one generic product either becomes extremely sparse or pushes important facts into descriptions, categories and custom fields. A sector-aware catalog accepts that products have different governed shapes while keeping them available through one consistent platform.

Product structure is inherited

The most important rule is that product data does not change governed structure without a merchant decision.

A product is created against a template. The template establishes which attributes apply, their types, units, required status and allowed values. A supplier payload can populate that contract after mapping and validation. An unknown field or value may propose a template change, but the merchant must approve, reject or ignore it before it becomes governed structure. An approval increments the schema version and leaves an activity record.

Products inherit structure from governed templates

Retail Vertical → Product Template → Validated attributes → Product and variants

This makes structure reusable. Every television that inherits the same template can be compared on the same dimensions. A template change can be audited across all affected products. APIs can state which contract a record follows.

Categories are not templates

Templates organise product meaning. Categories organise navigation. Confusing them creates the familiar deep hierarchy in which every attribute combination becomes another branch.

A television may appear in Electronics > Televisions, a promotional collection for a sporting event and a landing page for small spaces. None of those placements should determine whether the product has a refresh rate or screen size. Those facts remain attached to the television template.

Conversely, a template should not dictate exactly where a retailer merchandises a product. A portable projector might appear in home cinema, business equipment or travel collections while retaining one product contract.

Separating these responsibilities lets each change for the right reason.

Why “sector-aware” does not mean sector silos

The aim is not to build a separate catalog application for every retail vertical. Shared platform capabilities remain valuable: identity, versioning, permissions, import workflows, category management and APIs can all use common infrastructure.

Sector awareness exists in the governed model. A fashion sector may own templates for footwear, apparel and accessories. An electronics sector may own phones, televisions and audio equipment. Shared attribute definitions—such as brand, colour or country of origin—can be reused where their meaning really is the same. Domain-specific definitions remain scoped to the contexts that understand them.

This avoids two extremes: one universal schema that says too little, and isolated vertical systems that cannot share tooling or channels.

Attributes need context as well as names

Attribute labels are often deceptively generic. Size can mean a garment scale, shoe measurement, screen diagonal, storage capacity or package quantity. Reusing a label does not mean the underlying contract is shared.

A governed attribute needs a stable key, data type, unit or reference set, cardinality and context. Shoe size should identify the sizing system. Screen size should specify a unit and numeric interpretation. Storage capacity should support canonical units and conversion rules.

Context prevents a catalog from creating one ambiguous global size field or dozens of supplier-specific alternatives. It lets the platform reuse meaning deliberately rather than by coincidence.

Generated filters become possible

When a category or search result has a known set of product templates, the platform can determine which attributes are valid for filtering. The schema supplies the filter definitions and controlled values; actual inventory supplies counts and availability without deciding whether the filter exists. The interface can select suitable controls for numbers, ranges, enumerations or booleans.

From product context to trustworthy filters

Applicable templates → Governed filterable attributes and values → Occupancy counts → Generated facets

This is stronger than configuring a static filter menu or inferring the filter model from whichever products happen to be present. Merchandising can still control ordering and labels without maintaining a separate definition of product meaning.

Supplier data adapts at the boundary

Sector-aware templates also improve onboarding. A footwear supplier and an electronics supplier can use very different source formats, but each maps into an explicit target contract.

The mapping layer can normalize units, translate supplier terms into canonical values and surface missing required fields. Unrecognized meaning becomes a review decision. The supplier’s schema remains traceable as source data, but it does not become the retailer’s architecture.

This matters when multiple suppliers describe the same product type. Without a shared template, every feed creates another version of the domain. With one, integrations become repeatable and product comparison becomes credible.

Evolve templates without losing control

Retail domains change. Regulations introduce required facts, customer expectations change, and new product technologies appear. Templates therefore need versioning and migration workflows.

A new attribute should identify the affected templates and products. Existing records can be measured for completeness. Import mappings and API consumers can be updated deliberately. Some changes are additive; others require a new template version because they alter the meaning or type of an existing field.

Document storage can make these changes easier to represent, but governance determines whether they are safe. Flexibility at the database layer should support template evolution, not bypass it.

One catalog, many product contracts

A sector-aware catalog provides one operational surface without pretending there is one universal product shape. Shared APIs can expose common identity and lifecycle fields alongside attributes defined by the product’s template. Channels can request projections appropriate to their needs. Search can index comparable facts with their context intact.

The result is a catalog that reflects real inventory. Categories remain useful and thin. Products inherit explicit structure. Filters emerge from governed attributes. New sectors can be added through new contracts rather than new workarounds.

That separation is the foundation of durable catalog architecture: navigation tells customers where to browse; templates tell every system what the product is.