Where product data stops meaning the same thing

The short answer

A field name is not a field meaning. Three attributes turn up in both a commerce system and a regulatory format under the same word, and in each pair the two fields describe different objects. A mapping built by matching names therefore produces values that validate, look right and are wrong.

The three are material, weight and brand. They fail in both directions, which is the part that catches people: a value good enough for a shopping feed is not a compliance value, and the compliance value pushed back the other way arrives as a string the feed cannot use. A fourth thing, the category a product belongs to, does not map at all.

Two harder failures sit underneath that, and both are worth naming early. Where dates are concerned there are four clocks rather than one, so the simplest question anybody asks of a claim cannot be answered from what the systems hold. And on some platforms the destination field has no room for the value in any form: on one of the four platforms read for this page, the verdict is not that the work is hard but that it cannot be done there at all.

The idea that a product record can be structured once and used in many places holds at the identity layer and at the party layer, where the same object really is being described twice. It fails at the attribute layer, and the sections below are the places it fails.

Why one word ends up meaning two things

Neither side is careless. A commerce system defines an attribute by what it does with it, and what it mostly does is filter, rank and display. A material value exists so that a shopper can narrow a results page to cotton, so a short string is not a shortcoming there. It is exactly the right design for the job it has.

A legal instrument defines an attribute by who is accountable for it and for what. The same word then has to carry a closed vocabulary, an arithmetic and an addressable person behind it, because somebody may be asked to stand behind the answer. Those two designs are not versions of each other at different levels of detail. They are different objects that share a label.

The practical consequence is that name matching is not a weak method here, it is an unsafe one. Two fields called material agreeing on their name tells you nothing about whether either can hold what the other holds.

The three that catch people

Material

A shopping feed's material attribute is documented as the main fabric or material of the item, and it holds one primary value with room for a small number of secondary ones. There is no place in it for a percentage. One catalogue system's published taxonomy is arranged the same way: its apparel categories carry a single fabric attribute, which is a category rather than a breakdown, and it is not held per component, so a shell, a lining and a trim collapse into one word.

What labelling law asks for is a different kind of object. Only the names on a closed statutory list may be used, each fibre carries a percentage by weight, and the list runs in descending order. That is a value with a right answer, checkable against a vocabulary and an arithmetic.

So the direction of travel matters more than the mapping table. Composition can be reduced to a filter value, losing everything that made it a compliance value. A filter value cannot be promoted into a composition, because the percentages were never there to lose.

Weight

Several systems in an ordinary stack carry a field called weight and they do not describe the same object. A catalogue's weight field exists to price a shipment. A passport wants the product's own mass, without packaging, because impact figures and fee calculations divide by it.

The failure here is the mildest of the three to describe and the hardest to detect. A shipping weight for a shirt in a mailing bag is close enough to the shirt's mass to pass any plausibility check, and every figure calculated from it is then wrong by the weight of the bag. Where a producer responsibility scheme charges on mass, that same gap becomes money, though this page does not tell you what any scheme charges on: the textile producer responsibility instrument sits in our registry unread.

Brand

Brand is the false friend with the largest gap between the two objects, because on the commerce side it is not an entity at all. A feed requires a brand on new products and treats it as a name shown to a buyer. Whether anything stands behind that name is not a question the field asks.

The regulatory side asks for a party. An online offer has to identify the manufacturer and give a postal and an electronic contact, and where the manufacturer is outside the Union it has to name the responsible person there instead. The framework behind passports uses the same shape, defining an identifier for an operator as a string identifying an actor in the value chain rather than a name for a range.

Mapping a brand string into a party field produces a record that passes validation and names nobody. The reverse mapping is worse, because a party record flattened back into a brand string throws away the addresses that were the point of collecting it.

Three more pairs that are not what they look like

The three above are the ones people meet first, because they are the ones a mapping tool offers to connect. Three more behave the same way and are harder to see, because in each case both objects arrive in the same field and nothing in the value says which one it is.

Declared against analysed

A composition value reaches a record two ways. Somebody declares it, usually a supplier writing down what was used, or a laboratory analyses a finished garment and reports what it found. Both land in a field called composition, and neither carries a marker saying which it was.

The difference decides what a disagreement means. Two declared values that differ are a records problem, and somebody has to work out which document is newer or better. A declared value and an analysed value that differ are a different question, with its own arithmetic and its own margin, and that question belongs to the composition attribute rather than to the mapping.

What this page adds is the storage point. If the record does not say which kind of value it holds, nobody downstream can ask the right question about it, and the distinction between something a supplier asserted and something a laboratory measured is exactly the kind of thing a field named composition drops on the way through.

