RecallProven

Writing

GPSR: monitoring Safety Gate is easy, proving you did it is not

The EU General Product Safety Regulation — Regulation (EU) 2023/988 — has applied since 13 December 2024. If you sell consumer products into the EU, including online, it binds you, and Article 22(1) requires online marketplace providers to register a single point of contact for Safety Gate.

Most of the published guidance covers the paperwork: appointing a Responsible Person, technical documentation, labelling, the registration itself. That advice is easy to follow because it is a one-time task with a definite finish.

The obligation that practitioners consistently report as the one sellers fail is not a one-time task. It is continuous: monitor safety alerts affecting products in your catalogue, and act on them. And the part almost nobody has prepared for is the second half of that sentence, because an obligation you meet continuously is one you have to be able to *evidence* continuously.

*This is a description of a data problem, not legal advice. Read the regulation, or ask someone qualified, for what applies to your business.*

Checking is the easy part

The data is free and public. Safety Gate publishes weekly. France's RappelConso republishes with extra national detail. The US equivalents — CPSC, NHTSA, three separate FDA enforcement databases — are all open too, and useful if you sell in both markets.

Matching that against your catalogue is a scripting job. Pull the alerts, match on barcode or model, flag the hits. A competent developer builds a first version in a week.

So if the obligation were "check", this would be a solved problem and nobody would be failing it.

A feed subscription is not evidence

Here is the situation the requirement is actually about.

It is March. You check your catalogue against Safety Gate. Nothing matches. You carry on selling.

It is now November, and a market surveillance authority is asking about a product you listed in April. What can you show them?

"We subscribe to Safety Gate alerts" is a description of an intention. It says nothing about whether *that product* was covered by *that check* on *that date*. Neither does a screenshot, which is undated in any verifiable sense and shows only what someone chose to capture. Neither does an email archive of alert notifications, which proves you received things, not that you compared them to anything.

What answers the question is a record that has four properties. Each one is boring on its own, and the absence of any one of them is what turns a diligent seller into an undocumented one:

  • Dated — a timestamp you did not write yourself after the fact.
  • Scoped — the specific list of products the check covered. "Our catalogue" is not a scope;

catalogues change weekly.

  • Frozen — the result exactly as it stood that day, not recomputed on demand against today's

data.

  • Reproducible — a digest or hash that lets anyone confirm the record was not edited later.

Notice that all four are about *bookkeeping*, not about safety data. This is why the problem survives having good data: you can have every alert in the EU and still have nothing to show.

The property that breaks naive systems

Frozen is the one that catches people, and it took me a while to understand why.

Agencies revise recalls after publication. A recall issued in March covering three lot codes can cover eleven by June. Sometimes the product list widens, sometimes a date range extends, sometimes the hazard description sharpens into something that would have changed your assessment.

The URL does not change. There is no changelog, no revised_at field, and no notification. The page simply says something different than it did.

Now put that together with the March check. You checked, you found nothing, and you were right on the day. In June the recall widened to include one of your products. Nobody told you, because nobody is told.

If your evidence is generated on demand — a report that queries live data and prints today's answer — then your March record has silently become a claim you cannot defend. Worse, it now disagrees with reality in the specific direction that looks like negligence: it says you checked and found nothing, against a recall that today plainly covers your product.

I did not expect this to be common. Measured across the corpus I maintain: 15,148 of 176,180 recalls have been amended after publication — 8.6%, and none of it announced anywhere. Amendment detection requires storing a content hash per record and diffing on every ingest, because there is no upstream signal to subscribe to.

Which means the frozen property is not a nice-to-have. A system that recomputes is not merely less convenient; on roughly one record in twelve it will eventually contradict its own history.

What a defensible record looks like

Concretely, per check, you want to be able to produce:

  • The date and time it ran.
  • The exact identifiers submitted — or a digest of them, if you would rather not retain the list.
  • The corpus it was checked against, and how fresh that corpus was at the time.
  • The matches found, pinned to the *revision* of each recall as it stood.
  • A digest over the result, so the record is tamper-evident.

The digest matters more than it looks. Without it, your evidence is a database row you control, which an authority is entitled to treat as something you could have written yesterday. With it, the record can be checked against itself.

And note what is deliberately absent: no personal data. A compliance record needs to say what was checked, not who checked it. Storing more than that creates a GDPR problem while solving a GPSR one.

What the EU data actually looks like

Since precision beats adjectives, this is the corpus behind recallproven.com as of today:

  • 64,455 EU and French recalls, the earliest dated 2005-02-04 — nearly twenty years of history
  • 7,568 of them in the last twelve months
  • 19,074 distinct GTINs extracted from EU records, including identifiers that appear only in

free-text fields rather than structured ones

  • 15,148 amendments detected across the full corpus, with field-level deltas
  • Seven official sources, each under a licence permitting commercial reuse, with every attribution

obligation published at /v1/sources

Twenty years of EU recall history with amendment tracking is a materially different thing from eighteen months of alerts. Most of the value in a compliance record is retrospective: the questions arrive about what you did months ago.

If you are handling this yourself

Entirely reasonable: the data is free and the matching is not hard. The parts that take longer than expected:

  • Identifiers hide in prose. Barcodes and model numbers frequently appear in free-text

description fields rather than structured ones. Extracting them means a regex pass, and a regex pass means false positives. Validate GTIN check digits or your matches will include numbers that were never barcodes.

  • Never answer a malformed identifier with "no recalls found." If someone queries a broken

barcode and you report it clear, you have told them a product is safe when you did not look it up. Reject it instead. This is the one failure mode a compliance tool cannot have, and it is easy to ship by accident.

  • Amendment detection is cheap to build and worth more than the rest combined. Content hash,

diff on ingest, store the delta. A day of work that converts your evidence from "as far as we knew" into something that survives a recall changing under it.

  • Freeze your receipts. Generating evidence on demand is the default design and the wrong one,

for the reason above.

The regulation has applied since December 2024, and the retrospective questions are the ones that arrive. A record you started keeping today covers today forward, which is a good reason not to leave it another quarter.

---

*RecallProven turns seven official recall feeds into one API with consistent identifiers, amendment history, and a frozen, digest-verified receipt for every check. See how it works or the pricing. The technical notes behind the corpus are in Seven government recall feeds.*

RecallProven turns these seven feeds into one API with a consistent schema, stable identifiers and a per-check audit trail. See the pricing or read the documentation.