Product records
Product catalogue data for AI licensing
A product catalogue needs an explanation of products, variants and changing offers before its records can be assessed. Start with that structure, not the number of rows in an export.
Last checked
Separate product identity from a supplier listing, a variant and an offer. Record where descriptions and images came from before discussing reuse.
What does one catalogue row mean?
Ask whether a row represents a product family, an individual variant, a pack size or a particular supplier's listing. Those are not interchangeable counts. A catalogue with repeated listings of the same item should not be described as containing that many distinct products.
Schema.org's ProductGroup documentation distinguishes a group from products that vary along specified dimensions, such as size or material. It includes relationships between a group and its variants. This is a useful vocabulary example, not an instruction to rebuild your catalogue or evidence of buyer demand.
Our suggested starting point is an internal relationship sketch. Mark the family, variant, listing and offer levels that actually exist. If the system has no stable way to connect them, record the gap rather than inventing a grouping for the enquiry.
Check the meaning behind the attributes
Choose a broad product category and ask a colleague to explain its attributes without relying on the storefront. Does a dimension describe the product, its packaging or the space it fits? Does weight mean a unit or a case? Are units explicit, inferred from category or mixed across suppliers?
List missing, unknown and not-applicable values separately where the source permits it. Do not fill blanks with plausible values simply to make a catalogue more complete. Keep supplier-provided attributes distinct from values your team measured or inferred.
An invented example is a fictional catalogue where a width field describes the item in one category and the packaging in another. The useful action is to document the difference and its scope. Renaming both fields width_mm would not resolve the underlying meaning.
Describe categories and product relationships
Record which category system is used and whether it has changed. Explain whether an item can belong to several categories, whether categories are assigned manually and whether old category assignments survive. A current browse menu is not necessarily a history of how products were classified.
Keep relationship types separate. A variant, compatible accessory, replacement part and suggested alternative each express a different claim. Ask what evidence supports each relationship and whether it was supplied, checked or generated automatically. Do not present a marketing recommendation as verified technical compatibility.
Possible discussion topics include attribute extraction, category assignment or matching duplicate listings. These are illustrative technical tasks only. Establish whether a relevant requirement exists before paying for relabelling or attempting to enrich the whole archive.
Separate product history from current offers
Ask whether historical descriptions, specifications and category changes are retained or overwritten. Identify the date represented by a snapshot. A recent export of an old product record does not prove that its specifications were checked recently.
An internal scope note should distinguish:
- Stable product or variant identifiers and any known reuse of identifiers.
- Product attributes from seller-specific stock and offer fields.
- Current records from discontinued items retained for history.
- Human-written text from imported or generated descriptions.
- Original images from resized copies and alternative views.
Do not add confidential prices, supplier terms, customer orders or transaction histories to a catalogue enquiry. Those would change the proposed collection. For delivery options, the existing one-off dataset or feed guide covers the difference without assuming that an ongoing supply is feasible.
Check origins before discussing external use
Make an internal source list for product descriptions, photographs, specifications and category mappings. Record whether each was created by your team, supplied by a manufacturer, licensed from a service or obtained elsewhere. Ask the appropriate adviser to review the relevant terms and evidence before promising reuse. Public visibility is not a rights assessment.
Use the provenance record guide to keep those questions traceable. If rights are unclear for part of the catalogue, describe that uncertainty rather than representing the whole collection as available for licensing. Do not scrape another catalogue to fill gaps for an enquiry.
A safe first outline can cover broad product categories, approximate distinct-product and variant counts, years held, available attributes, history and known exclusions. Fairlode begins with descriptions only, not catalogue exports, product images or account access. A well-organised catalogue still needs an appropriate use, suitable permissions and a separate commercial discussion.
General information, not legal advice, a valuation or a buyer offer. Illustrative examples are not customer case studies.
Sources and further reading
Sources checked 4 November 2026. Historical research is background, not evidence of current buyer demand.