Which chain of custody

A claim that a material is recycled or certified rests on a model for how certified material was kept apart from uncertified material on its way down the chain. Which model was used changes what the claim means. No attribute in any specification read for this page carries it, on either side of the mapping.

This page names no models. The standard that governs them is behind a purchase, it has not been bought and it has not been read here, so the vocabulary it defines is not ours to publish. The gap itself can be stated without it, and the gap is the part that matters for a mapping: two products whose composition and certification fields agree exactly can rest on different models, and nothing in either record would tell you so.

Verified against resolved

The last pair is a pair of states rather than of values. A field marked verified is recording that something happened: somebody checked this against something else, on a date. A field marked resolved is recording something different, that two values disagreed and one was chosen, or that an absence was given a reason.

They collapse into each other easily, because both look like a quality flag and a mapping tool will connect them without complaint. A verified value can still be one side of a disagreement nobody has settled. A resolved value can be one nobody has checked. Treating either state as the other produces a record that overstates one of them and loses the other.

Four clocks, and the question none of them answers

Ask the simplest question anybody can ask of a published claim. Was this true of this unit at the moment it was sold. Four different clocks bear on the answer, all four are written as dates, and no system holds all four against a single unit.

• The production date. One instant, fixed by the goods rather than by anybody's records.
• The claim date. The day the value was published, which is later and sometimes much later.
• The applicable period. The window the evidence itself says it covers, which is a property of the document rather than of the product.
• The validity of the evidence. The clock running on the document, where the document carries one at all.

This belongs on a page about mapping rather than on a page about governance, because it is the same failure as material and brand in a harder form. Four fields that all look like dates, and that any tool would map onto one another without complaint, describe four different objects. The object a reader actually wants, whether the claim held for this unit on the day it left, is none of the four, and it cannot be derived from them either.

The scheme documents sharpen the mismatch rather than softening it. A scope certificate runs a one year clock and prints on its own face that it provides no proof that any goods delivered by its holder are certified. The transaction certificate, which is the document that does say something about goods, carries no expiry field at all. So the paper that expires is not about the unit, and the paper about the unit does not expire.

The governance half of this, who owns a published field and what happens when it turns out to be wrong, is a separate question with a page of its own, and the four clocks are drawn there at full size against the life of one unit.

Where the system runs out of room

Everything above assumes the destination field exists. Often it does not, and that is a property of the platform rather than of the mapping. Four platforms were read for this page and the four answers differ enough that a plan written for one of them is wrong for the other three.

What a platform can hold

One of the four has a full definition layer for custom data. A definition is created before any value is stored, the definition carries a type, values are validated against that type, there is a documented limit on how many fields one structured object definition can carry, and there is a documented storage envelope. That is the most capable of the four, and it still shapes what a passport can look like there, because a flat passport does not fit inside a single definition and has to become linked objects instead. The guide to that catalogue system works through what it holds and what it does not.

The other three go downwards from there, and they are described below by what their own documentation says rather than by name, because no address for those reads is registered in our source list.

The first of those three deserves a stop. Across everything read for this estate, verdicts on data work are ordinarily degrees of difficulty: expensive, slow, dependent on a supplier who has not answered yet. This is the single place where the answer to whether a value can be held as structured data at all is that it cannot. A reader on that platform does not have a mapping problem to solve. They have a platform decision to take, or a second system to run beside it, and no amount of care with the mapping changes either.

What survives into a feed, and into an agentic catalogue

The same shape appears at the other end of the chain. A value that survived the catalogue then has to survive the feed, and the feed's attributes have ceilings of their own. The material attribute of one shopping feed specification takes a main value with room for a small number of secondary ones, is capped in length and has no place for a percentage. Its certification attribute is stricter in a different way: it accepts a closed list of four certification families, and no textile scheme is among the four. A textile certification does not fail validation there. It has no value it could be expressed as.

Beyond the feed sit the agentic commerce catalogue specifications, which is where this subject usually arrives in the form of a question: will structuring product data make a product findable on an AI shopping surface. Nothing read for this page supports that, and this estate does not publish it. What can be published is what the specifications carry, dated, because this is the fastest moving material on the estate.

Two things follow from that table and neither is comfortable. A passport attribute has nowhere to arrive on those surfaces as they are described today, so structuring it upstream does not place it there. The same fact read the other way is more reassuring: a specification with no field for a certification is not penalising a product for lacking one either.

One distinction does most of the work in this section. A vocabulary that offers a property is not evidence that anything consumes it. Where a general vocabulary does carry a product property, what has been read is the vocabulary rather than any surface's use of it, and availability and consumption are different facts with different evidence behind them. Only the first of the two is documented anywhere we looked.

