Skip to main content

Part 04 · Guide 14 of 33

AI product feeds for one-of-one inventory

A unique item is not a generic product with a quantity of one, and the difference shows up in the record. This lesson sets out the three identities such a record carries, the fields the cited specifications require, the difference between a shape check and a cross-field check, the lifecycle transitions where the record and the world can diverge, a set of accepted and rejected test records, and what adopting the shape looks like without new software.

Reading time
13 min
Sections
10
Last updated
July 30, 2026
Published by
Instica

01

Three identifiers, carried together

Applies to marketplace onlyown storefronthybrid

The record carries three identifiers, and a validator expects all three populated before it examines anything else.

IdentityWhat it namesMeridian exampleFailure it prevents
ProductThe model1978 Meridian cameraTwo bodies from one job lot cannot be described as the same model
Physical itemThe exact owned unitMER-1978-041, with photographsTwo such bodies cannot be told apart
OfferCurrent sale termsOne USD storefront offerA relisted object inherits the terms of a completed sale

The middle row is the one selling platforms rarely supply, and the rest of the record attaches to it. Choosing its value, deciding what an absent manufacturer code should record, and resolving duplicates are covered in the identity lesson; this lesson assumes the three values are in hand.

The fourth column separates the failures because they arrive differently. The first two are data errors. The second is the one that surfaces weeks later as a dispute about which object a buyer received, since nothing in the record distinguishes them.

02

Merge and relist are different writes

Applies to marketplace onlyown storefronthybrid

Two operations look alike in a spreadsheet and are not the same write. A relist keeps the physical-item identity and issues a new offer or offer version. A merge retires one physical-item identity in favor of another and redirects it, which corrects identity rather than recording a commercial event.

A system that treats both as “make a new listing” can reprice one object twice or return a sold object to availability, and a validator cannot distinguish the two cases unless the record does. Channel listing IDs are references onto the object and the offer, so they are stored beside the physical-item identity rather than in place of it.

03

The minimum record

Applies to marketplace onlyown storefronthybrid

The downloadable v0.1 specification requires a stable item ID, a stable offer ID, title, canonical URL, exact-item images, normalized and narrative condition, currency and minor-unit price, availability state, quantity, observation time, version, seller link, and policy links. The accompanying JSON Schema checks shape, and the validator adds cross-field lifecycle rules.

These fields come from the cited specifications rather than from this course. OpenAI’s current product API requires stable product and variant identifiers and exposes price, availability, condition, media, and seller links.1 The Schema.org Product vocabulary represents the same commercial facts on a page,2 alongside the Offer vocabulary for price and availability.3 Neither vocabulary synchronizes inventory between systems. The v0.1 record is written once so that one answer serves every destination.

LayerQuestion it answersWhat it cannot answer
JSON SchemaIs the field present, is it a string, is the date shaped like a dateWhether two fields agree with each other
Cross-field validatorDo state, quantity, and timestamps agreeWhether the values describe the object accurately
A person with the itemWhether the grade and the photographs match the objectNothing further is automated

A record can be well-formed and still state that an item is available in a quantity of zero, or that a sale occurred before the state was last observed. Those are agreements between fields, which is the second row.

Prices are stored in minor units. Decimal representations accumulate rounding differences as they are parsed and re-serialized across systems, and minor units remove that difference.

04

Facts that can be checked

Applies to marketplace onlyown storefronthybrid

A checkable claim is one a buyer or reviewer can trace to something specific. Three groups of fields carry them.

  • Factual title, condition label, notes, defects, inspection date, and photographs of the exact unit.
  • Price and currency paired with availability state, timestamp, shipping, return, and geographic limits.
  • Authenticity stated only where a verification step exists to point at.

Where a fact lives determines whether anything can check it. A defect described only in a paragraph is not reachable by a validator or by a system reading the record mechanically. The same defect in a condition field with an inspection date beside it can be compared against the grade and flagged when the two disagree. What to put in those fields, and how far a claim can go, is the subject of the evidence lesson.

