Finding and comparing product features

Answered 5 October 2026. Both recommendations are approved. Feature categories, product-specific names and links to demonstrating work are already approved. This review asks how people should find overlapping capabilities and compare them without losing the company's own wording.

Your recorded answers

Question	Recommendation
Can a feature appear in several relevant categories?	Yes, with a reason for each membership and one feature identity.
Should comparison use specific, defined capabilities?	Yes, where the evidence supports them. Preserve the original feature or bundle name alongside them.

You approved both recommendations. No repeat answer is needed. The examples below illustrate the behavior; their category names are not a proposed complete vocabulary. This does not require another fixed level in every product tree.

Already decided — no repeat answer needed

You approved adding feature categories in July, with the condition that types, names and categories remain clear and scale sensibly. Your October answer explains the research journey: someone studying shopping features should find relevant products, their named features and the work demonstrating them.

A product category and a feature category answer different questions. A named feature stays connected to its product. A short demonstration describes the relevant moment, not necessarily the entire video. A publisher's claim and an observed demonstration remain distinguishable. The Products page carries these rules.

The earlier prototype is useful research, but its full vocabulary was not approved merely because it used the word canonical. We also cannot treat two identically named features as the same feature without supporting evidence.

1. Let a feature appear in several supported categories

Remaining question: should the same feature be findable through more than one relevant feature category, when each membership has support?

I recommend yes. Keep one feature, with several justified entrances. A category can organize discovery without becoming the feature's exclusive parent. A result should explain why it matched. Overlapping results should not inflate the number of distinct features.

Checked example: OpenAI's shopping research announcement describes finding suitable products, comparing alternatives and producing a buyer's guide. The selected library record already links the name shopping research to ChatGPT and that announcement. Under this recommendation, people could find the same named feature through a Shopping category and a Research category if the later vocabulary review defines both appropriately. Those memberships are proposed interpretations of the inspected text, not current approved assignments.

Counterexample: mentioning prices does not establish a payment or checkout capability. A feature should not enter every category related to its subject. A search result comparing shoes also does not make the software a footwear product.

Alternative: give each feature one category and use ordinary text search for everything else. That offers a simpler tree, but a researcher entering through another legitimate task may miss the feature. I recommend supported overlap rather than making people guess the preferred route.

What it affects: feature discovery, filters, comparison counts and tracker rules. It does not create duplicate products, change the type of the announcement or establish campaign membership. The complete category list and storage design remain separate work.

2. Compare a defined behavior without renaming the vendor's feature

Remaining question: should researchers be able to compare a specific behavior across products, even when one company's named feature includes several behaviors?

I recommend yes, when evidence supports the narrower comparison. Keep the original named feature or bundle intact. Link it to defined capabilities describing what someone can do. One named feature may cover several capabilities; a broad category alone need not imply that every product in it does the same things. This is an additional comparison tool, not a requirement to break every feature into tiny operations.

Checked example: the same shopping research announcement includes comparing alternatives and preparing a buyer's guide. Its original name should remain visible when a researcher asks specifically about comparing retail products. OpenAI's later product-discovery article also describes side-by-side comparison within a wider shopping experience. That is evidence to investigate the relationship between the observations; it is not proof that the two announcements describe separate features or identical versions.

The library also has a screening and comparisons description linked to ChatGPT and a Morningstar page. The current page identifies Morningstar as the developer and describes investment research. That context matters: comparing investments and comparing retail products should not be declared the same capability because both use the word comparison. Collection and analysis must retain the provider and integration context. The current page is not proof of every detail of an older capture.

Counterexample: a video showing a generic comparison table does not establish which product feature generated it. A generic shopping claim that does not describe comparison does not establish that capability. A publisher’s documented comparison claim remains a claim, not an observed demonstration. Missing evidence means unknown, not unsupported.

Alternative: compare only broad categories and original feature names, leaving finer differences in descriptions. This requires less vocabulary maintenance, but makes precise cross-product research depend on reading every description. I recommend adding a defined capability only when it supports a useful comparison and has clear inclusion and exclusion boundaries.

What it affects: product research, classification prompts, evidence links, comparisons and scoped questions. Claims must retain source and date; particular video intervals need their own support. Product identity, campaign membership, content form and creative credits remain independently evidenced.

What remains to verify

Accepting these recommendations sets the research behavior. It does not approve the prototype's entire list, an automatic feature merge, a new physical hierarchy or a production migration. The implementation audit still needs to verify identity resolution, correction preservation, complete writers and readers, and links to the exact evidence.

The evidence note records the recovered answers, current sample and research limits. The review desk keeps the independent graphics questions and the rest of the decision pass visible.

Prepared and answered 5 October 2026. The recommendations below are retained as the record you approved.

Last reviewed 5 October 2026.