ACES Over-Mapping Fitment that is right, and still too much.

An over-mapped application is not wrong. It fits the vehicles it claims and it passes validation. It simply says more than it needs to, and across a whole catalog that extra detail turns into thousands of lines nobody needed and invalid records that never had to happen.

Over-mapping, defined

In the Aftermarket Catalog Exchange Standard (ACES), each application record states which vehicles a part fits [1]. Auto Care requires four elements in every application: a base vehicle (year, make and model), a part type, a quantity and a part number [2]. Anything mapped beyond those four should be there for one reason only: to qualify the part unambiguously.

Over-mapping is mapping attributes the part does not need. The application is still accurate and still valid; it just carries detail that narrows nothing. Amazon's guide to providing ACES data puts it plainly: "Don't over-map." It asks for only the fitment information needed to fit the product to the vehicle [3].

Over-mapping is a different problem from an application that claims vehicles the part does not fit, such as a diesel-only part mapped to a base vehicle with no engine. That is inaccurate fitment, covered in ACES notes vs attributes.

Two accurate ways to map one fit

The same fit can often be mapped more than one accurate way. Take a part that fits only the diesel versions of a vehicle offered with two diesel engines, each of which runs only on diesel. It can be mapped with one application per diesel engine, or with a single application that names the fuel type and no engine. Both claim exactly the same vehicles. One file has two applications and the other has one, and neither is wrong.

Over-mapping happens when the two methods are stacked: each engine-mapped application also carries the fuel type. The diesel engine already implies diesel, so the fuel type adds a line to every application and qualifies nothing.

✓ Accurate - one application per diesel engine
<App action="A" id="1">
  <BaseVehicle id="…"/>
  <EngineBase id="…"/>      first diesel engine
  <Qty>1</Qty>
  <PartType id="…"/>
  <Part>EX-3003</Part>
</App>
  (a second application for the second diesel engine)

✓ Accurate - one application, fuel type only
<App action="A" id="1">
  <BaseVehicle id="…"/>
  <FuelType id="…"/>        diesel
  <Qty>1</Qty>
  <PartType id="…"/>
  <Part>EX-3003</Part>
</App>

⚠ Over-mapped - accurate and valid, but the fuel
  type is already implied by the diesel engine
<App action="A" id="1">
  <BaseVehicle id="…"/>
  <EngineBase id="…"/>      first diesel engine
  <FuelType id="…"/>        diesel (adds nothing)
  <Qty>1</Qty>
  <PartType id="…"/>
  <Part>EX-3003</Part>
</App>
  (a second application for the second diesel engine,
  also carrying the fuel type)

Why extra attributes cost

Bloat. One unneeded attribute is one line. Repeated on every application of every part in a catalog, it becomes many thousands of lines of data that has to be built, sent, loaded and reviewed, and that tells no one anything new.

Invalid records that never had to happen. The reference databases behind ACES are not fixed. Auto Care publishes Vehicle Configuration Database (VCdb) updates monthly as downloads and daily through its API [4], and its release notes announce deletions and changes to existing data [5]. Every attribute on an application has to remain valid in combination with the base vehicle and with every other attribute on it. Each extra attribute is one more combination a VCdb change can break.

When a change touches an attribute the part never needed, the over-mapped application can become invalid while the leaner version of the same fit would have stayed valid. The record that was accurate yesterday is now a record a receiver rejects, and someone has to find and fix it. Those rejections are covered in ACES file rejections.

• Larger files with no extra coverage
• More applications to review on every catalog change
• Avoidable invalids after VCdb updates
• Time spent fixing records that were never wrong about the fit

Keeping fitment lean

Lean fitment is not vague fitment. Leaving out an attribute the fit depends on claims vehicles the part does not fit, which is a far bigger problem than over-mapping. The aim is the narrowest accurate claim with the fewest attributes:

• Start from the four required elements and add only what the fit depends on.
• Skip what is implied. If one mapped attribute already settles another, map one of them, not both.
• Pick one method per fit. By engine or by fuel type, for example, but not both on the same application.
• Do not judge fitment by the number of applications. Two files can claim identical vehicles with different application counts; compare the vehicle configurations they claim.
• Re-check the catalog after VCdb updates, so any application a change has made invalid is found before a receiver finds it.

When a receiver requires the extra detail. Some receivers' systems cannot accept an empty field, so every application they load must carry, for example, an engine. For that receiver, over-mapping becomes a deliberate choice. It belongs in the file prepared for that one receiver, not in the master catalog, so every other trading partner still gets the lean version. The expansion also has to respect everything the application already maps. An application limited to one submodel and drive type should expand only to the engines offered with that submodel and drive. Expanding from the base vehicle alone adds engine combinations that were never built, and turns one accurate record into several invalid ones.

Where over-mapping does the most damage. A brand that over-maps its own data usually still sends valid fitment, just more of it than needed. The bigger risk sits downstream. A repository that receives a brand's file and over-maps the entire catalog to suit its own receivers can expand records from the base vehicle alone. That creates invalid configurations the brand never sent, cannot see, and cannot correct at the source.

Checks worth asking for

Over-mapping passes validation, so most processes never see it. These questions show whether a tool or service can:

1. Does it flag attributes that another mapped attribute already implies?
2. Can it compare two versions of a catalog by the vehicle configurations they claim, rather than by counting applications?
3. After each VCdb update, does it re-check every application and explain which ones the change made invalid, and why?
4. Can it show the leaner, equivalent mapping for an application, without changing the vehicles it claims?
5. When a receiver requires fields that cannot be empty, can the export fill them for that receiver only, expanding against the whole mapped configuration rather than the base vehicle alone?
6. Does it ever add attributes on its own? Anything a tool adds should be visible and explained.