05

Three required condition fields

Applies to marketplace onlyown storefronthybrid

Condition is three required fields rather than one: a normalized value, unit-specific narrative and media, and an inspection date. A record supplying only the first passes a shape check and carries nothing specific to the object.

The validator enforces the pairing, not the content. It can require that a grade never stands alone, that media is present, and that the assessment carries a date comparable against the other timestamps. It cannot determine whether the grade is accurate or whether the photograph shows the object in hand, which is why writing those values is covered separately.

06

Designing for quantity races

Applies to marketplace onlyown storefronthybrid

A quantity of one does not prevent two channels from acting on stale state. The record uses a version token or an equivalent conditional update, defines when a reservation becomes authoritative, and makes sold or withdrawn terminal for the current offer.

A version token works by a single rule: a writer reads the record along with its current version, and the update is accepted only if the version is still what it read. If something else changed the record first, the update is rejected and the writer re-reads. The rule converts a silent race into a returned error.

Where cross-channel reservation is unavailable, the record states that as an operational limit and the verification interval is shortened, leaving the residual risk manual. The description that causes trouble later is “synchronized,” because it will be relied on by whoever next decides how many channels to add.

07

The lifecycle transitions

Applies to marketplace onlyown storefronthybrid

Each transition below is a point where the record and the world can diverge. Naming them is what makes the divergence detectable.

  1. Create a full record with a version.
  2. Reserve only where the merchant process can actually prevent a conflict.
  3. On sale, make the source unavailable and propagate removal.
  4. Verify every surface, then retain a truthful tombstone or redirect.

The fourth step contains two verbs on purpose. Propagation and verification are separate actions with separate failure modes, and the record carries the surface list that verification walks. How long that walk takes on a given setup is measured in the removal-latency lesson.

The second step is conditional for a reason. A reservation that cannot prevent a competing sale records a protection the system does not provide, and the record then states something that is not the case.

08

Accepted and rejected test records

Applies to marketplace onlyown storefronthybrid

The fixtures are the executable form of the rules above. Each rejected case is a record a shape-only check accepts, and each reason names the cross-field rule that catches it.

RecordExpected resultReason
Complete available offerAcceptRequired identity, facts, and timestamps agree
Missing item-specific conditionRejectThe exact unit cannot be evaluated
Available with quantity zeroRejectCommercial state contradicts quantity
Sold offer updated before its observation timeRejectLifecycle timestamps are inconsistent
Stable tombstone after saleAcceptThe old URL cannot be read as a live offer

Rejecting on ambiguity is the default here because the two error directions cost differently. A rejected record costs a listing. An accepted contradictory record for a single object can sell it twice.

The rejected fixtures are run alongside the accepted ones. A suite that only demonstrates good records passing continues to pass after a rule is loosened; the negative fixtures are the ones that fail at that point.

09

Adopting the record without new software

Applies to marketplace onlyown storefronthybrid

The specification describes a record shape. A seller running a spreadsheet and two marketplace accounts can satisfy most of it with three columns: a physical-item column that never changes, an inspection-date column beside the condition grade, and an observed-at timestamp beside availability. Those three turn a row from an assertion into a dated observation.

A column only helps if something moves the timestamp when the value moves, which is the practice covered under removal latency.

One adjacent finding is often read as more than it says. Peer-reviewed catalog-quality work reports reference-backed record repair using brand knowledge bases and agents, conducted inside the authors’ own large-retailer setting.4 It reports results for structured catalog facts in that setting. It does not describe a service that assesses a seller’s own stock, and the evidence lesson covers why.

Applied to the camera, the row carries four columns, one of which has no value yet.

Column addedValue for MER-1978-041What it makes checkable
Physical-item IDMER-1978-041, fixed at intakeWhich of two similar bodies is being discussed
Inspection dateRecorded when the shutter was testedWhether the grade reflects a recent examination
Observed-atStamped whenever availability is writtenHow stale the offer is at the moment of reading
Cross-channel reservationNot yet tested under a real raceNothing yet; this is the next measurement

