The field that explains a recall was specified to describe the product. The hazard lives in a separate enum, and it is the part least likely to survive being quoted.
Four sentences from the Food and Drug Administration's device enforcement database, each of them the complete text of the field that explains why a product was recalled:
Probes may rupture/burst during activation
A detector can detach and fall.
The catheters may not retain their shape.
Incorrect instructions for use (IFU).
Recall numbers Z-1566-2026, Z-0371-2019, Z-2481-2025 and Z-0789-2014. All four are Class I, the classification the agency's own regulation reserves for "a situation in which there is a reasonable probability that the use of, or exposure to, a violative product will cause serious adverse health consequences or death" (21 CFR 7.3(m)(1)). Six words, seven, eight, six. Read them again and notice who is missing. A probe bursts during activation, and the sentence does not say inside what. A detector detaches and falls, and the sentence does not say onto whom.
I read ten thousand of these sentences, the most recent ten thousand of the 39,794 records the openFDA device enforcement endpoint held on 6 September 2026 (dataset stamped 19 August 2026; report dates from 20 June 2012 to 19 August 2026). The question was simple: how often does the sentence that explains a recall contain a person, or a harm to one? The answer is that in the class defined by death, two sentences in three contain neither.
The count, with its gradient
Counting was done generously on purpose. A record counts as naming a person if the field contains any of patient, user, consumer, person, people, clinician, physician, surgeon, nurse, operator, infant, child, neonate or subject, in singular or plural. It counts as naming a harm on death, die, fatal, injury, harm, serious adverse, adverse health event or reaction, morbidity or mortality. "The device may injure the user" counts as both. Every rate below is therefore an upper bound on how often the human appears, and the share of sentences with nobody in them is a floor.
| class | records | median words | names a person | names a harm | neither |
|---|---|---|---|---|---|
| Class I | 938 | 32 | 293 (31.2%) | 124 (13.2%) | 616 (65.7%) |
| Class II | 8,804 | 26 | 1,486 (16.9%) | 341 (3.9%) | 7,167 (81.4%) |
| Class III | 258 | 24 | 18 (7.0%) | 9 (3.5%) | 233 (90.3%) |
The gradient is real and the piece should not flatten it. A Class I reason is about twice as likely as a Class II reason to put a person in the sentence and three times as likely to name a harm. The prose does carry some of the severity. What it does not do, even in the class where the regulation says a reasonable probability of death, is carry it most of the time. Only 95 of the 938 Class I sentences, one in ten, contain both a person and a harm.
Two checks on the count before going further. The first is repetition. A single recall event can produce dozens of records, one per product line, each carrying the same sentence, and 2014 shows what that does: of 145 Class I records that year, 28 distinct sentences, and one of them, a packaging-integrity notice that does mention "injury to the patient", appears 59 times. That year's silent share is 11 per cent and it is the exception in a run of years between 55 and 91 per cent. Collapsing the whole Class I set to its 434 distinct sentences moves the silent share from 65.7 to 69.1 per cent. The finding is not a repetition artifact; if anything the repeated sentences are the ones that mention the patient.
The second check is the word list. When a Class I sentence does name a person, the word is "patient" in 213 of 294 cases (a prefix match, so one record more generous than the table's 293), and "patient" is the only person-word present in 200 of them. Across 938 recalls of products that could kill, "physician" appears once, "person" once, "surgeon" twice. The field's vocabulary for a human being is effectively one word, and two times in three it is absent.
What the silent sentences say instead
If the person is not in the sentence, something else is, and it is worth reading what. Of the 616 Class I sentences with nobody in them, 425 name an object: a device, a product, a unit, a lot, a component, a catheter, a pump, a battery, a valve. 386 contain a modal of possibility, may or might or could or can or potential. The most common first word is "there", 135 times, almost always as "There is a potential for" or "There is a possibility that". Then "the", then "reports", then "potential". The grammar is consistent across manufacturers and years: there is a potential that the object may do a thing.
The longest silent sentence in the set is 179 words, recall Z-2173-2025, a large-volume infusion pump. It explains that under-infusion can occur when a flow rate is increased to more than double, that "the level of underinfusion is variable based on the current infusion rate, the duration the pump has been running at this flow rate, and the magnitude of the rate change," that mis-loaded tubing "may result in the pump infusing at a rate higher or lower than programmed," and that "customers should ensure that: 1) The door is fully open before loading the set. 2) The tubing is taut and loaded without slack in the pumping channel." It is a careful, specific, useful paragraph about a pump. The thing the pump is attached to does not appear in it. Neither does what under-infusion of that thing does.
The 144-word runner-up, Z-0864-2024, is a numbered list of eleven software issues in a syringe pump, "Delivery During Motor Not Running High Priority Alarm," "Re-administered Loading Dose," "Depleted Battery Alarm," each with the firmware versions affected, closing with a request to install the latest software. Class I. Nobody in it.
Set those beside the sentences that do name both. Z-1484-2024: "Software has anomalies that have the potential to cause underdose, overdose, or delay in therapy which could lead to serious patient harm or death." Z-1228-2014: "Discovery of serious injuries and deaths associated with the process of changing from a primary System controller to their back-up System controller in patients using the Pocket System controller model." The second of those is a sentence about something that happened. The first is a sentence about a class. Both are rare: 124 Class I sentences name a harm at all, and 50 of those say death, serious injury or life-threatening in words.
The obvious reading, and why it is wrong
The obvious reading is that manufacturers write around the patient. Someone at the company drafts the recall statement, and the sentence about the probe bursting is the sentence a lawyer lets through. I started with that reading and the field's own documentation talked me out of it.
openFDA publishes a field reference for the device enforcement endpoint, a YAML file with one entry per field. The entry for the sentence I have been reading says this, in full:
reason_for_recall: Information describing how the product is defective and violates the FD&C Act or related statutes.
That is line 296 of the file as retrieved on 6 September 2026. The field is specified to describe the product and the violation. It is not specified to describe the hazard, and it is not specified to describe the person. Near the top of the same file, the classification field is defined as the "numerical designation (I, II, or III) that is assigned by FDA to a particular product recall that indicates the relative degree of health hazard," and its three permitted values are glossed in the same file: Class I, "Dangerous or defective products that predictably could cause serious health problems or death"; Class II, "Products that might cause a temporary health problem, or pose only a slight threat of a serious nature"; Class III, "Products that are unlikely to cause any adverse health reaction, but that violate FDA labeling or manufacturing laws" (lines 26 to 35).
So the database has a field for the hazard and a field for the defect, and they are different fields. The hazard field is an enumeration with three values. The defect field is free text. A manufacturer who wrote "the patient may die" into the defect field would be filling it with something it was not defined to hold, and a manufacturer who describes the probe and stops has filled it exactly as specified. The two-thirds silence is the schema working.
The split is older than the API. The recall regulation, whose definitions section carries a source note that begins in 1977 and was amended in 1978, tells a firm that initiates a recall what to report to the agency, as a numbered list: "(1) Identity of the product involved. (2) Reason for the removal or correction and the date and circumstances under which the product deficiency or possible deficiency was discovered. (3) Evaluation of the risk associated with the deficiency or possible deficiency." (21 CFR 7.46(a)). Reason is item two. Risk is item three. The public database inherited item two as prose and item three as a Roman numeral.
There is one more place in the same regulation where the two are asked for together, and it is not the database. The recall communication, the letter a firm sends to the hospitals and distributors holding the product, is to "explain concisely the reason for the recall and the hazard involved, if any" (21 CFR 7.49(c)(1)(iii)). The reader who is about to use the product gets the reason and the hazard in one sentence. The public record gets the reason in a sentence and the hazard in a code.
Where the code falls off
The two fields travel together inside the record. Every one of the 10,000 records I read carries both, and anyone reading a whole record sees both. The problem is everything that reads the prose and not the record.
The reason field is the field that is quotable. It is the one a search engine indexes, the one a summary copies, the one a procurement analyst pastes into a note, the one a language model is most likely to have seen, and the one an automated pipeline extracts when it wants "the text." The classification is an enum. Enums are the part of a record least likely to survive that flattening, because they do not read as sentences. Any downstream reader that keeps the text and loses the code is reading a corpus of 39,794 sentences in which, by the most generous count available, almost nobody is hurt.
I want to be exact about the status of that paragraph. It is a structural claim, not a measured one. I did not trace the recall text into search results or summaries or models, and I am not asserting that anyone downstream has in fact lost the code. What I measured is that the code is the only place the severity reliably lives, and what I am pointing at is that the code is the part of the record least likely to survive being quoted.
What a schema decides
None of this required anyone to lie. Every sentence in the 616 is, as far as I can tell, true. The probe does burst. The detector does detach. The pump does under-infuse when the rate more than doubles. The manufacturers answered the question the field asked, and the field asked about the product, because in the late 1970s, when the recall regulation was written, someone decided that the reason and the risk were separate items on a list, and when the records were published through an API the risk arrived as an enumeration and the reason as a string, and 39,794 pieces of writing inherited both shapes without anyone downstream being told they had been made.
That is the general form and it is not special to the FDA. Every mandated text field is a question, and the question was written once, by someone thinking about what the field was for at the time, and every answer afterwards is shaped by it. The people who fill the field learn its shape from the previous entries. The people who read the field, years later and one table-join away, see only the answers and assume the shape was chosen by the writers. Ask what a field was specified to hold before asking why its writers left something out. Often they did not leave it out. It was never in the question.
A detector can detach and fall. The sentence is complete, correct, and Class I. It was never asked what it might fall on.
Reproduction
Every number in this essay was computed by one of two scripts kept beside it, and nothing was hand-counted.
read_reasons.py: fetches the 10,000 most recent records from the openFDA device enforcement endpoint intoreasons_cache.json(3,056,270 bytes, datasetlast_updated2026-08-19, 39,794 records available) and computes the class table, the shortest Class I reasons, the 616 of 938, and the person-word breakdown. Its person and harm patterns are the two word lists given above.read_silence.py: imports those same two patterns fromread_reasons.py, so the two scripts cannot disagree about who counts as a person, and computes the modal and object-noun shares of the silent sentences, the first-word count, the longest silent sentences, the 95 records naming both, the 50 naming death or serious injury in words, the silent share by report year, the 2014 repetition check (145 records, 28 distinct texts, one text 59 times), the distinct-text share (434 distinct, 300 silent, 69.1%), and the report-date span.Primaries saved in
PRIMARIES/with the fetch stamp:deviceenforcement.yaml(12,662 bytes; the quoted definitions are at lines 26 to 35 and 295 to 296),ecfr_21cfr7.3.xml,ecfr_21cfr7.46.xml,ecfr_21cfr7.49.xml(the eCFR versioner API at the 2026-09-03 issue date, 4,144, 3,050 and 3,028 bytes), Cornell LII copies of the same three sections, and the FDA "Recalls Background and Definitions" page (30,299 bytes, "Content current as of" 20 March 2026).Limits worth stating plainly: the sample is the endpoint's most recent 10,000 by its default order, not a random draw of the 39,794; the word lists are generous, so every person and harm rate is an upper bound; "silent" is my label for a record matching neither list; the year table is uneven because a few large events dominate some years; the downstream claim in "Where the code falls off" is unmeasured.
Sources
U.S. Food and Drug Administration, openFDA, Device Enforcement Reports API, https://api.fda.gov/device/enforcement.json (records retrieved 6 September 2026; dataset last updated 19 August 2026)
U.S. Food and Drug Administration, openFDA, device enforcement field reference, https://open.fda.gov/fields/deviceenforcement.yaml (retrieved 6 September 2026; keys
reason_for_recall.description,classification.description,classification.possible_values.value)21 CFR 7.3(m), Definitions, Recall classification; 21 CFR 7.46(a), Firm-initiated recall; 21 CFR 7.49(c)(1), Recall communications; Electronic Code of Federal Regulations, https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-7/subpart-C (issue date 3 September 2026; source note 42 FR 15567, 22 March 1977, as amended at 43 FR 26218, 16 June 1978, and 77 FR 5176, 2 February 2012); mirrored at Cornell Legal Information Institute, https://www.law.cornell.edu/cfr/text/21/7.3, /7.46, /7.49
U.S. Food and Drug Administration, "Recalls Background and Definitions", https://www.fda.gov/safety/industry-guidance-recalls/recalls-background-and-definitions (content current as of 20 March 2026)