So the publishable position here is a negative, and it is worth writing down precisely because the positive version circulates: structure the data and the AI surfaces will reward it. Nothing read for this page says so. The rows above carry their dates for that reason. If a materials, certification or provenance attribute enters one of those schemas, this section changes rather than being defended.

What survives the crossing, and what has no counterpart at all

Two layers survive contact with all of this, and it is worth being precise about which.

Identity. The trade identifier is the one attribute that means the same thing in a catalogue, in a feed, at a marketplace and in a passport. It is a join key rather than a description, which is exactly why it travels. It is also the attribute a business is most likely to be unable to supply cleanly, and what committing to one involves is a question about that attribute rather than about mapping.

The party. Who is responsible, at which address, reachable how, is the single most re-entered dataset in the chain. It is also not a product attribute: it belongs to a business or to a catalogue, and it changes when the business changes rather than when the product does. Product systems have no natural home for a thing that is not a property of a product, so it ends up stored once per product and once per channel, then diverges quietly between the copies.

That is the real shape of the reuse argument. Establish identity once and responsibility once, then translate into each destination's own vocabulary with the meaning and the provenance intact. It is a narrower promise than the one usually made, and it is the one the evidence supports.

The category, which does not map at all

Product category classification is the starkest non-overlap in the whole picture. A customs nomenclature exists to assess duty and is republished every year. A retail taxonomy exists to organise a storefront and to route a product into the right filters and the right tax treatment. A producer responsibility scheme's category schedule exists to set a fee. A passport's own classification, when a product act eventually specifies one, will exist for something else again.

These are not the same hierarchy at different resolutions. They cut the world along different joints, for different purposes, maintained by different bodies on different cycles, and none of them converts into another by lookup. What that means in practice is a crosswalk per destination, and a crosswalk is permanent maintenance rather than a one off mapping: the customs nomenclature alone is reissued annually, so a stored code ages on a known cycle whether anybody notices or not.

It is also the reason a product classified once in a storefront still has to be classified again for customs, again for a producer responsibility return, and again for whatever a passport asks for. That is not duplication caused by bad tooling. It is four different questions that happen to be asked in the same grammar.

What to do instead

1. Check there is somewhere to put it. Before designing a mapping, read the destination platform's own documentation on custom data and establish whether it has a definition layer, a type, a size ceiling or none of those. On one of the four platforms described above, the answer makes the rest of the work moot.
2. Map meanings, never names. For every pair of fields you are about to connect, write down what each system does with its value. If the two answers differ, you have a translation problem rather than a copy problem.
3. Keep the strongest form of the value. Store composition as fibres and percentages, weight as the product's own mass, the party as a party. Everything weaker can be derived from the strong form, and nothing can be derived from a weak one.
4. Record who said it, and how it was obtained. A value and its origin travel together or the value arrives at its third destination with nobody standing behind it. Whether it was declared or analysed is part of the origin, not a refinement of it.
5. Expect a crosswalk per destination, and budget for maintaining it. Classification schemes move on their own schedules, and a crosswalk that is right today is a crosswalk that was right today.
6. Treat a validated feed as evidence of nothing about compliance. The feed validated the shape it wanted. It has no view on the question the law is asking.

Which copy is the true one

One question is left over, and this page will not answer it, because the honest answer is not a general one. The same attribute is routinely held in three systems at once: the catalogue, the channel feed and whatever holds the compliance record. They disagree. Nothing read for this page supplies a rule for which of the three wins, and no instrument read for this page sets a precedence order between a business's own systems.

A universal rule would be an invention, and a plausible invention would be worse than none, because somebody would follow it. What can be said is the shape of a real answer. It is specific to the systems and to who maintains each of them, it is a decision somebody takes and writes down rather than a fact anybody discovers, and what makes it work afterwards is that the decision travels with the value rather than that it was the cleverest one available. Whoever owns the systems owns that decision, and nobody outside them can take it for them.

What this page rests on, and what it does not

This is a reading of published documentation. Each specification named here is described by what it defines its attributes to hold, and nothing here is a criticism of a platform: a filter attribute doing filtering is a design working as intended, and the failure only appears when somebody carries the value across a boundary it was never built to cross.

Four limits are worth stating plainly, because they bound different parts of the page.