The adoption order follows the cost of each failure. Identity first, since everything attaches to it and retrofitting it onto historic rows is the largest job. Lifecycle second, where a sale can go wrong. Condition evidence third, where returns and disputes arise. A partial adoption that records which parts are done is a usable state to be in.

10

What the record requires

Applies to marketplace onlyown storefronthybrid

The v0.1 record requires three identities, a condition grade paired with unit-specific evidence and an inspection date, price in minor units with currency, availability with an observation time, a version token, and defined lifecycle transitions ending in a verified removal.

The field requirements are drawn from a product API that requires stable product and variant identifiers,1 and from vocabularies that represent the same commercial facts on a page.2 Price and availability come from the Offer vocabulary.3 None of the cited documents specifies how a seller resolves a race between two channels, and none of them synchronizes inventory; those remain the seller’s process.

11

Practice

Exercise

Write and test an agent-safe record

  1. Complete the product, physical-item, and offer identifiers for one real item.
  2. Add one condition fact with an inspection date and a link to evidence for the exact unit.
  3. Simulate a sale, mark the offer unavailable, and list every surface that needs verifying.
Specification · download Agent-Safe Unique Inventory Spec v0.1 Vendor-neutral field dictionary, state model, and validation checklist.

Check yourself

Is a generic product ID sufficient for a one-of-one listing?

No. A generic product ID identifies a model. A unique listing also needs an identifier for the distinct owned object and one for its current offer.

A record passes JSON Schema validation but states the item is available with a quantity of zero. Which layer catches that?

The cross-field validator. A schema checks field presence and type and cannot express agreement between fields, which is where contradictions between state, quantity, and timestamps appear.

Two records describe the same physical camera. Is correcting that a relist?

No, it is a merge. One object identity survives and the retired alias redirects to it. A relist keeps the same object and changes the offer.

Which two fields does the validator refuse to accept on their own?

A condition grade with no unit-specific evidence beside it, and an availability state with no observation time. Both pass a shape check and neither is checkable.

12

Common questions

Does structured data reduce duplicate-offer risk?

It can make a record clearer to read. It does not synchronize availability between systems, and it does not remove the step of verifying removal after a sale.

Why store prices in minor units instead of decimals?

Decimal money accumulates rounding differences as it is parsed and re-serialized between systems. Minor units remove that class of difference, so the record and the landing page state the same figure.

What if the commerce system cannot reserve stock across channels?

Record that as an operational limit, shorten the verification interval, and treat the residual risk as manual. What causes trouble is describing the setup as synchronized when nothing enforces it.

Does the specification require software to adopt?

No. Three added columns — physical-item ID, inspection date, and observed-at — carry most of the shape in a spreadsheet, provided something updates the timestamp when the value changes.

13

Research and sources

Rules and platform policies change. These primary sources were reviewed on ; confirm the current position for your jurisdiction and account before acting.

Claim evidence

OpenAI’s current API requires stable product and variant IDs and exposes price, availability, condition, media, and seller links.
technical requirement. Supported by Agentic Commerce API: Products .
Product and Offer vocabularies represent product and commercial facts but do not synchronize inventory.
technical requirement. Supported by Schema.org Product , Schema.org Offer .
Peer-reviewed catalog-quality research reports reference-backed repair in its studied large-retailer setting, not automatic transfer to resale inventory.
observed outcome. Supported by Using brand knowledge bases and LLM agents to enhance e-commerce retailers’ catalog quality .

Start with 25 items. Stay for 25,000.

Free for 25 items · No card · Cancel from your account page.

También disponible en españolEspañol →
Disponível em portuguêsPortuguês →
Auf Deutsch verfügbarDeutsch →
Disponible en françaisFrançais →
中文版本可用中文 →