Product-feature comparison — bounded evidence

This note supports the two remaining product-feature choices. It separates recorded direction, observed records and proposed behavior. No database, prompt, pipeline or automation was changed.

Prior answers and prototype context

• The original July response in docs/reference/2026-07/2026-07-21/theratificationcnooslejuly21.md, under g-11-c, explicitly approves a Feature-Category level, qualified by clear types, names and categories that work at scale. The original proposal's no-schema-change assertion is historical, not a verified current implementation fact.
• The October response in docs/reference/2026-10/2026-10-05/morning-three-reviews-joe-response.txt requires research across shopping features, product-specific names and the work demonstrating them. It does not approve every prototype label.
• The existing local pilot PLAN separates product category, feature category, capability and vendor wording. The original normalization-contract.contract inside its evidence/reference-reconciliation/figma.json is explicitly an analytical comparison vocabulary, not approved Atlas vocabulary. It preserves source bundles, scope and uncertainty rather than claiming all products behave identically.
• The Products page already distinguishes product identity, feature identity, product links and demonstrating work. Multiple memberships and precise comparison boundaries are residual choices. Equal names alone are not an identity rule.

These sources were reread in this preparation. The older Brand Events thread remains reference material; it does not override Joe's later answers. The referenced prototype conversation was not newly reopened in this batch; the original repository contract and qualified approvals were inspected directly.

Selected live check on 5 October

Schema was read before the selected records. The saved SQL responses cover product_features, product_feature_tags and content_features, with a targeted sample of shopping and comparison names. The sample contains supported product and content links, but stored links do not establish the accuracy of the classification.

The six sampled feature records span shopping research, retail comparison, investment analysis and experiment comparison. They are not a count of the complete feature vocabulary. Selected links lead to the shopping research announcement, the product-discovery article, the Morningstar page, a moderation page and the Gym announcement. Only the three sources used by the review were read for its examples.

The present Morningstar URL redirects to a plugins page identifying Morningstar as developer. A stored association with ChatGPT must therefore be interpreted with provider and integration context. A changed current page is not sufficient evidence that an older capture or assignment was wrong. No records were corrected.

Exact queries and literal responses are saved in docs/reference/2026-10/2026-10-05/feature-comparison-live.json. This is a selected schema and record check, not a full constraint, permission, index or deployed-consumer audit.

Primary sources and independent challenge

The published text of OpenAI's shopping research announcement, product-discovery article and Morningstar page was inspected. The review relies on written descriptions, not a claim to have tested the products or viewed an embedded demonstration.

The W3C SKOS reference distinguishes hierarchical and associative relationships and permits alternate paths. Its mapping section distinguishes types of correspondence. This supports carefully defined relationships; it does not decide our categories, mandate a graph database or make two vendor features equivalent.

Three approaches were considered:

Approach	Benefit	Limitation
Keep one feature category and the original name	Smaller maintained vocabulary	Precise comparisons depend on reading descriptions; alternate entrances are weaker.
Use supported overlapping categories	More useful discovery without duplicating identity	Membership needs reasons and counts must avoid duplication.
Add selective, defined capability comparisons	Makes narrower research possible while preserving bundles	Requires explicit boundaries and evidence; must not become automatic decomposition.

The recommendation combines the last two selectively. Provider context, product scope, observation dates and uncertainty must survive. Shared names and common technology do not prove shared identity. Category membership does not prove that a particular content item demonstrates a feature.

Remaining engineering work

Earlier local path findings are preserved in product-feature-path-audit.json beside this evidence. They remain leads for a complete writer/reader and deployed-parity check, not newly verified production defects in this preparation. The selected live probe does not close identity resolution, interval links, human-correction preservation, query behavior or migration design.

Approval of the two review choices would settle behavior only. Physical implementation must follow the complete audit and existing change controls. All remaining work stays in the existing review inventory.

Evidence gathered 5 October 2026.