Short answer
Automotive aftermarket catalogs follow two industry data standards: ACES for vehicle fitment and PIES for product attributes, descriptions, images and packaging. Together they link a part's appearance to the vehicles it fits. That supports parts recognition and fitment grounding, but supplier images are mostly packshots, and fitment tables depend on subscription reference databases.
Why this catalog type is worth its own page
Most product catalogs are free-form: each seller invents its own fields. The automotive aftermarket is unusual because the industry agreed on exchange formats. The Auto Care Association describes ACES as the aftermarket data standard for managing and communicating product fitment data for light, medium and heavy duty vehicles, powersports, and off-highway and equipment, and PIES as the standard for product information covering attributes, descriptions, images and packaging. Both are machine-readable XML (Auto Care Association).
That structure matters to a perception buyer for two reasons. First, labels come ready-made: a brake rotor image arrives with a part type, brand, attributes and a list of vehicles it fits. Second, the scale is large and consistent, so one parsing pipeline can handle records from many suppliers. A buyer working on repair, parts counter or workshop tasks can use this to ground recognition in the vocabulary of the trade.
What the two standards carry
| Standard | Carries | Perception use |
|---|---|---|
| ACES | Which part fits which vehicle (year, make, model, engine and other qualifiers), plus notes | Links part appearance to vehicle context; grounding "the filter for this engine" |
| PIES | Item attributes, descriptions, digital asset references, packaging data | Labels, text and image pairs, package dimensions |
| Reference databases | Controlled lists for vehicles, qualifiers, part types, attributes and brands | Normalizing category and fitment values |
The reference databases named by the Auto Care Association are VCdb, Qdb, PCdb, PAdb and the Brand Table, and they are subscription resources. A fitment file is therefore a set of codes that only resolve into readable vehicle and part descriptions with the matching reference data. Ask who holds the subscription, whether you may receive the resolved values, and whether the license to use the reference data extends to AI training; this is a separate agreement from the catalog owner's.
Versions change. ACES 5.0 and PIES 8.0 were released on 2 April 2026 after a year of industry review, and PIES 8.0 adds Extended Producer Responsibility packaging data and digital asset file hashing (Auto Care Association). Records may sit in older versions, so request the version identifier with each file. The file hashing is helpful for deduplication when assets carry it.
What this data can support, and what it cannot
It can support:
- Part-type and brand recognition from product imagery, using PIES attributes and reference-database part types as labels.
- Fitment-aware retrieval, where a query includes a vehicle and the system returns candidate parts.
- Attribute grounding: dimensions, materials, position (front or rear, left or right) and quantity per vehicle.
- Language grounding with descriptions written in the trade's vocabulary.
It cannot support:
- In-situ recognition. Parts under a car are dirty, installed, partly hidden and often worn. Catalog packshots show new parts in clean light. See packshot vs in-situ images.
- Handling or installation. Torque, clearances and removal sequences are repair-procedure content, not catalog content. That belongs with work order histories and service documentation.
- Pose and grasp labels. No orientation or model is included unless the supplier holds CAD; see manufacturer 3D models and CAD.
- Condition. New-part imagery does not teach wear, corrosion or damage recognition, which come from inspection and teardown images.
Data problems specific to this domain
Fitment is combinatorial: the same part appears against many vehicle rows, so record counts overstate the number of distinct parts. The same physical part can be sold under several brand and part numbers, and look identical across them. Different parts for left and right sides can look like mirror images. Interchange relationships exist in industry data but may not be in the file you receive. Images are often reused across a family of parts with different dimensions. Supersession (old numbers replaced by new) means a part may vanish from the current file while still being on shelves.
For any recognition task, define what counts as the same class: the part number, the part type, or the functional equivalent. That choice drives splits. A hold-out by part number alone leaks if equivalent parts from another brand look identical, so hold out by part type or by brand family as well. See instance vs category recognition.
Illustrative sample request
The sample below is Illustrative; names and counts are synthetic.
# Illustrative automotive catalog sample - synthetic values
scope: brake, filtration, ignition part types; 5 brands
files:
pies: items.xml (version recorded)
aces: fitment.xml (version recorded)
reference: resolved values for part type, position, vehicle, brand (license stated)
assets:
images: original resolution, all views; origin tag per image; hash recorded
drawings: optional; origin tag
checks_you_run:
- share of items with >= 2 images
- duplicate image hashes across different part numbers
- mirror-image pairs (left/right) present and labeled
- items superseded or discontinued: flagged
- attribute completeness by part type
rights:
images: manufacturer-supplied | distributor-created | third-party
fitment_and_reference: license separate from item data
Rights and provenance
Rights are the main risk. PIES asset links usually point to images supplied by the manufacturer, which a distributor may display but not own. Fitment data is often compiled by the brand, and the reference databases are licensed products. Ask which rights each party holds and what the license to a downstream buyer allows. Do not assume that having the file means having the right to train on it. See product image rights, and the broader licensing questions in licensing terms for robotics training data. This is not legal advice.
Matching the catalog to the robot's task
Fitment data matters most for tasks that begin with a vehicle: a parts counter lookup, a service bay that fetches the right filter for a given engine. For tasks that begin with a bin of parts, the visual labels matter more than fitment. State which of these your robot does. If it is the first, the vehicle-to-part links in ACES are the valuable part; if it is the second, you may need only the PIES attributes and images, which can simplify licensing because the reference-database terms apply mainly to fitment resolution.
Limitations and extra preparation
Expect to resolve codes, deduplicate, and map to a taxonomy (product taxonomies). Add in-situ images from workshops or teardown photography if the robot will work on vehicles, and consider whether other industrial catalogs complement the range (industrial distributor catalogs). Write down what you received, in the manner of datasheets for datasets, including the standard versions.
Evaluating a sample
Pick ten parts you know well and trace each from the PIES record through its images to the ACES fitment rows. Check that the part type matches what you expect, that left and right variants are distinguishable, and that the images show the right side of the part. Then count how many distinct images the ten parts have in total. Duplicate use of one picture across a family is common, and discovering it in a sample is far cheaper than after a full delivery.
Questions to ask suppliers
- Which ACES and PIES versions are the files in, and are older versions mixed in?
- Do you hold a reference-database subscription, and may resolved values be shared for AI training?
- Which images are manufacturer-supplied, and what rights do you hold to sublicense them?
- How many distinct physical parts, not rows, are in the file?
- How are interchange and supersession recorded?
- Do images include installed or worn views, or only new-part packshots?
- Are digital asset hashes present so duplicates can be found?
- Can pricing, cost and customer-specific data be removed from the files?
Discuss your requirements
If you can name the part types and the labels you need, describe the automotive parts requirement to SourceX. SourceX reviews the requirement and follows up about potential sources among US businesses; the supplier's licensing permissions, including any reference-data terms, are checked as part of that review. A request does not guarantee a match. See the humanoid training data guide and the object data hub.
Explore sourcing and licensing options with SourceX
Sources
- Auto Care Association ACES and PIES standards — scope, format, reference databases and current versions of the two aftermarket standards.
- Datasheets for Datasets — documenting composition and recommended uses.