Concept Walkthroughs
Every row is a count, not an opinion
Ratik3 min readProduct data checks for a named destination: required, recommended, not checked and not applicable are different findings.
A readiness number is only useful if you can identify the destination, requirements and evidence behind it. A count of missing fields cannot do that on its own.
Agent Readiness uses PLAIN / LIVING to show the distinction. Choose Google Search AI features, OpenAI product discovery or an agreed partner API contract. The interface recomputes local catalog verification states; it does not probe a live store or submit anything to a platform.
Five questions, whatever the catalog’s size
Can the destination access its source? Are descriptions available? Are identifiers resolved? Do published ratings agree? Is the delivery path verified?
The questions stay visible, but applicability changes. Google Search does not acquire a GTIN or catalog API prerequisite. The partner contract uses SKU identifiers and does not consume ratings. The OpenAI profile distinguishes descriptions from recommended rating details. These selected checks are not the full platform eligibility specification.
That is the difference between an instrument and a verdict. A verdict asks you to trust the person holding it. An instrument shows the reading and lets you re-take it.
What is already right, first
Each row leads with the known source and observed state. All three records publish price, availability, SKU, format and size; two descriptions are absent. Access and delivery that have not been checked are labeled that way. A guessed endpoint returning 404 would not prove a catalog has no API.
Only then does the row say what is missing. This is not politeness. A readiness report that opens on failures gets read as a sales document, and the specific thing you want a merchant to believe (that the numbers are real) is exactly what that framing costs you.
Required and recommended describe the requirement. Not checked describes missing evidence; not applicable excludes a check from the denominator. Resolving identifier assignment can therefore reduce the denominator without adding a field. Request counts remain separate context, never a speed or readiness score.
Different readers use different sources
An answer engine can use web pages as well as structured sources. A shopping feed consumes product data; a partner integration may need a documented API. These are different access paths, not evidence that every machine bypasses the page.
Google’s guidance for AI features adds no special AI-file or schema requirement. Files such as llms.txt, agents.txt or mcp.json are not scored as missing prerequisites. Public availability does not prove that a system fetched a record; that needs its own evidence.
Correct the record and watch the counts move
Apply the checks relevant to the destination. Add the missing descriptions, resolve identifier assignment, match a page rating, verify delivery or record source access. Changing destination resets verification so a result from one access path is not silently reused for another.
The identifier action records this catalog’s unassigned status; it never generates a GTIN. The exported value stays null, with the verification reason separate. In production, check assignment with the source and follow the selected platform’s identifier rules. Do not infer “not assigned” merely from a blank field.
Source: OpenAI: Product discovery feed fields and optional identifiers
What this does not tell you
Readiness is not visibility. A complete record does not establish that an answer engine will mention the store, that a missing field caused an omission, or that any ranking or revenue will follow.
Those are separate questions, and the honest way to ask them is a dated observation with its own stated limits: one question, one date, one platform, recorded as what it is rather than generalized into a trend. A scorecard that quietly implies otherwise has stopped being an instrument.
A record can be perfectly readable and still never be quoted. Measuring the first thing is useful. Selling it as the second is not.
Source: Google Merchant Center: About the Universal Commerce Protocol
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.
