Choose the product identity level
Decide whether an example represents a product family, a sellable variant, a supplier listing, or an individual item. Color and size combinations may share descriptions while requiring separate identifiers. Document how bundles, discontinued products, and duplicate listings across marketplaces should be represented.
Define attribute evidence
List required attributes and distinguish observed source values from normalized categories. A material stated in a specification is different from one inferred from a photograph. Preserve units, allowed categories, and unknown values. For extraction tasks, attach the supporting description or specification passage to each expected output.
Measure coverage that matters
Request category, supplier, language, and attribute-completeness counts, including the long tail of unusual items. Inspect variation within categories rather than judging the set only by total listings. Reused supplier descriptions and variant families can make a large catalog less independent than its size suggests.
Review change and use scope
Specify whether the task needs a current snapshot or product histories with effective dates. Review permitted uses of text, images, and third-party specifications separately for the project. Send Fiund your target taxonomy, identity rules, and example records to discuss a sourcing approach that matches the intended catalog workflow. Use a product family with several size variants as a pilot case. Verify which attributes are inherited and which vary by listing. Ask reviewers to identify where each value originated. That exercise can uncover accidental duplication, attribute propagation errors, and differences between supplier claims and values inferred during dataset preparation or annotation.
Review checklist
- Define family and variant identifiers
- Separate observed and inferred attributes
- Request category and supplier coverage
- Specify snapshot or historical requirements