• The feed and taxonomy specifications were read second hand. The material, brand, certification and fabric claims came through this estate's own research pass rather than being read at the publisher by the author of this page, so their effect is described and none of their wording is quoted.
• The platform reads are dated and the platforms are not named. Platform documentation moves frequently and carries no date at source, so every platform fact carries the date it was read, and the three ceilings are described by what their documentation says because no address for those reads is registered here.
• No chain of custody model is named. The standard that governs them is behind a purchase, has not been bought and has not been read here, so the page states the gap and stops there.
• No figure appears for duplicated collection. We found no study that measured how often one business collects the same attribute twice, and a number would have to be invented.

The section on what survives downstream will age faster than anything else here, which is why its rows carry a read status and a date each. If those specifications gain an attribute this page says they lack, the right response is to change the section rather than to argue with the reader who noticed.

Sources

Four of the specifications below are platform or feed documentation rather than registered standards, and are listed here so that the claims resting on them are visible rather than implied. Platform documentation moves frequently and carries no date at source, so every platform fact on this page carries the date it was read, and the read depth on each row records how far it was actually read.

• Google Merchant Center product data specification
  Platform documentationReached through a secondary reproduction, primary text not read

  The product data specification behind a shopping feed, and the source for what the material, brand and certification attributes are defined to hold, including the certification attribute that accepts a closed list of four families. Read through this estate's research pass rather than at the publisher, so the effect of each attribute is described here and no wording is quoted from it.

  View official source

• Shopify Standard Product Taxonomy, apparel categories and their attributes
  Platform documentationReached through a secondary reproduction, primary text not read

  The published product taxonomy behind one catalogue system, and the source for the apparel category carrying a single fabric attribute. Read second hand, as above.

  View official source

• Shopify Admin API product and inventory item documentation
  Platform documentationRelevant provisions reviewed

  A market participant rather than an authority. It is here for what a catalogue record holds and what each field is used for, which is evidence of platform behaviour and never of law.

  View official source

• Shopify developer documentation on custom data, metaobjects and storage limits
  Platform documentationRelevant provisions reviewed

  The custom data documentation for the most capable of the four platforms described here: a definition layer, a type on every definition, validation against it, a limit on how many fields one structured object definition carries, and a documented storage envelope. It is the comparator that makes the other three ceilings legible. What that platform can and cannot hold is the subject of the guide to it rather than of this page.

  View official source

• Second and third platform documentation on custom product data
  Platform documentationRelevant provisions reviewed

  The custom data documentation for three further platforms, and the source for the three ceilings in the table above, including the platform that documents no custom field capability at all. No address is registered for these reads, so no platform is named on this page and each is described by what its own documentation says it can hold.

• Feed and agentic catalogue specifications, and their attribute ceilings
  Specification documentationRelevant provisions reviewed

  The agentic catalogue specifications and the search publisher's own guidance for its AI features, read for their attribute lists and for what those lists do not contain. It is the basis for the dated table in the section on what survives downstream, and it is the fastest decaying source on this page, which is why that table carries a date and a read status on every row rather than a single line at the foot.

• Regulation (EU) No 1007/2011 on textile fibre names and related labelling, consolidated text
  Annex I, Art. 5CELEX 02011R1007-20180215In forceRelevant provisions reviewed

  The closed list of fibre names and the rule that only those names may be used. It is the instrument that makes composition a value with a right answer rather than a description. Annex I and Art. 5(1) were read; nothing on this page rests on any other provision of it.

  View official source

• General Product Safety Regulation (EU) 2023/988
  Art. 19CELEX 32023R0988In forceOfficial source confirmed, detailed review pending

  The listing information articles, reached through a secondary reproduction rather than at the Official Journal because every route to the primary text stopped short of them. Its effect is described here and none of its wording is quoted.

  View official source

• Combined Nomenclature, annual amending regulation to Annex I of (EEC) 2658/87
  In forceRelevant provisions reviewed

  The customs nomenclature behind a commodity code. It is on this page as a classification that exists for a purpose entirely unlike a retail taxonomy's, which is why the two do not convert.

  View official source

• Ecodesign for Sustainable Products Regulation (EU) 2024/1781, consolidated text
  Arts. 2, 10, 12CELEX 02024R1781-20240628In forceRelevant provisions reviewed

  The framework, for the defined terms. Its identifiers for products, operators and facilities are the reason the identity layer and the party layer behave differently from everything else described here.

  View official source

• Chain of custody scheme rules, scope and transaction certificate specifications
  Scheme rulesRelevant provisions reviewed

  The published scheme rules, used here for two things: that a scope certificate runs a one year clock and states on its own face that it proves nothing about goods delivered by its holder, while the transaction certificate that does speak to goods carries no expiry field at all. The standard that governs chain of custody models themselves is behind a purchase and has not been read, so no model is named on this page.