What this feed will not tell you

Recalls are usually batch-specific. A notice covers serials 4400 to 6200, or units manufactured between two dates. A resale listing almost never shows a lot code, and frequently does not show the model.

So a title match cannot establish that a listing is a recalled unit. It can establish that a listing is for the same product line as a recall. That is a materially weaker claim, and it is the only one the feed makes.

Matched on product line, not on unit. Recalls are often limited to specific batches or serial ranges, and marketplace listings rarely show them, so a match here means this listing appears to be the same product as a recall, not that this particular item is affected.

What follows from that

• Seller identity is never published. It is hashed at the adapter, before the matcher sees it, and the published record type has no field for it. Naming a seller as trading recalled goods on a fuzzy title match is the specific lie this project exists to avoid.
• A match below 0.7 confidence is quarantined, shown with its reason, and never asserted. The threshold is set high on purpose: a false positive here is an accusation and a false negative is only a miss.
• A listing that states an attribute the recall rules out is demoted below the threshold even when the brand and product agree. A 4-litre fridge is not covered by a recall of the 10 and 15 litre models, however well the words line up.

The rate is low and it is meant to be. 168 of 185 matches were held back, and the reasons below are checkable rather than a score. Most of them are a stated capacity that the recall does not cover, which is exactly the case a keyword search gets wrong and reports as a hit.

Each source has a contract with a version, a minimum row count, a maximum row-count drop, and a per-field null-rate and type limit calibrated against an observed healthy capture. A run that breaches the contract is diagnosed before anything is repaired.

The gate that matters most

A repair reporting success is not evidence that it worked. Every repair is followed by a fresh run measured against the same contract, and the result is only served if that run passes. This has already caught a repair that finished cleanly and returned nothing, which is on the incident log as the oldest entry.

• Matching is title-based. It cannot read a lot code off a photo, so batch-level certainty is out of reach by construction, not by effort.
• A record that is withdrawn at source and later reappears sorts above every other recall and carries both dates, but nobody is told. There is no subscription and no alert, so the feed reports a relisting only to a reader who happens to open it.
• Three collectors in the account are permanently stuck: one on a repair prompt that was too aggressive, and two holding a repair lock that outlived the job that took it. A repair can damage a working scraper, and nothing here prevents that beyond refusing to serve the result.
• Bright Data cannot run a repaired collector as a draft from the CLI, so the verification gate sits at serving time rather than at promotion time. The collector can be left in a worse state than it started, even though the feed never shows the bad output.
• Coverage is two recall sources and one marketplace. Nothing here has been measured against a regulator that redesigns its site without warning, because that has not happened during the build.