Why does the same car have a different ID at every data provider?

The same car has a different ID at every data provider because every provider built its own vehicle catalog with its own keys, and the industry never agreed on a shared identifier. Chrome, KBB, Edmunds, EVOX, vPIC, and the rest each cataloged the vehicle fleet independently — so the same physical car carries a different vehicle ID, a different trim string, a different style code, and different color and option codes at each one. There was never a common spine underneath them. Vindex is the reconciliation layer built after the fact: it lands every provider's identifier on one YMMTS spine — year, make, model, trim, style — and cross-maps the codes between providers, with coverage stated per pair.

The fracture is historical, not accidental

This isn't sloppiness at any one provider; it's the shape of how the industry's data grew up. Each catalog was built to serve its own purpose — a valuation book to price cars, a merchandising catalog to describe them for sale, a government feed to decode the VIN, an imagery library to key photos. Each needed a way to name a vehicle, and each minted its own. None of them was designed to join to the others, because at the time there was nothing to join to. The result is a fleet of catalogs that all describe the same cars and share no key.

So the same trim can be a style at one provider, a vehicle at another, and a pattern at a third — three names, three grains, three keys, one car. A provider that splits a trim into two option-driven styles disagrees, at the identifier level, with a provider that keeps it as one. Neither is wrong inside its own catalog. They simply can't be joined by their labels, because the labels were never coordinated.

The VIN doesn't fix it

The natural reflex is: isn't the VIN the shared key? It isn't — not at the grain the industry needs. The VIN decodes to a pattern, and a pattern can end above trim. Two cars with meaningfully different builds — different trims, different options that move value and specification — can share the same VIN pattern. So the VIN gets you to the vehicle's neighborhood, but it doesn't always land you on the exact trim and style each provider keyed its data to. That gap between the pattern and the trim is precisely where hand-reconciliation goes wrong, and where each provider's private key fills the vacuum differently.

Where the pattern ceiling holds, Vindex doesn't pretend to a precision it lacks — it enumerates the candidate styles and scores them, shown rather than picked.

What the fragmentation costs you

Every unjoined feed is reconciled by hand, or it's wrong. The failure modes are specific:

• a mismatched trim priced against the wrong style's valuation row,
• options silently dropped when they cross a provider boundary that doesn't carry them,
• a build quoted from another car's code because two similar patterns got string-matched together,
• a listing's style bound to the wrong imagery key, so the photos show a different car than the one for sale.

Teams paper over this with string-matching on trim names and hand-kept lookup tables. Those tables are brittle, they go stale every model year, and they scale badly: reconciling n providers by direct pairing means maintaining n·(n−1)/2 separate crosswalks.

The spine is the reconciliation layer

Vindex answers the fragmentation with a hub. There is one YMMTS spine — the year/make/model/trim/style hierarchy every provider's catalog is really describing — and each provider's identifiers map onto it: vehicle IDs as sameAs edges, trim and style codes, color codes, and option and package equivalences, pair by pair. Map each provider to the spine once and every provider pair resolves through the spine — n edges instead of a mesh you can't keep current.

Providers still home their own identifiers; Vindex serves the resolution between them. A mapping posts only once it's verified, with its timestamp and a confidence number on the edge. And the coverage is reported, not asserted: the manifest renders per provider pair, per model year, showing the mapped styles, the confidence distribution, and the last-verified date. A pair without a bound mapping shows as a gap — a stated absence, never a claim.

What reads free, and what clears through the catalog

Reading the spine, the mapping structure, and the coverage manifest costs nothing — $0, no account. Understanding why the IDs differ and how they reconcile is the free face. Per-resolution answers, the pair table, and full-map licensing clear through the catalog at data.vin, which states the license and the price; a number is stated or it's absent, never invented. Provider names are stated nominatively — each mark belongs to its owner, and Vindex maps between catalogs rather than republishing them.

Where to go next

• vindex.vin — resolve a VIN and see every provider's identifier for it on one spine.
• data.vin — the pillar door: the crosswalk cataloged with its coverage, license, and price.
• build.vin — the as-built option codes the crosswalk maps, as the factory ordered them.