Recall Radar
Inspiration
Turning individual vehicle reports into collective, verifiable consumer understanding.
Every car has a price. Every car has a mileage. But what tells you the story behind its reported problems? Imagine you're buying a used car.
Within seconds, you can compare its price, mileage, features, and specifications. You might even review its vehicle history. Everything seems straightforward.
But what if hundreds of other drivers have reported problems involving the same vehicle model?Were these isolated experiences? Did similar complaints increase over time? Did federal regulators eventually investigate the issue? And most importantly, how could you find the original evidence without spending hours searching through government databases?
The National Highway Traffic Safety Administration (NHTSA) publishes complaints, investigations, and recalls. Yet these records remain scattered, technical, and difficult for everyday consumers to interpret. The problem isn't a lack of information. It's the distance between available information and understandable information. A driver might report an engine stalling. Another might describe a sudden loss of power while driving. Thousands of reports may exist, but understanding how similar complaints relate to one another and whether their reporting patterns changed over time-requires substantial effort. So we asked : What if individual vehicle complaints could become a collective source of knowledge, while preserving the evidence behind every finding?
That question became Recall Radar.
We wanted to bridge the gap between government data and everyday decision-making by creating a platform where consumers, researchers, and automotive organizations can understand complaint-reporting patterns without needing specialized data-analysis skills. Our goal is not to tell people what to buy or declare a vehicle safe or unsafe. Our goal is to make public automotive information accessible, contextual, and verifiable so people can make better-informed decisions themselves.
What It Does
Recall Radar is an interactive, evidence-first automotive intelligence and decision-support platform that transforms fragmented public vehicle records into collective, understandable, and verifiable insights.
By combining historical analytics, statistical detection, AI-assisted explanations, and conversational tools, Recall Radar connects individual vehicle complaints to broader reporting patterns, empowering buyers, vehicle owners, researchers, automotive businesses, and communities to make better-informed decisions.
1. Vehicle Explorer - Understanding the Bigger Picture
Users begin by selecting a vehicle's make, model, and year.
Recall Radar brings together historical NHTSA complaints, investigations, and related vehicle information, allowing users to explore:
- Complaint Trends: Month-by-month reporting volumes and how they changed over time.
- Component Analysis: Which vehicle systems, such as brakes, steering, or power trains, appear in reported complaints.
- Statistical Alerts: When particular complaint groups experienced unusually rapid growth.
- Regulatory Timeline: Whether NHTSA subsequently opened related investigations.
- Source Verification: Original government records supporting every displayed finding.
Each issue page compares observed complaints against an expected statistical baseline, explains the alert score in everyday language, and displays redacted complaint excerpts with direct links to NHTSA records.
The goal isn't simply to display more data. It's to help people understand what the evidence actually shows.
2. Historical Replay - Seeing Information as It Emerged
What did consumers actually know before an investigation or recall?
Recall Radar's time-aware Historical Replay lets users travel through complaint-reporting history one month at a time, reconstructing what information was available at each point.
To prevent hindsight bias, our detector uses only complaints eligible under each historical cutoff, applying a received-date-plus-seven-days public-availability proxy.
A Poisson-based statistical detector identifies unusually rapid increases in complaint reporting without accessing future records or regulatory outcomes.
The replay visually distinguishes:
- ▲ Statistical Alert: When an unusual complaint-reporting increase was detected.
- ◆ Investigation Opened: When NHTSA officially opened a related investigation, revealed later in the replay.
- Recall Markers: Official recall events displayed along the historical timeline.
For example, our development-period analysis identified a statistical alert for a 2019 Volkswagen Jetta power-train issue on April 1, 2019, preceding an investigation opened on September 3, 2019, by 155 days.
This is a historical example, not evidence of reliable recall prediction. Our demo replay uses development-period data and is labeled accordingly because no investigation in the held-out test period received an early alert.
Transparent Evaluation
Our results page compares the frozen detector's early-alert coverage against a chance comparison, while listing missed investigations and unmatched alerts.
- Development: 23/257 (8.95%) early coverage versus 70/783 (8.94%) in the chance comparison.
- Held-out test: 0/161 early coverage versus 9/290 (3.10%) in the chance comparison.
These results do not establish predictive performance. We deliberately present the detector as a tool for historical pattern exploration, not defect detection or recall forecasting.
3. Evidence-First Exploration - Transparency Behind Every Insight
Trustworthy information should never require users to accept a dashboard's conclusions without question.
Recall Radar is built around source traceability, reproducibility, and scientific transparency.
Users can move from summarized patterns to their underlying government records and distinguish between:
- Consumer Reports: Individual experiences documented through NHTSA complaints.
- Regulatory Actions: Official investigations and manufacturer recalls.
- Statistical Analysis: Our independent interpretation of historical reporting patterns.
Every finding is presented with its supporting evidence and appropriate limitations.
We provide context, not verdicts. Neither complaint counts nor statistical alerts establish confirmed defects, prove a vehicle is unsafe, or demonstrate that we identified an issue before NHTSA staff.
4. Everyday-Language Symptom Search
Drivers shouldn't need technical automotive vocabulary to find relevant information.
Our symptom-search feature uses reviewed aliases and lexical phrase matching to connect everyday descriptions with related complaint groups.
For example, users can search:
- "My steering wheel shakes."
- "Grinding when braking."
- "Engine suddenly loses power."
Recall Radar returns matching complaint groups with relevant excerpts, reporting dates, and official NHTSA source links.
These matches identify reported symptoms, not mechanical diagnoses.
5. Buyer Reports -Source-Backed Intelligence
Our printable, one-page PDF buyer reports bring together:
- Historical complaint counts and component trends.
- Relevant investigations and recalls.
- Statistical reporting patterns and reporting periods.
- Official NHTSA citations and supporting evidence.
Instead of reducing a vehicle to an unexplained safety score, these reports organize verifiable information into a format users can review, print, and share.
We also introduced Remember This Car, allowing users to save a selected vehicle directly in their browser without sending those preferences to our server.
No black-box safety scores- just accessible, verifiable evidence for better-informed decisions.
6. Official Recalls & Gemini Explanations - AI Grounded in Evidence
Recall Radar's expanded v2 experience brings official NHTSA recall information to vehicle pages, alongside recall markers in Historical Replay.
However, official recall descriptions can be dense and technical.
To improve accessibility, we developed a Google Gemini-assisted explanation workflow that simplifies recall language while preserving its original meaning.
Our approach follows strict verification principles:
- Source Grounding: Every generated sentence is connected to the official NHTSA text supporting it.
- Validation: Unsupported details, invented numbers, omitted qualifications, and altered urgency cause an explanation to be rejected.
- Human Review: Generated explanations are not published until reviewed by a person.
- Official Fallback: When an explanation is unavailable or unapproved, Recall Radar displays the original NHTSA wording.
Most recalls therefore continue to display official text rather than an AI-generated explanation.
AI makes complex information easier to understand without replacing government evidence as the authoritative source.
7. Recall Radar Through iMessage - Intelligence Beyond the Dashboard
Automotive awareness shouldn't end when users close a website.
Our separate Photon Spectrum iMessage assistant extends Recall Radar into a communication channel people already use.
The integration was completed after our feature cutoff and is enabled only during supervised testing windows. We do not represent it as a fully shipped, continuously available service.
The assistant supports structured, conversational questions such as:
- "What problems are reported for the 2019 Jetta?"
- "Are there any recalls on it?"
- "How have complaints changed over time?"
Google Gemini interprets the user's question and identifies the relevant vehicle, while responses remain grounded in our underlying data.
Every numerical claim is verified against the data before a response is sent. The assistant does not diagnose vehicles, declare them safe or unsafe, or invent regulatory conclusions.
Consent-Based Vehicle Monitoring
Users can explicitly opt in to WATCH one selected vehicle and receive sourced notifications when NHTSA publishes new complaints or recalls.
The messaging architecture includes:
- At most one notification per day for a followed vehicle.
- Explicit opt-in and consent confirmation.
- Quiet hours and daily messaging limits.
- Pause and resume controls.
- STOP to end notifications and DELETE to remove stored messaging preferences.
Our vision is to make trusted automotive information accessible through everyday conversations, allowing individual reports to contribute to broader, collective awareness without requiring users to repeatedly check a dashboard.
8. NHTSA Handoffs - Official Verification & Reporting
Recall Radar maintains a clear distinction between general vehicle research and the official status of a specific vehicle.
VIN Lookup - Privacy by Design
Users can enter a Vehicle Identification Number (VIN), which their browser sends directly to NHTSA's vPIC decoder to identify the vehicle's year, make, and model.
Recall Radar then opens the corresponding vehicle information page.
Importantly:
- The VIN never reaches our server.
- The VIN is never included in the website URL.
- The VIN is not stored by Recall Radar.
Because a make/model/year lookup cannot establish whether an individual vehicle has an unrepaired recall, we direct users to NHTSA's official VIN recall lookup rather than displaying an unverified recall status.
Official VIN Recall Lookup: NHTSA Recalls
Guided Complaint Reporting
Our complaint-reporting workflow allows users to organize their experiences into a structured draft before continuing to NHTSA's official reporting form.
Recall Radar does not silently submit complaints, retain draft submissions, or replace the official reporting process.
We help users understand and communicate their experiences while keeping final verification and reporting with the appropriate government authority.
Built for Reliability - From v1 to v2
Our expanded v2 experience introduces recall information, symptom search, buyer reports, VIN handoffs, and additional consumer features without altering the original statistical evaluation.
To protect analytical reproducibility, our make protected verification checks that v1 result files remain byte-for-byte unchanged.
This ensures new features cannot silently rewrite historical findings or make earlier evaluation results appear stronger.
Our guiding principle: Transform individual vehicle reports into collective, verifiable awareness—connecting people, evidence, and automotive communities so better decisions begin with information they can actually trust.
How we built it
Everything heavy happens offline, once, before the demo. The site itself only reads precomputed results.
OFFLINE (done once, before the demo)
NHTSA flat files: complaints, investigations, recalls
│
▼
ingest.py dedupe by complaint number
│ drop personal fields, redact complaint text
▼
DuckDB snapshot e808281f001a, data as of Oct 10, 2026
│
▼
detector · matching · evaluation · v2 tables
(recalls, explanations, symptom index)
AT REQUEST TIME (read only)
browser → Caddy → FastAPI → DuckDB (precomputed) → React
no calls to NHTSA here
THE ONLY TWO LIVE NHTSA CALLS
browser → NHTSA vPIC when you press Decode with NHTSA
VM timer → api.nhtsa.gov once a day per watched car (iMessage)
The pipeline is Python 3.11 (managed with uv), Pandas and DuckDB, covering NHTSA records from 2014–2023. Ingest dedupes by complaint number, drops personal fields and redacts names, phone numbers, addresses and VINs from complaint text. FastAPI on Uvicorn serves the cached results from a DuckDB file opened read only, and the frontend is React, Vite, TypeScript and Recharts. It all runs on one Vultr VM behind Caddy, with systemd and HTTPS from Let's Encrypt. The analysis app makes no network calls at request time and runs fine offline on a laptop. When we tested on the real data, 95% of requests finished under 300 ms and issue page requests averaged about 14 ms.
The detector
For every group of make, model, model year and component, and for every month, we add up the complaints from the last two months and compare that to what the previous two years would lead you to expect. The surprise score is how unlikely that count is under a Poisson model:
$$S = −\log_{10} P\left(X \ge c \mid X \sim \text{Poisson}(\hat{\lambda})\right)$$
Here c is the number of complaints in the last two months, and the expected count is
$$\hat{\lambda} = 2 \cdot \max(\bar{y}, 0.25)$$
where ȳ is the monthly average over up to 24 earlier months. The 0.25 floor keeps the expected count above zero for groups with no history. A month raises an alert only when all three of these hold:
$$c \ge c_{\min} \qquad S \ge 4.0 \qquad c / \hat{\lambda} \ge 3$$
The minimum count is 5 (8 during the first six months). Consecutive alert months make one episode, and a new episode needs six quiet months first.
A quick example: a group that averaged 0.5 complaints a month gets λ̂ = 1. If the last two months had 4 and 5 complaints, c = 9. The chance of 9 or more under Poisson(1) is about 1.1 in a million, so S ≈ 5.95, the ratio is 9, and that month alerts.
complaints, one row per complaint number
public date = received date + 7 days
│
▼
group = (make, model, model year, component)
e.g. 2019 VW JETTA · POWER TRAIN
│
▼ for each month m
c = y[m−1] + y[m] last two months
mean = avg of y[m−25 … m−2] up to 24 months before
λ̂ = 2 × max(mean, 0.25) expected count
S = −log10 P(X ≥ c | λ̂) surprise score
ratio = c / λ̂
│
▼
alert if c ≥ 5 (8 during the first 6 months)
and S ≥ 4.0
and ratio ≥ 3
│
▼
episode = a run of alert months
a new one needs 6 quiet months
│
├→ match.py linked to a later investigation?
├→ evaluate.py early coverage vs chance
├→ replay.py ▲ markers on the replay
└→ export.py results.csv, cases.csv
Matching to investigations happens afterward, so the detector never sees a later outcome when it scores a month. We tuned the settings on the development years only and froze them under the git tag freeze-v1 before the test year was run. The evaluation is seeded and compares against matched control groups of comparable vehicles NHTSA never investigated.
Recall explanations and symptom search
Gemini runs as a batch job through the Google GenAI SDK. It never runs live on the site. Each draft explanation is checked against the official recall text and thrown out if it adds a detail the source doesn't support, invents a number, drops a qualification or changes how urgent it sounds. We reviewed 72 drafts and approved 58, and anything not approved falls back to the official wording.
Symptom search uses reviewed aliases plus plain phrase matching. The matcher exists in both Python and TypeScript so the search can stay in the browser, and the two versions produced the same 26,185 matches.
iMessage
IN
iPhone → Apple → Photon's shared iMessage line
→ Spectrum cloud → signed POST to our webhook
→ Caddy → messaging service (127.0.0.1:8791)
kill switch off? 503, nothing stored
bad signature? 401
message id seen before? ignored
group chat? polite no, direct chats only
our own echo? ignored
anything else a command, or:
Gemini reads the question
→ allowlisted data lookups
→ every number checked
→ reply
OUT
messaging service → Photon sidecar (Node 22)
→ Spectrum API → shared line → Apple → iPhone
It runs on Photon's shared line, which only registered users can text. Each webhook delivery is signed with HMAC over a timestamp and the body (SHA256). The messaging service is separate from the analysis app and sits behind a kill switch. It keeps a small SQLite database: the chat handle, the watched vehicle with consent time and time zone, the vehicle mentioned in the last 30 minutes of chat, the replies and alerts we sent, and incoming message ids and times (not their text). Gemini gets the question text, capped at 500 characters, plus the vehicle, and never the handle. We're on the free tier, so Google may keep what it's sent.
STOP cancels any queued alerts. DELETE removes every row for that chat and keeps only a one way hash, so a late message can't sign you back up. Copies held by Apple, Photon or the phone are outside our control. There are also quiet hours, pause and resume, and a daily limit.
How we worked
We split the repo into four owned areas (A–D), each worked on in its own Claude Code session. Project rules like no claim words, no VIN storage and who owns which paths lived in AGENTS.md and CLAUDE.md, and the spec, plan and task board lived in docs. Pydantic models generate JSON Schema, which generates the TypeScript types, so all four parts agree on the API shapes and CI fails if they drift. Every task was one PR with green CI and a review from someone who didn't write it, and release gates were checked on the deployed site. Testing covered hundreds of Python and frontend tests, API and messaging checks, browser checks, redaction audits and integration tests against production.
Results
Thresholds were frozen before the test year was run.
Test year:
- Early alerts for 0 of 161 eligible investigations, 0.0% (95% Wilson interval 0.0%–2.3%).
- Matched control groups reached 9 of 290, or 3.1%.
- That's 3.1 points below chance. The margin we set in advance was 10 points above chance.
- We audited the top alerts: 5 were later linked to an investigation, 18 matched nothing and none were ambiguous.
Development years, which we used to choose the settings: 23 of 257 (8.9%) against 70 of 783 (8.9%) for the controls, so the same as chance.
So on the test year, a simple complaint growth detector did not raise alerts earlier for vehicles NHTSA went on to investigate than for comparable vehicles it never investigated. That's our result, and it's why Recall Radar is built around reading a vehicle's full complaint history and seeing what was public before each investigation, rather than around prediction.
It's easy to find one case that looks good. In the development years, complaints about the 2019 Volkswagen Jetta power train alerted on April 1, 2019, and NHTSA opened an investigation on September 3, 2019, 155 days later. It makes a nice replay, and the numbers above are the reason we don't read much into it.
Every row of exports/demo/results.csv carries the config hash and git SHA. A clean clone running git checkout baseline-v1 && make repro reproduces both period summaries, results.csv and cases.csv byte for byte. The SHA256 of results.csv is 7a469c93a4097df1bb3d3f28a97772d20e58aa9ed106338cde6b67a3c561321a. We also checked all 120 values shown on the site against the exported results.
Challenges we ran into
The hardest part was being honest about time. NHTSA's "added to file" date matches the received date for almost every complaint, which looks like it was rewritten by a later system update, so it can't tell you when a record actually became public. We count each complaint as public seven days after NHTSA received it instead, and every screen labels the analysis as a received date experiment.
Counting was fiddlier than we expected. One complaint can list several components, so the per component counts had to count distinct complaints.
Matching cost us a lot of the test year. Most investigation families were excluded because their first action was an engineering analysis, and almost all of those came from one analysis that names several hundred vehicle and system combinations. In total, 333 of 494 test year families were excluded for one reason or another.
Keeping the AI parts in check took more work than wiring them up: rejection rules for the explanations, a number check on every iMessage reply, and an allowlist of the data lookups the assistant is allowed to make.
And scope. The iMessage assistant came together after our feature cutoff, and we chose to keep it behind a kill switch rather than call it shipped.
Accomplishments that we're proud of
Mostly that the negative result holds up. The thresholds, the rule for picking the demo replay and the method code were all frozen under a git tag before the test year run, so when the answer came back as no better than chance we could trust it, and anyone can reproduce it from a clean clone.
We're also happy that v2 added a lot without touching a single v1 result file, that the site needs no accounts, cookies or sign in, that VINs never reach our server, and that every number on the page traces back to a row of results.csv.
What we learned
Public data and usable data are pretty different things. Dates mattered more than any modeling choice, because the whole replay depends on knowing when each record became public. And writing the rules down before looking is what makes a "no" worth reporting. It's easy to find one replay that looks great; it's harder, and more useful, to say how often that happens by chance.
We also got a clearer sense of where AI helps here. Gemini was good at rewording dense recall text and at working out which car someone meant in a text message, but we only trusted it once every output was checked against the source.
What's next for Recall Radar
- Evaluate at the level of those engineering analyses, with a new freeze and a new test year, instead of tuning against this one.
- A specific car's recall status by VIN through an authorized source.
- With a licensed vehicle history source, suggestions in the chat for what to have inspected on a specific VIN. Those would be inspection points drawn from complaint data, never a diagnosis.
- A full independent review and verification of the iMessage assistant before it goes live.
Longer term, we think the same setup could be useful to consumer groups, researchers or car marketplaces. None of those are partnerships, just places it might fit.
Built with
Python, uv, Pandas, NumPy, SciPy, DuckDB, FastAPI, Uvicorn, React, Vite, TypeScript, Recharts, Playwright, SQLite, Node.js, Vultr, Caddy, Let's Encrypt, NHTSA ODI public datasets (complaints, investigations, recalls), NHTSA vPIC, Google Gemini, Photon Spectrum (iMessage), Claude Code
No accounts or sign in needed to try it.
Log in or sign up for Devpost to join the conversation.