Products

A product is a thing a company sells, and it is an entity in its own right. A product line sits inside its company, can carry its own brand identity — its own positioning, its own look — and never has to "become" a brand to earn that. The flagship phone line, the AI model, the shoe: each is a product we can track, link work to, and follow over time.

How products connect to everything else

Read it as sentences: a company sells products; a product family has models and variants; a bundle includes products; a product offers named features; content shows a product and can demonstrate a specific feature; and a campaign promotes the products it exists to sell.

Family membership and bundle membership answer different questions. An iPhone model belongs to the iPhone family. Word can be included in Microsoft 365 without becoming a model of Microsoft 365. Searching a family should include its descendants, while someone comparing individual models can narrow the result. Price and market position describe a product; they do not by themselves make a new level in its family.

Product categories and market tier

A product category names the kind of product, such as Watches. Its market tier, such as luxury or mass-market, is a separate description. Keep the ability to browse those tiers without requiring separate category names such as Luxury Watches and Mass-Market Watches.

This preserves the distinction people want to explore while avoiding competing names for the same kind of product. The recovered naming decision does not establish that the current vocabulary and filters already implement this rule.

What a product record holds

A product has one identity in the shared entity graph. Its family relationships belong there too. A product-specific detail record attaches to that identity, with at most one detail record for each product entity. That detail adds facts such as its category, launch date and flagship status; it does not create a second identity or a competing family tree. A product can carry its own brand identity and positioning while remaining part of its company's wider family.

Features — what the product actually offers

Named features are the individual capabilities a piece of work can point at. This is what separates "this video is about the product" from "this video demonstrates this specific capability" — the second is a far sharper fact, and it is the level the classification works at whenever it can. Content links directly to the features it demonstrates.

A feature has its own identity and can be linked to the products that offer it. Those product-to-feature links are separate from the links recording which pieces demonstrate the feature. Keeping both relationships lets someone browse a product's capabilities and then find work showing a particular capability.

Feature categories and names

A product category describes the kind of product. A feature category describes a reusable area of capability across products. A named feature identifies the particular capability a product offers, using supported source wording. These are different research questions; a category name must not replace the product-to-feature connection.

Someone studying shopping features should be able to find relevant products, inspect their named features, and compare the work or particular video intervals demonstrating them. Keep a visible activity, a publisher's capability claim and a verified feature relationship distinguishable. Knowing that a video concerns a product does not prove that every moment demonstrates every feature it offers.

If a source shows an activity without naming the feature, describe what is supported and leave the specific identity unresolved. A newly observed interaction can be proposed for vocabulary review. It must not silently create a canonical feature category or an invented product feature.

A feature can appear in several supported categories while keeping one identity. Each membership needs a reason, and overlapping results must not inflate the number of distinct features.

Researchers can compare specific, defined capabilities across products when evidence supports the comparison. Keep the original named feature or bundle alongside those capabilities. Do not require every feature to be broken into tiny operations. A broad category alone does not prove that all its members offer the same behavior.

The recorded feature review explains these distinctions and their counterexamples. Exact vocabulary, names shared across products and physical storage remain to verify. This explanation does not adopt every prototype label or claim that the complete search journey already works.

How work connects to a product

Content links directly to the products it shows, with one marked primary when a piece covers several. A campaign can likewise name the products it promotes. Both links carry who said so — whether an analyzer inferred it or a person confirmed it — like every other classification in the system.

A product or app can also be where a piece was collected. Keep that relationship separate from the products the piece shows or discusses, with evidence for each. People can browse either path without treating the source app as the subject or copying the piece. Neither path proves which tool made the work. The source and subject decision establishes this browsing requirement; the current writer and queries still need verification against it.

One identity, with product details

The entity and its product details describe the same product. This relationship was approved in July. It does not require two product destinations in the interface. The relationship reference records which parts the database and writers currently support; the open questions keep the remaining navigation choices separate from this approved identity model.

The vocabulary

The generated product category, product type and feature type pages preserve the extracted registry. They are not proof that every desired research category has been modeled. A selected live check on 5 October found only Capability, Marketplace and Model Behavior in the active feature-type list. Those broad kinds do not by themselves provide a shopping or comparison category across products. The detailed feature model still needs reconciliation.

A real example, measured on 2026-10-03

ChatGPT is the flagship product of OpenAI, and it shows both homes at once: a product record carrying the detail, pointing at an entity of the same name that carries the brand identity, sitting under its parent company. 4,223 pieces of content link directly to it — ask "show me everything featuring this product" and that link is what answers.

The layer as a whole: 139 product records, of which 129 (92.8%) have content linked to them, and 2 are marked as operating as brands in their own right. Alongside them, 394 entities are labelled as product lines — the entity-side home of the same idea. The feature layer contains 1,517 named features, 1,465 of them demonstrated by real work across 1,750 content-to-feature links. Separately, 1,621 links connect products to features. These measurements establish that the relationships are populated; they do not establish that every link is correct or that the interface exposes them completely.

Where to look next

• Every value you can actually choose — the full vocabulary, starting with the product vocabularies.
• How many products we hold, and how full the layer is — the state of the data.
• Where the live system disagrees with this page — the conformance report.
• What is still undecided about products — the open questions.
• The exact tables and columns — the data reference.

Last reviewed 5 October 2026.