Why a guessed match never reaches you
Every match FDA Radar computes between an FDA document and your product carries a provenance field: source, human, or model. The database lets only two of the three ever fire an alert — a rule poured into the schema, not remembered by hand.
By Connor Griggs — Regulatory & Quality Strategist
A monitoring product that joins your portfolio against FDA’s record is making two separate claims every time an item reaches you: that the document exists, and that it actually touches your device. The first claim is a fact FDA published. The second is a computation — and treating both as equally certain is a mistake worth naming before it costs anyone an alert they trusted.
Five bases, computed the same way
FDA Radar’s matcher answers one narrow question — does this item touch this product — as a join on identifiers, never a model call. Today it runs five bases: product_code exact, cfr_regulation at part granularity (a profile’s 21 CFR 876.1500 against a notice’s 21 CFR 876), application_no against a submitter’s own clearance number, and two firm fields — firm and cmo_firm — normalized the same way and checked separately, because a contract manufacturer’s name is not a looser version of the brand’s. Every one of the five is exact after normalization. None of them is a guess.
Two bases the schema names and the matcher won’t use
The database’s match_basis enum declares eight values, not five. device_class is one of the three left unimplemented, and the code comment explaining why is blunt: “Class II” matches half of FDA. A device class is real information — it is just too broad to mean anything as a personal match, and shipping it anyway would mean an alert firing on a shared risk category instead of a shared device. tag is declared for a vocabulary join that hasn’t been wired in yet. semantic is the third, reserved for an embeddings-based match that does not exist in this product today — and its own comment in the schema states what it will never be allowed to do, before a single line of that matcher has been written: can never alert.
A database column can enforce a promise a person only remembers to keep on their best day.
What “alertable” actually is
Every computed match carries a provenance field with one of three values: source — FDA published the identifier, and the join is exact; human — a reviewer supplied the key FDA omitted, most often a product code hand-tagged onto a recall that arrived without one; or model — a guess. A fourth column, alertable, is not written by any job in this pipeline. It is generated by the database itself, computed true only when provenance is not model. The invariant does not live in a function some future engineer has to remember to call before shipping a semantic matcher. It lives in the table, and a guessed match is structurally incapable of reaching a subscriber’s digest or firing an alert the day it is written, whether or not anyone reviewing that pull request thought about alerts at all.
What this doesn’t change
Alertable is necessary, not sufficient. A match can be exact — a real product code, joined against a real recall — and still never reach anyone, because the item behind it hasn’t cleared the separate, human-approval gate every published item passes through regardless of how it was matched. Relevance and judgment are two different questions in this product, decided by two different mechanisms, and neither is allowed to stand in for the other: a match says an item touches your device; a human still says what, if anything, that means. Per how the pipeline works and our editorial standards, this is regulatory intelligence about how relevance gets computed, never a claim about what a specific match means for a specific device.
Primary sources
Regulatory intelligence, not regulatory advice. This post describes method and published FDA records as of its date; decisions about a specific device belong with your regulatory professional.