Safety Recall Radar

"Your monitored product catalogue contains 3 products matching new safety notices" — not "here are 1,089 recall records." The killer feature per the source research is inventory-exposure matching: real recalls from 6 real government bodies, scored against your product catalogue by UPC, model number, or fuzzy brand+name, with a confidence score that makes it immediately clear whether a hit is a confirmed match or a fuzzy one that needs a human look.

All 6 jurisdictions are real, live, keyless sources — none are placeholders

Jurisdiction	Real source	Access
us_cpsc	SaferProducts.gov Recall API	JSON, keyless
us_fda	openFDA enforcement API (food + drug + device)	JSON, keyless
uk_opss	gov.uk product safety Atom feed + content API	Atom + JSON, keyless
eu_safety_gate	Safety Gate's official weekly-report XML API	XML, keyless
canada	Health Canada's open data recall/alert bulk file	JSON, keyless, ~34,000 real rows, updated daily
australia	productsafety.gov.au recall RSS feed	RSS, keyless

Confirmed live end-to-end, all 6 succeeding in the same run: 1,089 real records (202 CPSC, 300 FDA, 40 OPSS, 297 EU Safety Gate, 150 Canada, 100 Australia), 0 fetch failures.

Two real bugs caught during live testing, fixed before shipping

1. openFDA's date-range query was silently breaking every FDA request. openFDA's Lucene-style range syntax needs a literal +TO+ in the raw URL (e.g. [20260401+TO+99991231]), but axios URL-encodes a literal + character in params to %2B, which openFDA's query parser rejects with an HTTP 500. Fixed by putting a literal space in the query string instead ([20260401 TO 99991231]) — axios's default param serializer encodes a space as +, which happens to produce exactly the right raw URL. Confirmed live: all 3 FDA endpoints failed identically before the fix, all 3 succeeded after.

2. CPSC's hazard text was pointing at the wrong field. CPSC's API returns both Description (product identification only — "this recall involves X battery charger, model Y") and Hazards[].Name (the actual hazard explanation — "...can cause serious injuries, internal chemical burns and death"). The first draft used Description for severity/hazard-type classification, which meant every CPSC record scored as low-severity "Other" regardless of how serious the real hazard was. Caught by spot-checking real output against the real source record before deploying, not assumed correct because the build succeeded. Fixed to read Hazards[].Name, confirmed live: the same battery-ingestion recall now correctly scores critical / Choking/Ingestion instead of low / Other.

A related, smaller classification fix: the hazard-type keyword for "Fire" originally matched the word "burn," which is ambiguous between thermal (fire) and chemical (e.g. battery-acid ingestion) burns — a real CPSC record about a swallowed battery's "internal chemical burns" was misclassified as a Fire hazard before this was narrowed to fire-specific terms only (fire, overheat, explosion).

Severity normalization — real structured hints first, keyword fallback second

Three of the six sources provide a genuine structured severity classification; the other three don't, and this is stated honestly rather than invented:

Source	Real structured hint
us_fda	FDA's own official Class I / II / III
canada	Two real coexisting vocabularies in the same dataset depending on which agency filed the recall: Type I/II/III (health products) and Class 1/2/3 (others)
eu_safety_gate	"Serious risk" / "Other risk levels"
us_cpsc, uk_opss, australia	No structured field — severity is keyword-scored against the real hazard text (death → critical; fire/choking/electric shock/serious injury → high; general injury/hazard language → medium; else low)

Hazard-type normalization

No two of the six sources share a hazard taxonomy (EU Safety Gate's real riskType field, Canada's short but inconsistent Issue text, CPSC/FDA/OPSS/Australia's free text only). All six are mapped through the same order-sensitive keyword classifier (hazardClassifier.ts) into one consistent vocabulary (Fire, Choking/Ingestion, Electrical, Chemical/Contamination, Laceration/Injury, Entrapment/Tip-over, Drowning/Water, Environmental, or each source's own real category text as a fallback) — a genuine cross-jurisdiction normalization, not each source's own inconsistent labels passed through untouched.

Inventory-exposure matching — confidence tiers

Tier	Confidence	Condition
Exact UPC	1.0	Recall and catalogue item share an identical (digits-only normalized) UPC
Exact model number	0.9	Recall and catalogue item share an identical (normalized) model number
Fuzzy, brand confirmed	0.35 + up to 0.55	Brand matches exactly; product-name token overlap (Jaccard similarity) scales the rest
Fuzzy, brand unknown	up to 0.5	No brand match on either side; scored on product-name token overlap alone
No match	0 / null	Below a 0.3 floor — treated as no match at all, not a very-low-confidence one

Confirmed live against real data: an exact model-number match (a real EU Safety Gate solar lamp recall, model "Star II") scored 0.9; a fuzzy brand-only match (a real Pixi eyeliner recall against a catalogue entry with a slightly different product name) scored 0.63; an unrelated catalogue item scored 0 and was correctly excluded. UPC and model number are frequently absent from the real source data itself — confirmed live that CPSC's own ProductUPCs/Products[].Model fields were empty in every sample checked — so the fuzzy path is the common real-world case, not an edge case, and its confidence is scored conservatively rather than inflated to look more certain than it is.

Modes

Mode	Behavior
jurisdiction_snapshot	Every real recall for the selected jurisdictions, unmatched — for research without a catalogue
catalogue_match	Same, plus matchedCatalogueItem/matchConfidence scored against productCatalogue (required for this mode)

Output schema

{
  "recallId": "string",
  "jurisdiction": "us_cpsc | us_fda | uk_opss | eu_safety_gate | canada | australia",
  "brand": "string | null",
  "productName": "string",
  "modelNumber": "string | null",
  "hazardType": "string",
  "hazardDescription": "string",
  "recallDate": "string",
  "severityLevel": "low | medium | high | critical",
  "matchedCatalogueItem": "string | null",
  "matchConfidence": "number (0-1)",
  "sourceUrl": "string",
  "checkedAt": "ISO timestamp",
  "fetchStatus": "success | failed",
  "errorMessage": "string | null"
}

Setup note

No browser needed — all 6 real sources work over plain HTTP (JSON/XML/RSS/Atom). Canada's bulk file is ~34,000 historical rows; fetched in full but filtered client-side to the last 120 days and capped at 150 most-recent records per run — a recall radar, not a full historical archive. UK OPSS detail fetches are capped at 40 per run for the same reason.

Shared "Radar" architecture

This actor doesn't need deltaStore.ts — recalls are inherently point-in-time events (a product either has been recalled or hasn't), not documents that get revised in place, so there's no "diff" to track the way Actors 37/38 track status/text changes. The relevant shared pattern reused here is the honesty discipline: real structured hints trusted first, keyword fallback second and labeled as such, never presenting a best-effort heuristic as an official classification a source doesn't actually provide.

Pricing

Event	Price
Run started	£0.05
Reading success	£0.06
Fetch failed	free

n8n integration

• Workflow A (trigger): scheduled daily run against a seller's full product catalogue across all 6 jurisdictions (catalogue_match mode).
• Workflow B (processing): immediate high-priority alert on any matchedCatalogueItem with matchConfidence >= 0.85; lower-confidence matches logged for manual review rather than triggering an urgent alert.