DEV Community

Vin Lookup
Vin Lookup

Posted on

Displaying TPMS from vPIC Without Inventing Tire-Safety Claims

NHTSA vPIC often returns tire-pressure monitoring catalog fields on DecodeVinValues-style payloads -- commonly under keys such as TPMS when the pattern includes that token. Those strings are useful on a free VIN decode card. The trap is turning a single sourced field into a tire-health grade, "TPMS working," or roadside-safety claim that the catalog never asserted.

This post is about honest display: show the TPMS catalog value when vPIC provides it, refuse tire-safety inventing, and allow a clean "not provided" state when the field is empty. Keep TPMS catalog tokens separate from live sensor readings, tire tread depth, and inspection results. A sourced token is still only a token: it does not prove the system is present, calibrated, or undamaged on the listed vehicle.

What TPMS is (and is not) in vPIC

TPMS (or the equivalent tire-pressure monitoring field your decode maps) is a catalog attribute associated with the VIN pattern. It answers a narrow question: which TPMS-related token did the decode associate with this pattern?

It does not answer:

  • Whether tires currently hold safe pressure or need inflation
  • Whether sensors are installed, paired, or reporting correctly today
  • Direct vs indirect TPMS hardware details you did not source
  • Whether a dashboard light is on, off, or silenced after a wheel swap
  • A composite "tire safety score" built from missing neighboring fields

Empty TPMS does not authorize a default "Standard" badge, and a positive token does not mean "tires verified safe." Do not fill gaps from Make/Model/Year folklore or a chart keyed only by model year.

Normalize empties, do not invent health

Treat blank, "Not Applicable", "N/A", and similar tokens as missing. Keep a sourced string when present; do not rewrite it into "TPMS Healthy" or a tire-inspection grade.

const EMPTY = new Set([
  "",
  "not applicable",
  "n/a",
  "na",
  "null",
  "none",
  "unknown",
]);

export type TpmsView = {
  value: string | null;
  source: "vpic" | "missing";
};

export function viewTpms(fields: {
  TPMS?: string | null;
}): TpmsView {
  const raw = (fields.TPMS ?? "").trim();
  if (!raw || EMPTY.has(raw.toLowerCase())) {
    return { value: null, source: "missing" };
  }
  return { value: raw, source: "vpic" };
}

export function tpmsLines(view: TpmsView): string[] {
  if (view.source === "missing") {
    return ["TPMS: not provided by vPIC for this VIN"];
  }
  return [
    `TPMS (vPIC): ${view.value}`,
    "Catalog token only -- not a tire-health or sensor status claim",
  ];
}
Enter fullscreen mode Exit fullscreen mode

The footnote matters. Buyers over-read a TPMS catalog field as proof that tires are safe to drive. Show the sourced token; if blank, say "not provided" -- no greyed "Direct" and no invented "pressure OK" badge.

Forbidden upgrades

Product pressure often asks for:

  1. Mapping any non-empty TPMS into "Tire pressure monitoring working"
  2. Inventing psi readings, tread depth, or inspection grades from the catalog field
  3. Bundling TPMS with unrelated safety keys into "Full Tire Safety Package"
  4. Defaulting blank TPMS to "Standard" so mid-trim cars look complete
  5. Renaming catalog tokens into OEM sensor marketing names you did not source

Refuse those. If you show other catalog fields from separate sourced keys, show each on its own row. Never invent live tire health inside the TPMS mapper.

export function assertNoTpmsHealthInvent(moduleSource: string): void {
  const banned = [
    /tire.?health/i,
    /pressure ok/i,
    /psi verified/i,
    /tread depth/i,
    /sensors working/i,
    /full tire safety/i,
  ];
  for (const re of banned) {
    if (re.test(moduleSource)) {
      throw new Error(
        `TPMS module must not invent tire-safety claims: ${re}`,
      );
    }
  }
}

export type CardRow = { label: string; value: string };

export function cardRows(fields: {
  TPMS?: string | null;
  TirePressureMonitoringType?: string | null;
  WheelBaseType?: string | null;
}): CardRow[] {
  const view = viewTpms(fields);
  const out: CardRow[] = [];
  if (view.source === "missing") {
    out.push({ label: "TPMS", value: "not provided" });
  } else {
    out.push({ label: "TPMS", value: String(view.value) });
  }

  const kind = (fields.TirePressureMonitoringType ?? "").trim();
  if (kind && !EMPTY.has(kind.toLowerCase())) {
    out.push({
      label: "TPMS type (vPIC)",
      value: kind,
    });
  }
  const wheel = (fields.WheelBaseType ?? "").trim();
  if (wheel && !EMPTY.has(wheel.toLowerCase())) {
    out.push({ label: "Wheel base type (vPIC)", value: wheel });
  }
  return out;
}
Enter fullscreen mode Exit fullscreen mode

Keep neighboring catalog fields on their own labeled rows. Never concatenate them into "Full Tire Safety Package," and never treat a separate type key as live sensor telemetry.

UI copy that stays honest

Prefer:

  • "TPMS (vPIC): Direct"
  • "TPMS: not provided by vPIC for this VIN"
  • A short footnote: catalog token, not a tire-health or sensor status claim

Avoid:

  • "Tire pressure OK -- verified"
  • "Sensors working / full tire safety included"
  • Grey placeholders that look like real TPMS data when the field was empty

Quick checks

import assert from "node:assert/strict";

assert.equal(viewTpms({}).source, "missing");
assert.deepEqual(tpmsLines(viewTpms({})), [
  "TPMS: not provided by vPIC for this VIN",
]);

const direct = viewTpms({ TPMS: "Direct" });
assert.equal(direct.value, "Direct");
assert.ok(
  tpmsLines(direct).some((l) =>
    /not a tire-health or sensor status/i.test(l),
  ),
);
assert.ok(
  !tpmsLines(direct).some((l) =>
    /pressure ok|tread|sensors working/i.test(l),
  ),
);

const rows = cardRows({
  TPMS: "",
  TirePressureMonitoringType: "Direct",
  WheelBaseType: "Long",
});
assert.ok(
  rows.some((r) => r.label === "TPMS" && r.value === "not provided"),
);
assert.ok(rows.some((r) => r.label.includes("TPMS type")));
assert.ok(rows.some((r) => r.label.includes("Wheel base")));
assert.ok(!rows.some((r) => /pressure ok|tire health/i.test(r.value)));
Enter fullscreen mode Exit fullscreen mode

Review rule: TPMS modules must not contain tire-health or live-sensor phrases except in forbidding tests. Never upgrade a blank into "Standard" or "Direct."

Takeaway

TPMS from vPIC is a catalog token. Display it with clear sourcing, allow "not provided," and never use it as a key into invented psi readings, sensor-working claims, or "full tire safety" bundles. Your free VIN UI stays trustworthy when TPMS data is either a real vPIC value with a modest footnote -- or absent -- and tire inspection marketing lives somewhere else, clearly labeled, or not at all.

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

Top comments (0)