Guides
Product records for AI discovery: what to fix, what not to promise
Ratik7 min readStart with accurate source facts, matching product pages and valid records. Know what those fixes can establish, and what they cannot promise about discovery.
A pictured bottle says 60 capsules. Its catalog record says 30. Before discussing AI discovery, fix that disagreement.
Our Product Catalog concept uses PLAIN / LIVING products to make that work visible. Choose a local record destination, review corrections across three products, apply selected fields and copy the actual working record. It is a local demonstration, not a live enrichment service or evidence of search performance. The production question is broader: can your business keep product facts accurate wherever customers and systems encounter them?
Establish the source before filling the field
For each product, identify where a fact is approved and who can resolve a conflict. A supplier document, a product label and an internal catalog may disagree. Collecting all three does not tell you which one is current. That needs an ownership decision, not a more confident generated answer.
In a proposed audit, start with the identity of the exact item being sold. Separate the product family from the variant, the unit from the multipack and the shipping weight from the quantity inside the package. Record where the value came from and when it was checked. Leave an uncertain fact unresolved rather than inventing a plausible replacement.
The concept shares Daily Essentials (60 capsules), Plain Blend (300 g) and Mineral Drops (30 ml) with the PLAIN / LIVING shopping experiences. Description, format and pack facts come from the shared catalog. SKU, identifier provenance and review-source alignment need their own declared evidence. A label photograph alone cannot settle all of them. A real catalog would require your approved sources and a review process before making equivalent changes.
Keep an unverified identifier distinct from a verified declaration that none is assigned. Neither is permission to create a plausible code. Apply the same discipline to reviews: an unavailable review source does not justify borrowing another product’s rating or count. The concept keeps these evidence gaps visible alongside the corrections its sources do support.
For Plain Blend and Mineral Drops, its assignment and rating records are authored examples reused from Agent Readiness. Their source ratings of 4.6 from 214 reviews are demonstration values, not verified customer reviews, and their verified-unassigned declarations do not represent supplier checks. Daily Essentials has no assignment or rating evidence in this workspace. All GTIN values stay null.
Separate readiness from visibility
Google says its AI search features do not require special schema. Eligibility depends on normal Search requirements, including indexing and the ability to show a snippet. Meeting those conditions does not guarantee inclusion. That guidance concerns Google Search; it is not a universal rule for every answer engine.
This creates a useful boundary for a project. You can inspect whether source facts are accurate, whether published pages expose them and whether the intended technical output is valid. You cannot responsibly promise that correcting a field will produce a particular citation, ranking or recommendation.
Use the same boundary when reviewing a proposal. Ask what will be delivered, how it will be checked and which outcomes remain outside the team’s control. “We will make the record agree with the approved source” is an acceptance criterion. “AI will recommend your brand” is not an equivalent promise.
Validate the record and the page
A machine-readable record and a useful product page solve related but different problems. The record expresses facts in defined fields. The page helps a customer understand the item, compare options and decide what to do next. Neither should contradict the other.
Google’s structured-data guidelines require markup to represent visible page content and make clear that valid markup does not guarantee a rich result. Passing a technical test therefore belongs alongside factual and page-level review, not in place of it.
For a proposed review, put the source, visible product page and generated record next to each other. Check a field from origin to output. Then change a sample value in a safe test environment and confirm it reaches the intended places without altering a sibling variant. This exercises the publishing path, not just a static example that happened to be correct once.
Our concept’s copyable record is plain data for inspection. Its working values change only when selected corrections are applied; viewing a proposal does not silently export it as an accepted fact. The selected destination determines which fields appear. It is not a complete Product schema implementation, a merchant feed or a submission to a discovery platform. Its purpose is to make the relationship between source, decision and output clear enough to challenge.
Keep every destination in agreement
Google Merchant Center’s product specification requires price and availability to agree with the landing page and checkout, and describes accurate product identifiers and variant information. Those requirements are a concrete example of why a clean record cannot be treated as an isolated document.
Map the destinations your business actually uses. Your storefront, app, product feed and shopping guide may read from different services. Identify which service owns each fact and where transformations occur. If one system stores a pack quantity as a number and another as free text, test the conversion rather than assuming both mean the same thing.
The Product Catalog workspace uses two declared local contracts: Storefront product record and SKU-based partner export. Their requirements explain the priority of its worklist. These are authored examples, not implementations of the Google specification or another platform’s rules. Selecting a destination changes what needs attention without changing the approved source facts.
For example, correcting Plain Blend’s SKU from C-02 to P-01 is Recommended for the storefront and Required for the partner export. The partner contract excludes GTIN and ratings from its worklist and JSON. Those facts remain in local state; leaving a field out of one destination does not resolve its evidence elsewhere. Also decide how updates travel. A one-time cleanup is incomplete if the next product import restores the old values. Give the team an explicit way to spot a stale destination, trace its source and correct the publishing rule. This is a proposed operational design, not a promise that every store needs the same architecture.
Give a guided answer a factual boundary
Guided Product Discovery uses PLAIN / LIVING products to show clarification, no-match and health-refusal paths before a supported product choice. Visitors can inspect source facts before adding a product to a local basket. The conversation is scripted; it does not infer a diagnosis or establish that a product is suitable for someone’s health needs.
That narrow scope makes the design question easier to examine: does the explanation actually follow from the information supplied? A shopper choosing capsules can understand why a capsule product appears. An answer making a much broader promise would require different evidence and review.
When planning your own guide, define both supported questions and the response to unsupported ones. Decide what happens when a fact is missing, two sources disagree or a product is unavailable. A clear limitation can be more useful than a fluent answer that cannot be traced to a reliable record.
Choose a manageable first release
Select a small, representative group of products, including meaningful variants and at least one known data conflict. Agree the source owners, the fields in scope and the destinations that must match. Keep any unresolved facts visible to the person approving publication.
Acceptance should include the boring cases: unchanged fields remain unchanged, missing information is not silently filled, the correct variant is updated and copied or exported data matches the applied version. The Product Catalog lets you explore that discipline through a smaller local example. Applied changes survive a change of product, chapter or destination; pending selections clear so an unfinished choice does not follow you into a different review context.
After publication, monitor factual errors and publishing failures separately from discoverability. If a page appears in a search or answer result, check what it says. If it does not appear, do not conclude that its structured data must be incomplete; the observation alone cannot establish the cause.
Bring one product, its current page and the record that feeds it. We can use that concrete example to define a useful first correction and the work required to keep it correct. Start with information your customers can trust. Treat wider discovery as an outcome to observe, not a result to fabricate.
What would this look like for your brand?
Talk directly with a founder about one customer journey, the systems behind it and a focused prototype using your approved products and content.
