ACES and PIES is a relatively new thing. The Autocare aftermarket standards have probably helped the industry immensely, at the low-low cost of some developer sanity. Before this, Automotive fitment (matching a vehicle to a product) was all tribal knowledge and some hoarded spreadsheets, implemented a dozen different ways or more commonly not at all - just a dirt-simple catalogue page for a manufacturer's products. Nowadays, if you don't have a year-make-model selector tool, you're a bit behind the curve.
But the truly interesting bit is that for a lot of folks, (read: billion-dollar businesses and the poor sods that have to use their data) even that isn't enough. Even a well-regarded framework, with thousands of members and constant contribution isn't going to entirely cover their needs. They need to go deeper. Alright, slap on one extra layer and use the submodel, then. Surely that would cover just about everything? No, you actually need to go deeper still. For something as complicated as a Wheel, which fits on alot, and I truly mean a lot of different vehicles, You need more robust Vehicle Applications, Qualifiers, and Notes - other pieces of criteria that expand the amount of total "vehicles" possible. A 2026 Ford F-150 Lariat has a 4WD and a RWD option, along with two different bed lengths available and some other configurations.
Let's say you have a wheel that only fits on the 4WD version with a lower bed length. Perhaps the brake calipers are different (they are not) and the load rating changes significantly with the bed length (it doesn't). Well, In an ACES file, if you wanted to specifically call out the application for this vehicle with 4WD and the short bed, this would be Base Vehicle ID 184362, with Bed Option 87 and Drive Type Option 8. It'd look something like this:
<App action="A" id="1">
<BaseVehicle id="184362" /> <!-- 2026 Ford F-150 -->
<SubModel id="696" /> <!-- Lariat -->
<BedLength id="87" /> <!-- Fleetside 170.4-->
<DriveType id="8" /> <!-- 4WD -->
<Qty>4</Qty> <!-- Square Fitment -->
<PartType id="7644" /> <!-- Wheel -->
<Part>12345</Part>
</App>Okay great, clearly this is something that Autocare can cover A-OK. It's fully reversible, we can tell that this is a 100% valid configuration for the Lariat because all of our IDs match up. If I'd searched my VCdb and checked, I would find that there's exactly one vehicle configuration that comes back, and it's exactly what we have listed.
But we've got problems that only start ramping up when you need to get even more specific. Autocare provides about 257,000 unique vehicle identifiers at the submodel level (Vehicle ID), but when you start to include things like 4WD versus RWD affecting vehicle fitment, additional brake and suspension packages, and body styles? That number of total vehicles damned-near breeds. It's too much for Autocare to actually reasonably store and know about.
Even if Autocare says "Yeah there are 3 configs for that Lariat", the naive answer is that there would be 3 options for the customer to select. Wrong. There are a great, great many options for a customer to select, but zero options that they actually care about. Because the 4WD and RWD options don't actually matter for Wheel Fitment - both options share the same brake caliper - You don't actually need to go deeper than Submodel. In short, if you know the customer is looking for a wheel, you don't need to let them choose anything except the submodel.
But there are 2 options for Suspension - without Ride Height Sensor
and Ride Height Sensor.
Those are qualifiers. They're completely outside of the typical ID-based fitment Autocare provides, and wouldn't you know it, Autocare doesn't list any of the available configs as having something special like a ride height sensor. That data is simply unknowable from the list of vehicle options they provide. That info is given to me straight by the manufacturer of the suspension, who knows that there are configurations available for that F-150 which either have that sensor or don't. The ACES file would instead look something like this for a suspension part:
<App action="A" id="1">
<BaseVehicle id="184362" /> <!-- 2026 Ford F-150 -->
<SubModel id="696" /> <!-- Lariat -->
<Qual id="19001"></Qual> <!-- Without Ride Height Sensor -->
<PartType id="19360" /> <!-- Suspension Leaf Spring Block Kit -->
<Part>678910</Part>
</App>At first glance, this looks great. Autocare clearly covers this one too, right? Not really. A Qualifier is a predefined bit of text that describes the fitment. A Note is even worse - it's an open text field that basically just says "deal with it." You can slap a qualifier or a note on any application. Could these be one of the three configurations Autocare seems to think exist? Yeah absolutely. Which ones? Hell if I know. Hell if they know either. We're 100% reliant on the data providers in this case. I provided this data and I don't even know which it corresponds to. That's an engineer-level problem where your guy designing the suspension needs to know exactly which F-150 configurations are applicable, grab the Autocare values for the 'Valid Body Configs' and match them up with your research, and make sure that gets cleanly communicated down the entire product cycle chain. If it sounds tedious and somewhat impossible across however many vehicles your product covers, that's because it definitely is.
So this means the Dev, the unfortunate fellow, regardless of if he's on the sender's side or the reciever's side, must now create an entirely separate knowledgebase to contain what vehicles require what available qualifiers, and what product types those qualifiers are relevant for. If you can't, you damned well better make sure this caveat for fitment is clearly communicated to the customer. The consequence for failing to do this is to just eat a return. If it's a popular vehicle, be prepared to eat many returns.
Our standard loop turns into this: Salesmen will sell a product, run into a problem with a specific package rendering it incompatible, and then the Data Guys get to adjust the list to make sure that vehicle gets considered for next time for that product type. If you know the data is relevant for an entire Chassis across multiple years (more data Autocare skips on), then this assignment becomes easier over time. There is no easy list, no standardized framework that will tell you every modification that a manufacturer provides for a vehicle. Just a lot of salesmen that know a lot about cars, and a lot of data that gets tossed around and modified daily.
So there you go, that's the summary of my problem with Autocare and why vehicle fitment is still not an exact science, despite having a lot of rather precise measurements available from manufacturers for products and vehicles alike. Unfortunately I don't have a clean solution for you, solving this debacle is an excercise left to the reader. I can just about guarantee that your business will handle it differently than mine did, at the least. If you find yourself responsible for designing the database that holds all of your vehicle data (think bolt pattern, thread pitch, OE Tire Size, etc.), the only recommendation I have is to keep an open mind for making individual records easy to modify by trusted users and allowing additional assignments from chassis-to-vehicleIds to better organize vehicle data. Maybe also a list of chassis-to-qualifiers-through-productType.