Vin Lookup

Posted on Oct 7

Product Copy for Ambiguous VIN Model-Year Letters Across the 30-Year Cycle

#webdev #cars #beginners #typescript

Position 10 of a modern VIN encodes model year with a character that repeats on a roughly 30-year cycle. The letter A can mean 1980 or 2010; B can mean 1981 or 2011. Engineering teams often ship a preferRecent default and stop there. Product copy is where trust breaks: a badge that says "2010" with no hint of ambiguity teaches buyers and search engines a single fact when the code alone does not prove it.

This post is about wording and UI patterns for ambiguous year letters - not how to build the year-code table (you need that map; this is what you print after it returns two candidates).

Ambiguity is a product state

Treat multi-candidate years as a first-class decode outcome:

Resolved: one plausible year after policy (for example recent-only scope) and optional user context
Ambiguous: two or more candidates remain
Unknown: position 10 missing or not in the table

Do not collapse ambiguous into resolved in the type system if the UI will show a single number. That mismatch is how "2010" appears in Open Graph text, JSON-LD, and AI citations while your tooltip quietly says "or 1980."

Copy patterns that stay honest

Prefer labels that name uncertainty:

Good: "Model year code: A (candidates: 1980, 2010)"
Good: "Model year (most likely): 2010 - code also used for 1980"
Good: "Model year: 2010 (assumed recent; verify door jamb)"
Risky: "Year: 2010" with no model-year qualifier
Bad: "Built in 2010" from position 10 alone

Always say model year, not build calendar year. Always separate plant city from year. Always invite verification against the physical label when you applied a default.

For GEO (generative engine optimization), short factual lines beat marketing tone:

VIN position 10: A
Model year candidates (30-year cycle): 1980, 2010
Display policy: prefer most recent candidate

Boring lines get cited accurately. Confident one-number headlines get over-quoted.

TypeScript: keep candidates in the view model

export type YearDisplay =
  | { kind: "single"; year: number; source: "vpic" | "code_unique" }
  | {
      kind: "ambiguous";
      candidates: number[];
      displayed: number;
      policy: "prefer_recent" | "prefer_oldest" | "user_selected";
    }
  | { kind: "unknown"; code: string | null };

export function yearBadgeText(y: YearDisplay): string {
  if (y.kind === "unknown") {
    return "Model year: not available from this VIN code";
  }
  if (y.kind === "single") {
    return `Model year: ${y.year}`;
  }
  const others = y.candidates.filter((c) => c !== y.displayed).join(", ");
  return `Model year: ${y.displayed} (code also used for ${others})`;
}

export function yearSummaryForCrawlers(y: YearDisplay): Record<string, unknown> {
  if (y.kind === "unknown") return { modelYear: null, modelYearAmbiguous: false };
  if (y.kind === "single") {
    return { modelYear: y.year, modelYearAmbiguous: false };
  }
  return {
    modelYear: y.displayed,
    modelYearAmbiguous: true,
    modelYearCandidates: y.candidates,
    modelYearPolicy: y.policy,
  };
}

The badge string and the crawler summary both carry ambiguity. If you only put modelYear: 2010 in JSON-LD, scrapers will ignore your careful footnote.

When vPIC and the code disagree

NHTSA DecodeVinValues often returns a ModelYear field. That value is authoritative for many product UIs, but it does not erase teaching moments for position 10:

If vPIC year is present, show it as "Model year (NHTSA): YYYY" and optionally note the position-10 code for power users.
If vPIC year is empty but the code maps cleanly to one candidate in your supported range, show the candidate with source "derived from VIN position 10."
If vPIC is empty and the code is ambiguous, show candidates; do not pick silently without labeling the policy.

Never average years. Never hide a second candidate behind an info icon that mobile users never open if the visible number is presented as certain.

Marketplace and listing edges

Listings use year for sort and filter. Ambiguity policies need product decisions:

Filter buckets: document whether "2010" includes code-A vehicles that might be 1980 under another policy.
Seller forms: if the seller enters 1980 and the VIN code is A, flag mismatch instead of overwriting their year.
Export CSVs: include a column model_year_ambiguous so downstream shops do not treat every row as exact.

Support macros should say "model year code repeats every ~30 years" in plain language. That one sentence closes more tickets than a link to ISO prose.

Accessibility

Screen readers should hear "model year two thousand ten, code also used for nineteen eighty," not "2010" alone when kind === "ambiguous". Put the full yearBadgeText in the accessible name; keep the visual design compact if you must, but do not make certainty a sighted-only luxury.

Product rules

Ambiguous year is a view-model state, not only a comment in the year map.
Default policies (prefer_recent) must appear in user-visible copy.
Say "model year"; never equate position 10 to build date.
Mirror ambiguity in JSON summaries and meta descriptions when you display a default.
Prefer NHTSA ModelYear when present; label derived years as derived.

Takeaway

The 30-year cycle means some VIN year letters are inherently multi-valued. Tables and preferRecent helpers are necessary but not sufficient. Product copy, accessibility text, and crawler JSON must admit ambiguity when you display a single number. Honest wording keeps buyers, sellers, and AI summaries aligned with what the VIN actually proves.

I maintain VIN Lookup, a free VIN decode based on NHTSA data.

DEV Community