# Tesla OE cross-reference — published snapshot, 2026-09-01 This is the dataset behind the figures published in MapleV's field report *Beyond VIN Lookup: The Tesla Collision-Parts Cross-Reference Gap*. The live lookup at https://maplev.ca/oe-lookup changes as the catalogue changes; this file does not. It is published so the figures stay checkable. **This 2026-09-01 file supersedes the 2026-08-29 snapshot and is the one to cite.** See *Revision history* below for exactly what changed and why. **Files** | File | Contents | | --- | --- | | `tesla-oe-cross-reference-2026-09-01.csv` | One row per product grouping (282 rows + header) | | `tesla-oe-cross-reference-2026-09-01.stats.json` | The four published counts, machine-readable | | `tesla-oe-cross-reference-2026-09-01.README.md` | This file | **Published counts** | Figure | Value | | --- | --- | | Unique base numbers | 355 | | Distinct full OE numbers | 521 | | Product groupings | 282 | | Base numbers with two or more distinct full OE numbers | 135 (38.0%) | Middle-code distribution (over the same 521 deduplicated full OE numbers, full list in `stats.json`): `00` 428, `S0` 15, `E0` 12, `SC` 9, `EC` 9, and eleven further codes below that. We publish these counts without assigning meanings to the codes; we have not been able to source a definition of them to Tesla documentation. Note that counting raw occurrences instead of distinct numbers gives a much larger figure — mixing the two denominators is how an earlier version of these published statistics went wrong. ## Revision history An earlier snapshot dated 2026-08-29 was generated and linked from the working paper. Between 2026-08-29 and 2026-09-01 the build script regenerated that same filename each time it ran, so the file published under the 2026-08-29 name was not byte-stable even though its own notes described it as frozen. We are stating that plainly rather than leaving the claim standing. Three things follow from it, and all three are now fixed: 1. **The 2026-08-29 files are superseded.** They remain downloadable at their original URLs, restored to the bytes first published on that date, with a notice at the top of their README. Cite this 2026-09-01 file instead. 2. **The four published counts never changed.** 355 / 521 / 282 / 135 (38.0%) are identical in both snapshots. Everything the field report asserts still holds; no published figure is affected. 3. **Snapshots are no longer build output.** `npm run build` no longer writes any snapshot. A new one is minted deliberately with `npm run snapshot`, which writes a file dated the day it runs. A dated snapshot is now a committed artifact that nothing rewrites behind your back. Eight of the 282 rows differ between the two snapshots. All eight are catalogue corrections made in the ordinary course of maintaining the catalogue; none of them adds or removes an OE number, which is why no count moved: | Row | What changed | | --- | --- | | `P-021` Air Extractor | Fitment extended to Model 3 Highland and Model Y Juniper | | `P-247` Pedestrian Warning Speaker (25W) | Fitment extended to Model 3 Highland and Model Y | | `P-248` Pedestrian Warning Speaker (50W) | Fitment extended to Model 3 Highland and Model Y Juniper | | `P-254` / `P-255` Hood Hinge | Renamed to *Hood Hinge (Active)* to distinguish from `P-256` / `P-257` | | `P-256` / `P-257` Hood Hinge | `year_range` rewritten from an internal shorthand to `21-24 MODELY` | | `P-261` Cooling Fan and Shroud | Fitment extended to Model 3 Highland and Model Y Juniper | ## How the counts are produced Generated by `scripts/gen-oe-snapshot.mjs` in the maplev repository, from the catalogue data in `src/data/partsData.ts`. Both are private to the repository, so a third party can fully recompute the figures **from this CSV** using the rules below, but cannot independently regenerate the CSV from the original catalogue without that source. We state that limit rather than imply otherwise. The normalization rules are deliberately identical to the live lookup page (`src/pages/OeLookup.tsx`), so the published file and the public tool describe the same thing. Run `node scripts/gen-oe-snapshot.mjs 2026-09-01` against the same catalogue data to reproduce this file byte for byte. The SHA-256 of the published CSV is recorded in `stats.json` as `csv_sha256`. The rules, in order: 1. **Field extraction.** For each catalogue entry, read the `partNumber` field and the `variants` array. Split each on newline, comma and forward slash. Trim whitespace. 2. **Side-prefix strip.** A leading side marker of up to three letters followed by a colon (`L:`, `R:`, `LH:`) is removed. `L: 1084168-S0-E` becomes `1084168-S0-E`. 3. **Normalization.** Remove every character that is not a letter or digit, then uppercase. `1084168-S0-E` and `1084168S0E` both normalize to `1084168S0E` and count once. 4. **Internal SKU exclusion.** A token is treated as an internal SKU code, not an OE number, when it does **not** begin with a digit **and** matches `HARDCLIP`, `SUNS`, `CLIP`, or a leading `M3` / `MY` pattern. These are MapleV's own identifiers for sunshades and hardware clips. They are excluded from every count and never appear in `all_oes`. 5. **OE shape test.** A token qualifies only if its normalized form contains a run of seven digits, or begins with one letter followed by six digits. In this snapshot every qualifying full OE number in fact matches the tighter pattern `^[0-9]{7}[A-Z0-9]{3}$` — seven digits, then a three-character middle code and revision. If you are recomputing, use that tighter pattern: it is what the data actually contains, and unlike rule 5 it cannot diverge from rule 8's "leading seven digits" base derivation. 6. **Bare base exclusion.** A qualifying token whose normalized form is shorter than nine characters is a bare base reference, not a full OE number. It is excluded from the 521 count and from `all_oes`. It also does **not** by itself create an entry in the 355 denominator. 7. **Display form.** Where the same normalized number appears in both separated and unseparated form, the separated form is kept for display. 8. **Base number.** The leading seven digits of a normalized full OE number, where those seven characters are all digits. 9. **Deduplication.** `full OE numbers` and `base numbers` are deduplicated **globally across the whole catalogue**, not per row. The same OE number appearing under two groupings counts once. 10. **Multi-variant test.** A base number is multi-variant when two or more distinct normalized full OE numbers share it — again computed globally. **Definition of an occurrence.** Where these notes contrast *distinct* counts with *occurrences*, an occurrence means one raw token after splitting a row's `all_oes` on ` | `. The published counts are all distinct-value counts. ## Reading the CSV | Column | Meaning | | --- | --- | | `grouping_id` | MapleV internal identifier for the product grouping | | `name_en` | Product name | | `category` | MapleV category | | `models` | Vehicle models the grouping covers | | `year_range` | Model-year range **as recorded in the catalogue** — see note below | | `side` | Left / right where applicable; empty for non-sided parts | | `primary_oe` | The OE number MapleV lists first for the grouping | | `primary_base_number` | Base of `primary_oe` only | | `all_oes` | Every qualifying full OE number for the grouping, ` \| `-separated | **`year_range` is a free-text field, not a normalized one.** It is reproduced exactly as the catalogue records it, and the catalogue uses more than thirty different spellings across these 282 rows (`21-24 MODELY`, `21-24MODELY`, `MODEL3/Y (all years)`, and so on). Do not parse it programmatically and do not treat it as a controlled vocabulary. **None of the four published counts depends on this column** — they are computed entirely from `all_oes`. We publish the field as-is rather than silently tidying it, so that what you see is what the catalogue actually holds. **Important:** `primary_base_number` is the base of the primary OE only. The 355 base numbers are recomputed from **every** OE in `all_oes` across all rows, not from this column. A single grouping can legitimately span several different base numbers — a front fascia grouping, for example, carries `1084168`, `1916697`, `1519965` and `1916699`. This is why 282 rows yield 355 base numbers. ## What this data does and does not establish It shows that multiple distinct full OE numbers exist under one base number. It does **not** establish that every such set forms a linear supersession chain, that the variants physically interchange, or how Tesla's VIN-driven catalogue logic resolves any specific case. Those are questions Tesla's EPC answers per vehicle; this dataset does not. Product groupings are an analytical grouping for reporting. They do not correspond exactly to storefront listings — the MapleV catalogue lists 287 parts, while 282 groupings carry at least one qualifying full OE number. Base numbers, not groupings, are the primary denominator for every published percentage. ## Corrections This snapshot is fixed at the date in its filename and is not edited in place. The build no longer writes snapshots, and an automated check fails if the published bytes stop matching the SHA-256 recorded in `stats.json`. If you find an error, write to grant@maplev.ca. Corrections are applied to the live lookup and, where material, published as a new dated snapshot with its changes listed in a revision-history section like the one above — not by editing a file that has already been cited. MapleV is an independent supplier and is not affiliated with, endorsed by, or authorized by Tesla, Inc. Tesla OE numbers are used for identification and cross-reference only.