Riaz Malik

Considerations for the Regulation of Generative Al-Enabled Medical Devices: Discussion Paper
and Request for Feedback. Docket No. FDA-2026-N-7874

Considerations for the
Regulation of Generative AlEnabled Medical Devices:
Discussion Paper and Feedback
Docket No. FDA-2026-N-7874

Author - M A Riaz
sherwoodprojectsltd@gmail.com

Date 18/10/2026 1 of 131 FDA-2026-N-7874
Question 1 - Does the two-axis risk framework, organised around device activity and the
consequence of relying on an incorrect output, appropriately capture the dimensions most
relevant to the risk of a GenAI-enabled software function? If there are additional dimensions
—such as the reversibility of a resulting action, the availability of downstream safeguards, the
time pressure of the deployment setting, or the traceability of the output (i.e., to primary
source materials)—that should be represented in a risk framework, please describe and
provide examples of how they should be represented.

1. Summary position

The two-axis framework (activity × consequence of an incorrect output) is a sound starting
heuristic. It should not be the whole risk framework. Several factors that CDRH already treats as
risk-relevant are being folded into the consequences axis, which reduces predictability. We
recommend keeping the two axes for base placement and adding a short, de ned set of modi ers.

2. What the framework gets right

• The activity axis tracks real differences in risk. Separating non-directive, action-directing,
supervised action-taking and autonomous action-taking re ects how harm actually occurs.
• It looks at substance, not wording. The paper’s point that a “talk to your doctor”
disclaimer does not make an output less directive is correct and should be preserved.
• It is familiar. It follows matrix approaches FDA already uses in other guidance, so the
learning burden for sponsors is low.

3. Where it falls short

3.1 The consequences axis is carrying more than severity. The paper moves measurement and
signal-processing functions, and patient-facing functions, “higher on the consequences axis.” The
reason in both cases is that the user cannot detect an incorrect output. That concerns detectability,
not severity of harm. Combining the two makes placement subjective and hard for manufacturers to
anticipate.

3.2 Functions are placed at a single point, but GenAI behaviour is not. The paper notes that
multi-turn devices can migrate from informational to action-directing, and that scope boundaries
can be uncertain. Figure 1 has no way to represent this.

3.3 Human supervision is treated as protective by default. “HCP-supervised” sits lower on the
activity axis, yet the paper’s own Appendix A (E.4) recognises automation bias. Supervision lowers
risk only if it is effective in practice.

4. Responses to the dimensions CDRH proposed

Recommend
Dimension Condition
ation
Distinguishes transient from lasting harm; relatively objective to
Reversibility Include
assess
Downstream Credit only safeguards that are independent of the GenAI function
Include
safeguards and shown to work (e.g., pharmacist veri cation, hard dose limits)

Date 18/10/2026 2 of 131 FDA-2026-N-7874

fi fi
fi
fl
 Reduces the real capacity for human review; relevant to the stroke
Time pressure Include
order-set example in the paper
Include as a
Counts only if citations are faithful to sources and users can
Traceability conditional
realistically check them
mitigator

5. Additional dimensions

1. Error detectability/veri ability. Make this explicit, and move it out of the consequences
axis. It would replace the current informal “migration” for patient-facing and measurement
functions.
2. Breadth and open-endedness of scope. The Background section names uncertain intendeduse bounds as a distinct GenAI risk.
3. Conversational trajectory. Assess risk across realistic multi-turn paths, not only at a single
point (links to Question 5).
4. Scale and correlated error. A deployed model’s errors repeat across many users, unlike an
individual clinician’s.
5. Vulnerable populations, such as paediatric, cognitively impaired or low-health-literacy
users, as a consequence modi er.
6. Proposed representation

Avoid adding axes. Instead:

• Keep the two axes for base placement.
• De ne a closed list of modi ers (detectability, reversibility, independent safeguards, time
pressure).
• Specify criteria and a bounded effect for each, for example moving a function up or down
one level.
• Require sponsors to document the rationale for each modi er applied.
This keeps the framework usable and gives manufacturers the predictability that Question 2 asks
about.

7. Illustrative examples

Scenario Base Modi ers Net effect
placement
Basal insulin dose Action- Low detectability, patient-facing, low
Highest tier
instruction to a directing / reversibility
patient
Chest-pain triage severe
Action- Time pressure, low detectability; error Highest tier;
advice to a patient directing / in either direction (under- or over- evaluate both error
Strep antibiotic severe
Action-taking / Easily reversible, independent clinician directions
escalation)
Lower tier
prescription, HCP- limited- check
supervised
OTC remedy advice moderate
Action- Lowest tier among
Reversible, low severity
for poison ivy directing / action-directing
limited
These placements are illustrative and for discussion, not a proposed classi cation.

8. Additional point

Date 18/10/2026 3 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
 The framework operates per function, but the paper recognises that devices combine multiple
functions. CDRH should clarify how function-level placements combine into a device-level risk
determination, particularly when a conversational device moves between functions.

9. Recommendations

1. Retain the two-axis framework as a base heuristic.
2. Separate detectability from severity.
3. Adopt a de ned modi er set with bounded, documented effects.
4. Credit supervision and safeguards only where effectiveness is demonstrated.
5. Address multi-turn trajectories and device-level combination explicitly.

The modi ers wouldn’t add a third axis to the graph. The two axes stay as they are for base
placement, and the modi ers shift a function along the existing diagonal risk gradient. Here is a text
sketch.

Step 1: base placement on the two axes

Each cell has a risk tier from 1 (lowest) to 6 (highest), increasing toward the upper right, as in
Figure 1.

CONSEQUENCES
Non- Action- Action-Taking Action-Taking
Directive Directing HCP-Supervised Autonomous
Severe | 3 | 4 ●B | 5 | 6 |
Moderate | 2 | 3 | 4 | 5 |
Limited | 1 | 2 | 3 ●C | 4 |
ACTIVITY →
• ●B is chest-pain triage advice to a patient (action-directing, severe).
• ●C is an HCP-supervised strep antibiotic prescription (action-taking, limited).
Step 2: modi ers move the tier up or down

Each modi er has de ned criteria and moves the function by a xed, bounded amount, for example
±1 tier. The sponsor documents each one applied.

Modi er Effect Applies when
Low detectability of errors 1 User cannot independently check the output
Time pressure 1 Setting limits real human review
Low reversibility 1 Harm from a wrong output is lasting
Independent, proven A check outside the GenAI function demonstrably
-1
safeguard works
Easily reversible -1 Harm is transient and correctable

Step 3: net result

Tier 6 (cap) ┤ ●B' ← Chest-pain triage: base 4, +1 low detectability,
│ +1 time pressure → 6
Date 18/10/2026 4 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
fi fi
 Tier 4 ┤ ●B (base)
│
Tier 3 ┤ ●C (base): HCP-supervised strep prescription
Tier 2 ┤ ●C' ← base 3, −1 easily reversible → 2
On the graph, the modi ers do not move the point sideways or add a dimension. A point slides
along the diagonal arrow, either toward “increasing risk” or back toward the lower left, and the tier
it lands on sets the evidence expectation.

Why this form

• Predictability. Sponsors can calculate their tier from published criteria rather than from
judgment calls about which cell a function belongs in.
• Transparency. The “migration” the paper applies informally to patient-facing and
measurement functions becomes an explicit, auditable +1.
• Simplicity. There is no 3D graph or additional axis, so the framework stays close to Figure
1.
Question 2 - CDRH seeks input on how to account for the spectrum of GenAI-enabled
informational functions that vary in the degree to which they direct a user to a particular
action (i.e., between “non-directive” and “action-directing”). What characteristics of an
output—such as its wording, speci city, personalisation, or context—could be considered as
modi ers of the risk associated with an informational function, after accounting for the
device’s overall functionality and intended use? What additional information would provide
manufacturers with suf cient clarity and predictability around risk assessment for
informational functions while recognising that directiveness may exist along a continuum.

1. Summary position

Directiveness should be assessed from what an output asks the user to do, in context, not from its
wording. We recommend a short, de ned set of output-level modi ers that move an informational
function along the activity axis (and so along the risk gradient), supported by a published workedexample set and a sponsor-documented assessment method. This keeps the continuum the paper
describes while giving manufacturers a predictable answer.

2. Starting point: the paper’s own continuum

The paper gives four lisinopril examples that already form a usable ladder:

Level Example (from the paper) What changes
1. General Doses are sometimes increased when BP stays
No link to the user
information above goal
In situations like this, clinicians often increase Linked to the user’s
2. Contextualized
the dose circumstances
Takes a position on what to
3. Endorsement “I recommend increasing the dose”
do
4. Instruction Increase from 10 mg to 20 mg daily Speci es the action fully

We suggest CDRH formalise this ladder as the reference scale, since it is concrete and sponsors can
map outputs onto it.

Date 18/10/2026 5 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
 3. Output characteristics that should modify risk

Characteristic Lower directiveness Higher directiveness
Personalization Applies to patients in general Applies to this user’s data and situation
Speci city of Names a class of options Names a drug, dose, timing or destination
action
Stance Presents options neutrally Endorses or instructs a single course
Lays out alternatives and
Exclusivity Omits or discourages alternatives
trade-offs
Prescribes timing (“go now”, “wait until
Urgency framing No time element
morning”)
Foreclosing Preserves the option to seek
Tells the user they do not need care
escalation care
Context of use Reference or education setting Embedded in a live decision work ow

Two points on application:

• Assess the substance, not the verbs. The paper rightly says that “recommend,” “should” or
“consider” are not decisive. A neutral-sounding output that gives one dose to one patient is
highly directive.
• Disclaimers do not count as mitigation. We agree with the paper that “talk to your doctor”
does not make a patient-facing output less directive.
4. Context and user factors that interact with directiveness

Wording alone is not enough, because the same sentence has different effects depending on who
reads it and when.

• User expertise. A directive output to an HCP who can evaluate it differs from the same
output to a patient (links to Question 3).
• Conversational position. In multi-turn use, an output may be non-directive in isolation but
directive after the user has supplied personal data. Assess the full trajectory (links to
Question 5).
• Anticipated reliance. Where a user is likely to act on the output without further checking
(time pressure, no easy second source), effective directiveness is higher.
5. How this ts the two-axis framework

Rather than a separate scoring system, treat directiveness as a determinant of position on the activity
axis, with the modi ers above adjusting where an informational function sits between “nondirective” and “action-directing.” The consequences axis is then assessed independently, as in the
paper. This avoids double-counting the same factors on both axes.

A simple rule could work: a function is classed by its most directive output that it can
foreseeably produce within its intended use, not its typical output. Otherwise a device that is
usually general but occasionally instructs would be under-classi ed.

6. What would give manufacturers clarity and predictability

1. A reference ladder (Section 2) with published de nitions for each level.

Date 18/10/2026 6 of 131 FDA-2026-N-7874

fi
fl
fi
fi
fi fi
 2. A worked-example library across clinical domains, including borderline cases, with the
reasoning shown. Examples teach the continuum better than de nitions do.
3. A de ned assessment method. Sponsors would test outputs across a pre-speci ed set of
realistic prompts, including adversarial and emotionally loaded ones, and report the
distribution of directiveness levels, not a single label.
4. A decision rule for ambiguous cases, such as classing at the higher level when outputs
span two adjacent levels, unless the sponsor shows the higher level occurs rarely and is
controlled by a safeguard.
5. A pathway for early feedback, such as pre-submission review of the directiveness
classi cation, since this is a judgment-dependent determination.
6. Intended-use statements that match behaviour. Labelling that says “informational only”
should be checked against what the device actually outputs.
7. Illustrative examples

Output Setting Directiveness Reasoning
“Statins can lower LDL
Any Level 1 General, no action implied
cholesterol”
“With your numbers, doctors PatientLevel 2 Linked to user, no speci c action
often adjust therapy” facing
Patient-
“You should start a statin” Level 3 Endorses a course for this user
facing
Patient-
“Take 20 mg tonight” Level 4 Fully speci ed instruction
facing
“It is probably nothing, no need Chest- High, regardless Forecloses escalation on a severeto go in” pain query of wording consequence function

These are illustrative, not a proposed classi cation.

8. Cautions

• Avoid keyword tests. They can be gamed by rephrasing and miss neutral-sounding
instructions.
• Avoid a hard binary. A single threshold will push sponsors to engineer outputs to fall just
below it. The continuum plus a conservative rule for ambiguity is harder to game.
• Classi cation should follow testing, not design intent. Generative outputs vary, so the
label must re ect observed behaviour across inputs.
9. Recommendations

1. Adopt the four-level ladder as the reference scale for directiveness.
2. De ne a closed set of output modi ers (personalisation, speci city, stance, exclusivity,
urgency, foreclosing escalation).
3. Assess directiveness by substance and context, and class by the most directive foreseeable
output.
4. Reject disclaimers as mitigation, consistent with the paper.
5. Publish worked examples and offer pre-submission feedback on classi cation.
6. Require sponsors to report observed directiveness distributions from pre speci ed testing.

Question 3 - CDRH seeks input on whether and when a GenAI-enabled function that results
in delivery of clinical information to patients, as opposed to HCPs, could present different or
Date 18/10/2026 7 of 131 FDA-2026-N-7874

fi fi
fi
fl
fi
fi
fi
fi
fi fi fi fi fi
fi
 higher risks, while also recognising the potential bene ts associated with improved patient
empowerment, engagement, and access to clinical information. What device characteristics,
output features, or safeguards might mitigate risks that could arise when a user lacks the
domain knowledge to independently evaluate an output, without unnecessarily
underestimating patient capability?

1. Summary position

Patient-facing delivery should not be treated as higher risk by default. The relevant risk driver is
whether the user can detect and act safely on an incorrect output, not whether the user is a patient.
We recommend assessing the user’s ability to evaluate the output as a function of the task and
output, applying an uplift only where that ability is demonstrably limited, and crediting safeguards
that have been shown to work. This preserves the bene ts the paper recognises (empowerment,
access, engagement) while targeting the harms it identi es (delayed care, inappropriate selftreatment).

2. When patient-facing delivery presents different or higher risk

The paper’s concern is that patients may be unable to identify an incorrect output, rely on it, and act
in ways that harm outcomes. That concern is real, but it depends on conditions:

Condition Higher risk when... Lower risk when...
The output cannot be checked by a lay The output is easy to check or comes
Veri ability
user (dosing, interpretation of results) with a source the user can read
The output tells the patient what to do The output explains or educates
Directiveness
(links to Question 2) without directing
Consequence
A wrong action is serious or lasting A wrong action is minor or easily
and
(insulin, chest pain) corrected
reversibility
The patient is making a decision in The patient has time to re ect or
Time pressure
minutes consult
Downstream No clinician or other check sits between A clinician, pharmacist or care team
check output and action reviews before action
The user is a child, cognitively impaired, The user is a typical adult seeking
Vulnerability
distressed, or has low health literacy background information

Most of the risk sits in the combination of action-directing output, severe consequences and low
veri ability. A patient reading a plain-language explanation of their condition sits in a different
place from a patient being told whether to go to the emergency department.

3. Avoiding underestimation of patient capability

The paper itself ags the danger of “medical parentalism.” We suggest three principles:

• Treat the user population as a variable, not an assumption. Patients are not uniformly
less capable. A patient with a chronic condition may know their own disease better than a
generalist HCP. Risk should be assessed against the intended user population, with evidence
rather than an across-the-board uplift.

Date 18/10/2026 8 of 131 FDA-2026-N-7874

fi
fi
fl
fl
fi
fi fi
 • Distinguish information access from decision delegation. Giving patients clear
information supports autonomy. The higher-risk case is where the device substitutes for
judgment on a consequential decision. The framework should leave the former unburdened.
• Do not penalise transparency. Features that treat the patient as a capable adult (showing
uncertainty, offering sources, giving options) should be encouraged, not counted against the
device.
4. Device characteristics and safeguards that could mitigate risk

4.1 Output features

• Calibrated uncertainty. The output states what it does not know, and where evidence is
contested. This links to benchmarking element S.3.
• Source traceability. Citations to primary sources the user can open, credited as a mitigator
only where they are accurate and the user can realistically use them.
• Comprehension-appropriate language. Plain language adapted to health literacy, tested
rather than assumed (element E.4).
• Options and trade-offs, not a single instruction, where several reasonable courses exist.
• Speci c escalation triggers. Concrete “seek urgent care if...” criteria, which are more
usable than generic disclaimers.
• No foreclosure of escalation. The device should not tell a patient they do not need care on a
high-consequence question unless that function has been validated for it.
4.2 Device design

• Scope limits. Clear refusal and redirection when a request moves beyond intended use
(element S.2), including in multi-turn drift.
• Context capture. Asking for key facts (age, pregnancy, medications, renal function) before
giving advice that depends on them.
• Consistency on safety-critical behaviour. Escalation and refusal should not vary with
phrasing, tone or user pushback (element R.1).
• Handling distress and minimisation. Resistance to over-reassurance when a user plays
down symptoms.
4.3 Systemic safeguards

• Clinician in the loop where feasible, such as sharing outputs with the patient’s care team or
routing high-consequence outputs for review.
• Pharmacist or institutional checks for medication-related outputs.
• Hard limits on speci c outputs, such as dose ranges, enforced outside the GenAI
component.
• Post-market monitoring focused on patient-facing failure modes, including underescalation and over-escalation (links to Question 6).
4.4 A caution on disclaimers

The paper suggests that “talk to your doctor” statements do not reduce directiveness. We agree, and
would extend this: generic disclaimers should not be credited as a safeguard for patient-facing
functions.

5. How this ts the two-axis framework

The paper proposes shifting patient-facing functions higher on the consequences axis. We
recommend instead:

Date 18/10/2026 9 of 131 FDA-2026-N-7874

fi
fi
fi
 •Treat detectability as an explicit modi er (links to Question 1), applied when the intended
users cannot evaluate the output.
• Apply it per function and output type, so a patient-facing educational function is not
uplifted merely because of its audience.
• Allow mitigation credit where a sponsor shows that safeguards work for the intended
population.
This replaces an informal shift on the severity axis with a documented, testable adjustment.

6. Evidence to support patient-facing claims

To make the assessment concrete and avoid assumptions in either direction:

1. Comprehension testing with representative patients, including lower health literacy groups.
2. Behavioural outcome testing, asking whether users take appropriate action after the output,
not only whether they understood it.
3. Subgroup performance, including dialect, language, age and literacy (element R.2).
4. Simulated multi-turn patient interactions that include minimisation, pushback and
emotional distress.
5. Observed use data after deployment, particularly on care-seeking behaviour.
7. Illustrative examples

Function Patient-facing risk Reasoning
Plain-language explanation of a Educational, non-directive, user can
Lower
diagnosis the patient already has check against clinician advice
Interpreting a lab result and telling Low detectability; user cannot
Moderate to higher
the patient what it means verify the interpretation
Advising whether to go to the ED Directive, severe, time-pressured;
Higher
for chest pain both error directions matter
Advising on a basal insulin dose Directive, severe, low reversibility,
Highest
change low detectability
Medication information with Lower than the same Independent safeguard credited, if
citations and a pharmacist check function without checks shown to work

These are illustrative and not a proposed classi cation.

8. Cautions

• Do not use “patient-facing” as a proxy for risk. The same output can be low risk for one
population and high risk for another.
• Do not assume HCPs are protected. HCPs are also subject to automation bias, so the HCP/
patient distinction should be treated as a matter of degree.
• Do not credit safeguards that are only nominal. A “review by clinician” step that is never
exercised, or a citation no one checks, offers no protection.
• Weigh bene ts explicitly. Overly conservative treatment can leave patients with worse
information from unregulated sources, which carries its own risk.
9. Recommendations

1. Do not treat patient-facing delivery as higher risk by default. Assess whether the intended
users can detect and act safely on errors.

Date 18/10/2026 10 of 131 FDA-2026-N-7874

fi
fi
fi
 2. Handle this through an explicit detectability modi er, not an informal shift on the
consequences axis.
3. Reserve the highest scrutiny for the combination of directive output, severe consequences
and low veri ability.
4. Credit safeguards only where effectiveness is demonstrated, and do not credit generic
disclaimers.
5. Require evidence on comprehension, subgroup performance and user behaviour for patientfacing functions.
6. Encourage transparency features (uncertainty, sources, options) that respect patient
capability.

Question 4 - CDRH seeks input on whether and how the distinction between generalist and
specialist physicians might inform the assessment of risk for HCP-facing GenAI-enabled
functions. Under what circumstances, if any, might risk be affected when an HCP who lacks
the relevant clinical specialist knowledge receives information that falls within a specialist
area of practice? What device characteristics or safeguards might mitigate such risks?

1. Summary position

The generalist/specialist distinction is a useful signal about the user’s ability to detect an error,
which is the same construct we proposed as the detectability modi er in Questions 1 to 3. It should
not be a standalone category or a default uplift. We recommend treating it as one input to
detectability, assessed per task and per intended user population, with the distinction handled as a
matter of degree rather than a binary.

2. Framing: what the distinction is really measuring

The paper’s concern is that a generalist may be unable to independently evaluate a specialistdomain output. That is a claim about veri cation capacity, not about clinician quality. Three points
follow:

• Expertise is task-speci c. A generalist may be highly competent on common presentations
and poorly placed on rare ones within the same specialty. The relevant variable is the user’s
ability to evaluate this output for this task, not their credential.
• The relevance is two-sided. The paper notes that such a function may meaningfully extend
access to specialty knowledge. That bene t is largest where specialist access is scarce (rural
settings, delayed referrals), which is also where the unveri ability concern is greatest. The
framework should not resolve this tension by assumption.
• Specialists are not immune. Automation bias and over-reliance are documented concerns
for HCPs generally (and agged in Appendix A, E.4). The distinction is one of degree.
3. Circumstances in which risk may be affected

Factor Risk higher when... Risk lower when...
Output rests on specialist reasoning the user cannot Output is checkable against
Veri ability
check (e.g., interpretation of complex imaging, rare- guidelines or sources the
by the user
disease differentials) generalist can read
Output supports reasoning,
Directivenes Output instructs or takes action in the specialist
offers options and ags
s domain (links to Question 2)
uncertainty

Date 18/10/2026 11 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fl
fi
fl
fi
fi
 Consequenc
Specialist errors are serious or lasting (oncology Errors are minor or readily
e and
regimens, anticoagulation) reversed
reversibility
The case is rare, atypical or outside common
Case The case is routine and well
patterns, where model errors are likelier and
atypicality within generalist experience
recognition is harder
The output informs a referral
Care
The output replaces specialist review or is reviewed by a specialist
pathway
before action
Time
Rapid decisions limit consultation Time allows second opinion
pressure

Risk is most affected in the combination of directive output, severe consequences and a user who
cannot independently assess the specialist reasoning, particularly where the device substitutes for
rather than supports specialist input.

4. Device characteristics and safeguards that could mitigate risk

4.1 Output features

• Calibrated uncertainty and explicit limits, especially where the case falls outside wellsupported ground (element S.3).
• Reasoning and evidence made inspectable, such as the ndings driving a conclusion and
the guideline or source relied on, credited only where accurate and realistically usable.
• Differentials and alternatives rather than a single answer, with serious diagnoses
prioritised (E.2).
• Explicit prompts for specialist input when de ned criteria are met (atypical features, highconsequence decisions, low con dence), without over-deferring on routine questions.
4.2 Device design

• Scope de nition by specialty and task, with refusal or redirection when a query exceeds
validated scope (S.2).
• Detection of out-of-distribution or atypical cases and a visible signal to the user when it
occurs.
• Consistency on safety-critical outputs across phrasing and user pushback (R.1).
4.3 Systemic safeguards

• Access to specialist review (e-consult, referral triggers) built into the work ow, not left to
the user’s initiative.
• Labelling and training specifying the intended user quali cation and the limits of use by
non-specialists. This is a weaker safeguard than design controls and should be credited only
modestly unless effectiveness is shown.
• Post-market monitoring strati ed by user type, so that performance and downstream
outcomes of generalist use are observable (links to Section VI).
5. Implications for evidence and for the two-axis framework

• Evaluate with the intended user. Where the labeled user is a generalist, human-AI team
performance involving generalists should be assessed, not only device-alone performance or
specialist-user performance. This connects to Questions 14 and 15 on comparators.
• Compare against the realistic counterfactual. For generalists, the relevant baseline may
be unaided generalist judgment or delayed specialist review. A device that is imperfect but
Date 18/10/2026 12 of 131 FDA-2026-N-7874

fl
fi
fi
fi
fi fi
fi
 better than that baseline may have a favourable bene t-risk pro le, while one that is worse
than a specialist but used in place of one needs careful scrutiny.
• Placement in the framework. Handle the distinction through the detectability modi er
(and the care-pathway and consequence factors above) rather than shifting functions on the
consequences axis, consistent with our Question 1 comment.
6. Cautions

• Do not use clinician credential as a proxy for veri cation ability. Evidence on actual
detection of errors should drive classi cation.
• Avoid unnecessarily narrow labelling. Restricting use to specialists may reduce harm but
also removes the access bene t the paper identi es, and may be ignored in practice.
• Beware of nominal safeguards. A “consult a specialist if unsure” line adds little if users
cannot tell when they should be unsure. That is the exact gap the generalist lacks.
• Do not treat specialty as homogeneous. Boundaries between generalist and specialist
knowledge vary by region, setting and subspecialty, which complicates a uniform rule.
7. Illustrative cases

Scenario User Principal considerations Relative risk
Guideline-based Within routine competence,
Generalist Lower
hypertension management checkable against guidelines
suggestions for an
Differential Moderate detectability,
Generalist Moderate
atypical rash with source differentials and prompts for
citations
Chemotherapy regimen dermatology referral severe and
Specialist reasoning, Highest, with
Generalist
selection lasting consequences, low specialist review
detectability
User expected
can evaluate; automation bias Lower than
Same oncology output Oncologist
remains generalist use, not
Interpretation of complex Generalist, Independent specialist check if negligible
Reduced by
echocardiogram with e-consult shown to function safeguard
built in
These are illustrative only and not a proposed classi cation.

8. Limitations and open questions

• The empirical evidence on how generalists and specialists differ in detecting GenAI errors is
limited and likely varies by task, so we ag the premise as plausible but not established.
Studies that measure actual error-detection rates by user expertise would directly inform this
question.
• Criteria for when a device should prompt specialist input (and how often it over-triggers) are
untested.
• Over-deferral can reduce the access bene t and induce alert fatigue. The trade-off between
sensitivity and burden should be evaluated rather than assumed.
• It remains unclear how a manufacturer would de ne and demonstrate the intended user’s
expertise level in labelling and testing.
9. Recommendations

1. Treat the generalist/specialist distinction as one input to the detectability modi er, assessed
per task and per intended user, not as a category or default uplift.
2. Reserve the highest scrutiny for directive, high-consequence outputs in specialist domains
where the intended user cannot independently evaluate the reasoning.

Date 18/10/2026 13 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi fl
fi
fi fi
fi
 3. Credit design-level safeguards (uncertainty, inspectable reasoning, atypical-case ags, builtin specialist review) over labelling restrictions, and only where effectiveness is
demonstrated.
4. Require evaluation with the intended user population, including human-AI team
performance for generalists, and comparison to the realistic counterfactual.
5. Stratify post-market monitoring by user expertise.
6. Support empirical research on error detection by user expertise before xing a rule.

Question 5 - For multi-turn conversational GenAI-enabled devices that may migrate from
providing “non-directive” information to “action-directing” information over the course of an
exchange, how should risk be assessed across realistic conversational trajectories? How could
the intended use of such a device be characterised when its behaviour is emergent across a
conversation?

1. Summary position

Risk for multi-turn devices should be assessed at the level of the trajectory, not the single output.
We recommend (a) classifying a device by the most directive point it can foreseeably reach
within its intended use, consistent with our Question 2 comment, (b) characterising intended use as
a bounded envelope of permitted behaviours and transitions rather than a single function label,
and (c) evaluating trajectories through pre-speci ed simulated and real conversations that include
the pressures known to cause drift. Where a device can reach a higher-risk function than it is
intended and validated for, the control is a design-level boundary, not labelling.

2. Why the single-output view fails

The paper notes that a device may begin informational and migrate to action-directing. Three
mechanisms make this a distinct problem rather than a variant of Question 2:

• Accumulated context. Each turn can be benign in isolation while the cumulative exchange
becomes directive, for example once the user has supplied personal data (Question 2,
conversational position).
• User-driven escalation. Users push for a direct answer (“just tell me what to do”), and a
device tuned for helpfulness may comply.
• Degradation over length. Appendix A (R.1) already ags degradation across long
conversations, so the property being tested at turn 2 may not hold at turn 30.
A per-function placement on Figure 1 cannot represent this, which is the gap noted in our Question
1 comment.

3. Assessing risk across trajectories

3.1 Classify by reachable maximum. The tier assigned should re ect the highest-activity, highestconsequence function the device can foreseeably reach, observed under testing, not its typical
behaviour. A device that usually informs but can be steered to instruct is classed by the instruction
capability unless a control prevents it.

3.2 Model the conversation as states and transitions. A workable structure is:

Date 18/10/2026 14 of 131 FDA-2026-N-7874

fl
fi
fl
fl
fi
 Element What is speci ed
Activity levels the device may occupy (the directiveness ladder from Question 2, plus
States
action-taking where relevant)
Permitted Which moves between states are within intended use, and under what conditions (for
transitions example, informational to action-directing only after required context is gathered)
Prohibited
Moves that would take the device outside validated scope
transitions
Triggers User behaviors or content that should cause a transition, refusal, or escalation

Risk is then assessed on each reachable state, weighted by consequence, with attention to the
transitions most likely to occur and most harmful if they do.

3.3 Test with realistic and adversarial trajectories. The pre-speci ed test set should include:

• Natural paths: typical sequences, including symptom evolution over the exchange (links to
S.1 and E.2).
• Pressure paths: repeated requests for a direct answer, user minimisation of symptoms,
emotional distress, and persuasion to exceed scope (S.1, S.2).
• Distribution shift in length: long exchanges, context switching, and returns to earlier
topics (R.1).
• Contradictory or changing information mid-conversation (R.1).
• Cumulative-drift cases in which no single turn is clearly out of scope (S.2).
Sponsors would report the distribution of states reached and the rate of prohibited transitions, not
a single pass/fail label.

3.4 Seek real-use evidence. Simulated trajectories (including synthetic patient agents) are scalable
but may not match real user behaviour, and the paper’s Question 13 raises circularity when
synthetic generation and the device are of the same model class. Real or clinically representative
conversations, such as retrospective review or shadow deployment (Section V.C), should be used to
check that simulated trajectories resemble observed ones.

4. Characterising intended use when behaviour is emergent

We suggest intended use be stated at three layers:

1. Purpose and population: what the device is for and who uses it, as for any device.
2. Behavioural envelope: the maximum activity level and consequence class the device is
designed and validated to reach, the clinical domains in scope, and the actions it will never
take.
3. Boundary and handoff rules: what the device does when a conversation approaches the
envelope’s edge (refusal, redirection, escalation to a clinician).
This lets intended use be testable. A claim such as “provides health information” is too loose to
evaluate, whereas “provides information up to and including general contextualised guidance, and
escalates to a clinician before any speci c dosing or triage instruction” can be checked against
trajectories.

Two consequences follow:

• Labelling must match behaviour. If trajectory testing shows the device reaches actiondirecting outputs that labelling does not claim, the intended use is understated and the
classi cation should follow the observed behaviour (consistent with Question 2).
Date 18/10/2026 15 of 131 FDA-2026-N-7874

fi
fi
fi fi
 • Intended use cannot be de ned only by what the sponsor aims for. For generative
systems, the envelope should be established by what testing shows the device does under
pressure.
5. Design-level controls that would reduce risk

• Hard boundaries on speci c outputs (dosing, triage dispositions) enforced outside the
language model, so they do not depend on conversation context.
• State tracking that recognises when accumulated context has moved the exchange toward a
higher-risk function, and applies the relevant controls from that point.
• Required context gathering before any directive output that depends on individual facts
(age, pregnancy, medications, renal function) (E.2, E.3).
• Stable safety behaviour under pushback: escalation and refusal that do not weaken as the
user insists (S.1, R.1).
• Periodic re-grounding in long conversations (restating limits, re-checking key facts) with
evidence that it helps.
• Clear transitions to the user: signalling when the device is moving from information to
guidance, so the user can see the change.
These should be credited as mitigations only where trajectory testing shows they hold, in line with
our position that nominal safeguards should not count.

6. How this ts the two-axis framework

• Place the device by its reachable maximum on the activity axis, and assess the
consequences axis against the highest-consequence situations it can reach.
• Apply the modi ers from our Question 1 comment (detectability, time pressure,
reversibility, independent safeguards) to the reachable state, not the typical one.
• Treat boundary controls as the main route to a lower classi cation. A device that
demonstrably cannot reach action-directing outputs may be classed below one that can,
whatever its intended aims.
• Ask CDRH to clarify how this works for multi-function devices, where a conversation may
cross function boundaries (also noted in our Question 1 comment).
7. Illustrative cases

Reachable
Scenario Trajectory Consideration
maximum
ActionSymptom Starts with general information, user Class on triage capability unless
directing
information supplies chest-pain history, then asks a validated escalation rule or
triage,
chatbot “should I go to the ER?” hard boundary applies
severe
Medication Action- Needs context gathering and
Explains a drug, user supplies renal
information directing dose limits outside the model, or
function and asks for a dose
assistant dosing a refusal boundary
EducationShould hold its refusal and
only User repeatedly asks for a speci c Prohibited
redirect under pressure, shown
diabetes insulin adjustment transition
by pressure-path testing
coach
Clinician Information
Stays in guideline summaries Lower tier if long-conversation
reference al, limited to
throughout behavior is shown stable
tool moderate

Date 18/10/2026 16 of 131 FDA-2026-N-7874

fi fi fi fi fi fi
These are illustrative only and not a proposed classi cation.

8. Cautions

• Do not rely on turn-level testing alone. It will miss cumulative drift by construction.
• Avoid over-restricting. Boundaries that block legitimate in-scope help (over-refusal, S.2)
reduce bene t and may push users to worse sources.
• Do not treat the user’s framing as intended use. Real users will use the device in ways the
sponsor did not intend, so foreseeable misuse belongs in the envelope analysis.
• Beware of an unbounded test space. Conversations are effectively in nite, so the aim is
coverage of risk-relevant trajectory classes with pre-speci ed criteria, not exhaustive
enumeration.
9. Limitations and open questions

• There is no agreed method for sampling or enumerating realistic trajectories, and coverage
criteria for “suf cient” trajectory testing are unde ned.
• The validity of simulated users as proxies for real users is not established, and the extent of
drift under real use is an empirical question we do not claim to answer.
• It is unclear how to set acceptable rates of transitions into higher-risk states, and whether
such rates should vary by consequence class.
• Whether state-and-transition characterisations of intended use can be written precisely
enough for review, without becoming brittle, would bene t from pilot testing with sponsors
and reviewers.
• Inter-rater reliability of assigning conversation segments to activity levels would need
evaluation.
10. Recommendations

1. Assess risk across trajectories, and classify by the most directive and consequential state a
device can foreseeably reach.
2. Characterise intended use as purpose, behavioural envelope, and boundary and handoff
rules, so it is testable.
3. Pre-specify trajectory test sets covering natural, pressure, long-conversation, and
cumulative-drift paths, and report state distributions and prohibited-transition rates.
4. Validate simulated trajectories against real or clinically representative conversations.
5. Credit design-level boundaries (enforced outside the model) over labelling, and only where
testing shows they hold.
6. Require labelling to match observed behaviour, and treat foreseeable misuse as part of the
envelope analysis.
7. Clarify device-level aggregation for multi-function and multi-turn devices.

Question 6 - For GenAI-enabled care escalation functions, CDRH is considering how the
evaluation may account for both under-escalation and over-escalation. How could
manufacturers characterise and weigh these two directions of error, given that they may not
be commensurable and that acceptable trade-offs may vary by clinical context?

1. Summary position

Under-escalation and over-escalation should be characterised separately and reported
separately, and should not be collapsed into a single accuracy or F-score. We recommend that
Date 18/10/2026 17 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
acceptable operating points be pre-speci ed per clinical context from a documented harm
analysis, that under-escalation on time-critical conditions carry a pre-speci ed, stricter oor,
and that over-escalation be assessed both per encounter and at population level, since its harms
accumulate across users. Where the two errors cannot be put on a common scale, the framework
should make the trade-off explicit and justi ed rather than hiding it in an aggregate metric.

2. Why the two errors are not commensurable

The paper identi es the key asymmetries. They differ in several ways:

Dimension Under-escalation Over-escalation
Delayed treatment, potentially Anxiety, unnecessary tests, ED crowding, cost,
Typical harm
serious or irreversible erosion of trust
The individual, and also the system and other
Who bears it The individual patient
patients
Visibility Often silent until harm occurs Often visible (an ED visit happened)
Timescale Often acute Often cumulative, over repeated interactions
Often high per event, but not always (invasive
Reversibility Frequently low
workup)

Two points follow. First, a simple weighting such as “one missed emergency equals N unnecessary
visits” requires a value judgment that is context-dependent and rarely agreed. Second, the paper
notes that over-escalation can erode trust and reduce appropriate care-seeking over time. That
means over-escalation can feed back into under-escalation, so the two are not fully independent.

3. Characterising each direction of error

3.1 Report them separately. For each function, report sensitivity-type and speci city-type
measures against a de ned reference standard, strati ed by the conditions that matter:

• Under-escalation: miss rate for conditions that warrant escalation, broken down by timecriticality (e.g., stroke, sepsis, myocardial infarction versus conditions where a delay of
days is tolerable).
• Over-escalation: rate of escalation to a higher level of care than indicated, broken down by
level of care (ED versus urgent care versus routine appointment) and by cost of the
unnecessary action.
3.2 Grade the severity of each miss. Not all under-escalations are equal. A framework could
distinguish:

• Level of under-triage: recommending self-care when the ED was needed is more severe
than recommending a routine visit when urgent care was needed.
• Delay introduced: hours versus days.
• Outcome relevance: whether the delay plausibly changes prognosis.
The same grading applies to over-escalation (recommending the ED when self-care suf ced is
worse than recommending urgent care when a routine visit suf ced).

3.3 Evaluate the full trajectory, not only the nal recommendation. Per our Question 5
comment, assess behaviour across realistic conversations, including:

• Time to escalation in evolving presentations (S.1).
Date 18/10/2026 18 of 131 FDA-2026-N-7874

fl
fi
fi
fi
fi
fi
fi
fi
fi
fi fi
 • Resistance to minimisation, where a user plays down symptoms.
• Stability under pushback, where a user resists a correct escalation.
• Over-reassurance and over-alarm as paired failure modes in the same scenarios.
3.4 Assess the quality of the escalation, not only the decision. A correct decision delivered
unclearly can still fail. Elements include clarity, actionability, handoff information, and tone (S.1,
E.4).

4. Weighing the errors when they are not commensurable

We suggest three approaches, which can be combined, rather than one aggregate score.

4.1 Constraint-based approach (recommended primary). Set a non-negotiable ceiling on
under-escalation for de ned high-consequence, time-critical conditions, then optimise overescalation subject to that constraint. This avoids trading a missed emergency against a number of
unnecessary visits, which is the comparison that is hardest to defend.

4.2 Context-speci c operating points. Pre-specify the acceptable operating point by clinical
context. For example:

Context Posture Rationale (illustrative)
Possible stroke, MI, sepsis,
Strongly favor sensitivity Delay is costly and often irreversible
anaphylaxis
Self-limiting minor Low harm either way, and over-escalation
More balanced
complaints wastes resources
Favor sensitivity, with
Pediatric fever in infants Serious illness may present subtly
de ned criteria
Chronic condition follow- Depends on available Other monitoring may catch missed cases
up safeguards
The sponsor would document the clinical rationale, and the choice would be reviewed rather than
left to the manufacturer.

4.3 Explicit harm-weighted analysis as a supplement. Where a common metric is wanted, use a
decision-analytic approach (expected harm or net bene t under stated weights), but present it as
sensitivity analysis across a range of plausible weights, not a single weighting. If conclusions
hold across the range, that is more persuasive than a single number. If they do not, the dependence
on the value judgment should be visible to reviewers.

5. Population-level effects of over-escalation

Over-escalation is easy to dismiss per encounter but matters when a device is deployed widely. We
suggest that evaluation consider:

• Aggregate load: projected additional ED or clinic visits at the expected deployment scale,
including the intended user population’s baseline rates.
• Correlated behaviour: a device systematically biased toward escalation produces the same
unnecessary referral for many users, unlike independent clinician variation (links to the
scale and correlated error point in Question 1).
• Trust and adherence effects: whether repeated unnecessary escalation changes later careseeking. This is dif cult to measure premarket and is a natural target for post market
monitoring.

Date 18/10/2026 19 of 131 FDA-2026-N-7874

fi
fi
fi
fi fi
 • Equity: whether the burden of over-escalation (cost, time off work, travel) or underescalation falls unevenly across subgroups (R.2).
6. Choosing the reference standard and comparator

• Reference standard. Outcome-based truth (what was ultimately diagnosed) is stronger than
expert opinion about what should have happened, but is only available in some data sets,
and can be confounded where treatment altered the outcome. Where expert adjudication is
used, independence and the handling of disagreement should be documented (consistent
with the paper’s adjudication principles).
• Comparator. The relevant benchmark may not be an ideal triage decision but the realistic
alternative, such as unaided patient decisions, nurse triage lines, or existing symptom
checkers (links to Question 15). A device that under-escalates at a rate similar to current
practice but over-escalates less may still offer bene t, and the evaluation should be able to
show that.
• Human-AI team. Where a clinician reviews the output, assess combined performance,
since the clinician may correct over-escalation more easily than under-escalation, or vice
versa.
7. Statistical considerations

• Rare, high-consequence events make under-escalation hard to estimate precisely.
Con dence bounds on miss rates for time-critical conditions should be reported, and the
sample size justi ed for the upper bound, not only the point estimate.
• Synthetic or simulated cases can enrich rare presentations, but circularity risks apply
where the generator shares a model class with the device (Question 13), so real or clinically
representative cases should anchor the critical estimates.
• Prevalence dependence. Over-escalation burden depends on how common true
emergencies are in the deployed population, so the performance estimate should be reported
with the assumed prevalence and re-examined if the population differs.
• Multiplicity. Reporting many condition-level metrics without pre-speci cation invites
selective presentation, so the critical conditions and thresholds should be pre-speci ed.
8. How this ts the two-axis framework and the benchmarking elements

• Risk tiering. Escalation functions are typically action-directing, and the consequences axis
will often be at the severe end for time-critical conditions. The tier should be read alongside
the detectability modi er (a patient cannot easily tell a wrong disposition) and time
pressure (Question 1).
• Benchmarking. S.1 already names both error directions. We suggest it specify paired
reporting (separate under- and over-escalation results), a time-critical subset with a prespeci ed acceptance threshold, and trajectory-based tests.
• Post-market. Monitor care-seeking outcomes in both directions, including cases where
users did not escalate after advice not to, and escalation rates relative to expectation.
9. Illustrative cases

Scenario Principal concern Suggested emphasis
Chest-pain Prespeci ed sensitivity oor for acute coronary
Missed MI versus
triage to a syndrome, then minimize over-escalation, with
unnecessary ED visits
patient trajectory tests for minimization
Pediatric sore Missed complications
More balanced operating point, with explicit red- ag
throat advice to versus unnecessary
criteria
a parent appointments
Date 18/10/2026 20 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi fi
fl fl fi fi fi
Post-discharge Missed deterioration
Constraint on missed deterioration, with workload
symptom versus alert fatigue for
impact measured
monitoring the care team
Stroke symptom Delay is costly and time- Very high sensitivity requirement, with over-escalation
recognition critical accepted within limits

These are illustrative only and not a proposed classi cation.

10. Cautions

• Do not use a single accuracy or F1 score. It hides the asymmetry and can be improved by
trading one error for the other.
• Do not let over-escalation become a safe default. A device that always escalates is trivially
sensitive but is not safe or effective at the system level, and erodes trust.
• Do not assume the trade-off is xed. It depends on the deployment setting, for example
whether the ED is a few minutes away or hours away, and whether alternatives exist.
• Avoid pseudo-precision in harm weights. The relative harms are uncertain, so show the
range.
11. Limitations and open questions

• There is no consensus method for weighting the two error types, and we have deliberately
not proposed numerical weights. Stakeholder processes (clinicians, patients, health systems)
may be needed for high-stakes contexts.
• Evidence on how over-escalation affects later care-seeking is limited, so treating it as a harm
in evaluation requires care about what can be demonstrated premarket.
• The degree to which a constraint-based oor should vary with the evidence base for each
condition is unsettled.
• Whether sensitivity oors should be set by CDRH, by consensus standards, or by sponsors
with review is a governance question we ag rather than resolve.
• Outcome-based reference standards are often unavailable for rare conditions, which limits
what can be validated before deployment.
11a. Recommendations

1. Report under-escalation and over-escalation separately, strati ed by time-criticality and
level of care, and never collapse them into one score.
2. Use a constraint-based primary approach: a pre-speci ed ceiling on under-escalation for
high-consequence, time-critical conditions, then minimise over-escalation within it.
3. Pre-specify context-speci c operating points with documented clinical rationale, subject to
review.
4. Where an aggregate is wanted, present a harm-weighted analysis as sensitivity analysis
across plausible weights.
5. Assess over-escalation at the population level, including load, correlated behaviour, trust
effects and equity.
6. Evaluate full trajectories, including minimisation and pushback, and the quality of the
escalation itself.
7. Use realistic comparators and report con dence bounds on rare, high-consequence misses,
with real or clinically representative data anchoring the critical estimates.
8. Strengthen S.1 to require paired reporting and a time-critical subset with pre-speci ed
thresholds, and extend post-market monitoring to both error directions.

Date 18/10/2026 21 of 131 FDA-2026-N-7874

fl fi fi
fi fl
fl fi fi fi
fi
 Question - 7 Is the competency-based approach described above, i.e., device benchmarking
followed by clinical confirmation, a useful and appropriate framework for evaluating GenAIenabled devices?

1. Summary position

Yes, with conditions. The two-stage structure is a sound organising framework: broad non-clinical
benchmarking to characterise behaviour across a large input space, then clinical con rmation to
check that behaviour holds in real use. It ts the problem the paper identi es, that exhaustive input
testing is infeasible. Its usefulness depends on whether benchmark performance can be shown to
predict real-world performance, and on how the clinician analogy is applied. We recommend
adopting the structure as a framework, not as a xed sequence of mandatory steps, and making the
link between the two stages an explicit evidentiary requirement.

2. What the approach gets right

• It matches the evaluation problem. Open-ended inputs and variable outputs make
representative-sample testing inadequate on its own. Structured capability assessment plus
real-use con rmation is a reasonable response.
• It evaluates the deployed device, not the foundation model in isolation. This is the right
unit of analysis, since behaviour depends on prompts, retrieval, guardrails and interface.
• It is risk-proportionate by design. Evidence scales with the two-axis tier, and the paper
states that clinical con rmation need not mean a prospective trial in every case.
• It creates a reusable baseline. Pre-speci ed benchmarks support re-benchmarking after
modi cations (Section VI.C), which addresses the change-control problem directly.
• It pre-speci es methods and acceptance criteria, consistent with non-clinical testing
norms, and requires adjudicator independence.
3. Where the framework is vulnerable

3.1 Construct validity of benchmarks is the central weakness. The two-stage logic assumes that
benchmark performance is informative about real-world safety and effectiveness. The paper
acknowledges contamination, saturation and limited representativeness (Question 10). Prior work in
this area has shown that high scores on knowledge examinations do not necessarily translate into
safe performance in open-ended interaction, though we do not cite speci c studies here. Without
evidence of predictive validity, benchmarking can become a gate that measures test-taking rather
than clinical competence.

3.2 The clinician analogy has limits. The analogy is useful at a high level, but human licensure
rests on features that do not transfer directly:

Feature of clinician credentialing Transfer to GenAI devices
Exams validated against later practice over
Benchmark validity is largely unestablished
decades
Stable individual whose competence Device behavior can shift with a model, prompt or
changes slowly retrieval update
Supervised practice with graded
Possible via staged deployment, but no standard exists
independence
Professional, legal and reputational
Must be built (the Freyer et al. point the paper cites)
accountability
Date 18/10/2026 22 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
 Errors are individual and uncorrelated Device errors are systematic and repeat across all users
Training through extended socialization
Safety behavior must be engineered and tested
into norms

The last two rows matter most. A clinician’s error is idiosyncratic, whereas a device’s error is
replicated at scale, which argues for a higher evidence bar on safety-critical behaviours than the
analogy alone would suggest.

3.2a Competence is not the same as safe performance in context. Clinician credentialing
assumes a supervised, institutional environment. A device deployed directly to patients lacks that
scaffolding, so benchmarking should be paired with evaluation of the deployment context, not
treated as a substitute.

3.3 The “pass the exam” framing risks optimisation to the test. Sponsors can tune a device to
the benchmark. This is a known problem with xed public benchmarks and applies equally to
sponsor-developed ones (Question 10). Mitigations include sequestered, refreshed test sets,
independent adjudication, and evaluation on held-out scenario types.

3.4 Clinical con rmation as described is weaker than the label suggests. Several listed
approaches (retrospective evaluation, shadow deployment, clinician adjudication) do not measure
effect on patient outcomes or on clinician and patient behaviour. They con rm that outputs look
appropriate to reviewers, not that using the device improves care. For action-directing or actiontaking functions, this gap matters.

3.5 Real-world interaction effects fall between the stages. Automation bias, changes in clinician
work ow, and patient behaviour after an output are not captured by benchmarks, and are only
captured by con rmation methods that include real users acting on outputs.

4. Recommendations on how the framework should be applied

1. Make the benchmark-to-reality link an explicit requirement. Sponsors should provide
evidence that benchmark performance on the relevant elements predicts performance in the
clinical con rmation stage for their device, for example by showing concordance between
the two on a shared case set. Where the link is weak, clinical con rmation should carry more
weight.
2. Scale the weight of each stage to the risk tier. For lower tiers, benchmarking plus
retrospective evaluation may suf ce. For action-directing or action-taking functions at
higher consequence levels, clinical con rmation involving real or realistic user behaviour
(including prospective study where warranted) should be the primary evidence, with
benchmarking supporting.
3. Distinguish safety-critical from other elements. Failure on safety-critical elements (S.1,
S.2, and the safety-critical portion of R.1) should not be offset by strong performance on
pro ciency elements. We suggest these be treated as gating conditions with pre-speci ed
thresholds, not averaged in a composite.
4. Require sequestered or refreshed test material, with documentation of how
contamination was assessed, and independent adjudication consistent with the paper’s
principles.
5. Evaluate the human-AI system where humans are in the loop. Con rmation should
measure combined performance and behaviour, not only device-alone outputs (Questions 14
and 15).

Date 18/10/2026 23 of 131 FDA-2026-N-7874

fi
fi fi
fi
fi
fl
fi fi
fi
fi
fi
fi
 6. Treat sequencing as exible. Benchmarking and con rmation are likely iterative:
con rmation results should feed back into benchmark design, particularly to add failure
modes seen in real use.
7. Carry the framework into post-market. Use the same elements for re-benchmarking and
monitor whether premarket benchmark results continue to track real-world performance.
8. De ne the accountability counterpart. The competency analogy implies consequences for
failure to maintain competence. We suggest CDRH clarify how sponsor accountability,
including for third-party model changes, would operate alongside this approach.
5. Applicability across device types

The approach seems best suited to devices with de ned clinical tasks where reference standards or
clinician comparators can be established. It is likely harder to apply to:

• Very open-ended general-purpose assistants, where the scope cannot be bounded enough
to de ne benchmarks. For such devices, the behavioural-envelope characterisation from our
Question 5 comment would be needed rst.
• Devices for rare conditions, where real-world data for con rmation is scarce.
• Agentic devices, where multi-step action and tool use require additional elements (A.1) and
likely different con rmation methods (Question 26).
• Non-text architectures, such as multimodal and world models (Question 17), where the
clinician analogy and benchmark types may transfer less directly.
6. Limitations and open questions

• There is no established evidence on how well the proposed benchmarking elements predict
real-world safety. This is an empirical question and we do not claim to answer it, but it
should be studied early, ideally with pilot programs.
• It is unclear how many benchmark elements and how much coverage are enough for a given
tier, and whether the elements as listed are independent (some overlap, for example S.3 and
E.1).
• The costs of the approach for smaller sponsors are uncertain. The least burdensome principle
suggests that shared, sequestered benchmark assets and third-party roles (Question 16) could
reduce duplication, but also risk concentrating in uence in whoever maintains them.
• Whether adequate statistical frameworks exist for combining benchmark and con rmation
evidence is unresolved (Question 12).
• Pilot testing with real submissions would reveal whether the approach is workable in review,
which a discussion paper cannot establish.
7. Summary of recommendations

1. Adopt the competency-based framework as an organising structure, with exible
sequencing.
2. Require evidence that benchmark results predict real-world performance for the device in
question.
3. Weight clinical con rmation more heavily as risk rises, and use real or realistic user
behaviour for action-directing functions.
4. Treat safety-critical elements as gating conditions, not components of an averaged score.
5. Require sequestered or refreshed test sets, contamination assessment and independent
adjudication.
6. Evaluate human-AI team performance where applicable.
7. Reuse the same elements in post-market re-benchmarking and check that premarket
benchmarks remain predictive.
8. Clarify accountability, and pilot the approach before it is formalised.
Date 18/10/2026 24 of 131 FDA-2026-N-7874

fi fl fi
fl
fi fi
fi fi fl
fi fi fi
fi
 Question 8 - How might the two-axis risk framework described in Section IV be considered
within the competency-based approach described above to help determine the level of
evidence needed for a premarket submission?

1. Summary position

The two-axis framework should set the evidence tier, and the tier should determine three things:
which benchmarking elements apply, how demanding the benchmark conditions and acceptance
criteria are, and how much weight and rigor clinical con rmation carries. We recommend a
published tier-to-evidence mapping that is a default and not a rule, with a documented route for
sponsors to justify departures. Tiering should use the modi ed placement from our Questions 1 to 6
comments (base cell, bounded modi ers, reachable maximum), not the raw cell. The framework
determines the minimum expected evidence. It should not be used to excuse missing evidence on
safety-critical elements at any tier.

2. What the paper already says

The paper states that device activity and consequences “could help inform the nature, rigor, and
amount of evidence needed,” including the elements benchmarked, the range and dif culty of test
conditions, and the extent of clinical con rmation. It does not say how. The comment below
proposes a concrete structure for that link, offered for discussion and not as a validated scheme.

3. Four dimensions of evidence the tier could govern

Dimension What the tier changes
Element
Which benchmarking elements (S, E, R, A) are required versus optional
selection
Benchmark Breadth and dif culty of test conditions, adversarial and trajectory coverage,
stringency sequestration and independence of test material
Acceptance Strictness of thresholds, especially on safety-critical elements, and whether the
criteria comparator is a median clinician or a more demanding standard
Clinical Which method (retrospective, shadow, standardized patient, clinician adjudication,
con rmation prospective) and how much it carries

4. Illustrative tier-to-evidence mapping

Using the 1 to 6 tier scale from our Question 1 sketch (placeholder values, not proposed thresholds):

Tier Typical pro le Elements Benchmarking Clinical con rmation
Prespeci ed tests, standard
Non-directive, S.2, S.3, E.1, Retrospective
1 to adversarial set; sponsor-developed
limited E.4; R.1 as evaluation on real or
2 assets acceptable with
consequence relevant representative inputs
documentation

Date 18/10/2026 25 of 131 FDA-2026-N-7874

fi
fi
fi fi
fi fi fi fi fi fi
 Action-directing Retrospective plus
Add S.1, E.2, Trajectory and pressure-path testing;
or supervised shadow deployment or
3 to E.3 as some sequestered or independently
action-taking, independent clinician
4 relevant, and maintained material; independent
moderate adjudication of real
R.2 adjudication
consequence cases
Action-directing All
Real-use evidence
or autonomous, applicable Sequestered, refreshed test sets;
involving user
5 to severe elements, independent adjudication; extensive
behavior, up to
6 consequence, or with A.1 for subgroup and robustness testing;
prospective study
low agentic gating thresholds on safety elements
where warranted
detectability devices

This is a gradient, not a set of cliffs. The point is that each step up adds evidence types, not only
larger samples.

5. How the modi ers and reachable maximum feed in

• Use the reachable maximum. A multi-turn device should be tiered by the most directive
and consequential state it can foreseeably reach (Question 5), so evidence requirements
follow what the device can do, not what it usually does.
• Modi ers change evidence, not only the tier number. Low detectability argues for more
weight on clinical con rmation involving real users, since benchmarks cannot show whether
errors are caught. Time pressure argues for human-factors evidence. Low reversibility
argues for stricter acceptance thresholds on the relevant failure modes.
• Credited safeguards need evidence too. A tier reduction from an independent safeguard
should require testing the safeguard itself, so lower evidence on the model is offset by
evidence on the control.
6. Elements that should be gated regardless of tier

The tier should scale rigor, not remove baseline safety evidence. We suggest:

• Scope boundary testing (S.2) applies at every tier, since scope drift moves a device into a
higher tier by de nition.
• Calibration and uncertainty behaviour (S.3) applies wherever outputs reach users.
• For any function where escalation matters, S.1 applies with paired under- and overescalation reporting (Question 6).
• Failure on a safety-critical element should not be offset by strong pro ciency scores, as in
our Question 7 comment.
7. How the tier interacts with the two stages

Our Question 7 comment recommended weighting clinical con rmation more heavily as risk rises.
This yields a simple principle:

• Low tiers: benchmarking carries most of the evidentiary weight, with con rmation as a
check.
• Middle tiers: benchmarking and con rmation carry comparable weight, with concordance
between them shown.
• High tiers: con rmation involving realistic user behaviour carries the primary weight, and
benchmarking supports it and supplies coverage of rare scenarios.
The same tier should also determine the post market expectations (Section VI): higher tiers
warrant more frequent re-benchmarking, tighter degradation thresholds and clinician sample review.
Date 18/10/2026 26 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi fi
fi
 8. Cautions

• Avoid a purely mechanical lookup. A table that maps a cell to a xed evidence package
will mis t unusual devices and invite sponsors to engineer their classi cation. A default
mapping with a documented justi cation route is more robust.
• Avoid gaming the tier. Because tier determines burden, sponsors have an incentive to
understate directiveness or scope. This is the reason we recommend classi cation based on
observed behaviour and the reachable maximum, not on labelling alone, and an ambiguity
rule that classes at the higher level.
• Do not treat the tier as a risk-bene t judgment. It describes risk of an incorrect output. A
function with large potential bene t may still warrant a high evidence tier, and the bene t
side should be assessed alongside it.
• Avoid false precision. Tier boundaries are heuristics, so evidence requirements should not
change abruptly across an adjacent cell.
• Consider the least burdensome principle. The mapping should be defensible as
proportionate, with lower tiers genuinely lighter, so the framework does not default to
maximum evidence for everything.
9. Illustrative cases

Device Tiering Evidence emphasis
considerations
Plain-language Non-directive, limited, Scope, calibration, comprehension testing;
condition education no foreseeable drift to retrospective evaluation
tool
Lab-result directing
Informational, Element E.3 accuracy, comprehension and
interpretation for moderate, low behavioral testing, subgroup performance;
patients
Chest-pain triage for detectability
Action-directing, con rmation
Paired withreporting
escalation real patient inputs
with a sensitivity oor,
patients severe, time pressure, trajectory and pressure tests, con rmation with
HCP-supervised low detectability
Action-taking, real-useand
limited, Dosing evidence
contraindication accuracy (E.1, E.3),
antibiotic prescribing reversible, scope tests; retrospective plus clinician
for
Autonomous order-set Action-taking, severe, adjudication
con rmed strep independent check Highest tier: A.1 if agentic, gating thresholds,
initiation in stroke time pressure extensive robustness, prospective or equivalent
work ow real-use evidence
These are illustrative only and not a proposed classi cation.

10. Limitations and open questions

• The tier-to-evidence mapping above is a proposal with no empirical basis. Whether tiers
map sensibly to evidence burden would need pilot application to real submissions and
assessment of reviewer agreement.
• Inter-rater reliability of tier assignment (base cell plus modi ers) is untested and directly
affects fairness of the evidence burden.
• It is unclear how to set quantitative acceptance thresholds by tier, and whether this should be
done by CDRH, consensus standards, or sponsor proposal with review.
• The interaction of tiering with multi-function devices is unresolved: if a device spans tiers,
evidence could be tiered per function, or set by the highest function. We lean toward the
former with a device-level check, but ag it as open.
• The approach assumes the paper’s benchmarking elements are adequate and nonoverlapping (Question 9), which is not established.
11. Recommendations

Date 18/10/2026 27 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fl
fl
fi
fi
fi fi
fi
fi
fl
fi
 1. Use the modi ed tier (base placement, bounded modi ers, reachable maximum) to set
evidence expectations, in a published default mapping with a justi cation route for
departures.
2. Let the tier govern four things: element selection, benchmark stringency, acceptance criteria,
and clinical con rmation method and weight.
3. Shift evidentiary weight from benchmarking toward real-use con rmation as the tier rises.
4. Keep baseline safety elements (S.1 where relevant, S.2, S.3) in force at every tier, and treat
safety-critical failures as gating.
5. Require evidence on any safeguard credited for a tier reduction.
6. Link post market expectations to the same tier.
7. Classify on observed behaviour and use an ambiguity rule to limit tier gaming.
8. Pilot the mapping and measure inter-rater reliability of tiering before formalising it.

Question 9 - Would a benchmarking structure such as the one described above be likely to
provide adequate evidence of clinical knowledge, analytic capabilities, safety behaviour,
communication, and generalisability to support a reasonable assurance of safety and
effectiveness? Are there elements that are missing, redundant, or inappropriately categorised?
Are there externally developed standards that could be leveraged?

1. Summary position

The benchmarking structure is a good taxonomy of what to test, but benchmarking alone is unlikely
to provide adequate evidence of safety and effectiveness. It characterises capability under controlled
conditions. It does not show that users act appropriately on outputs, that patient outcomes improve,
or that benchmark performance predicts real-world behaviour (Questions 7 and 10). We recommend
treating benchmarking as necessary but not suf cient, and making several changes to the element
set: add elements for human-factors and user-reliance behaviour, privacy and data handling,
security, transparency and traceability, and system-level reliability; clarify overlaps (S.3/E.1,
S.1/E.2, R.1 spanning several others); and reconsider the placement of communication and
subgroup performance. Several existing standards and frameworks could be leveraged, though I
have not veri ed their current versions and cite them by name only.

2. Is the structure adequate for the stated purposes?

Coverage by
Purpose current Assessment
elements
Clinical Reasonable for knowledge and guideline delity. Risk of measuring
E.1
knowledge recall, not applied reasoning.
Analytic
E.2, E.3 Good coverage of reasoning under uncertainty and quantitative tasks.
capability
Safety Strong conceptually, with paired failure modes (under/over-escalation,
S.1 to S.3
behavior under/over-refusal).
Covers comprehension and tone, but measuring comprehension
Communi
E.4 requires human participants, which is not “high-throughput”
cation
benchmarking.
Generaliz Good on robustness and subgroups. Weak on shift in deployment
R.1, R.2
ability setting, work ow and population over time.

Date 18/10/2026 28 of 131 FDA-2026-N-7874

fi
fi
fl fi fi fi fi fi fi
 The structure addresses whether the device behaves well on pre-speci ed tests. It does not address
whether the device is used well, which is where several of the paper’s own concerns (automation
bias, patient reliance, disengagement) sit. Adequacy therefore depends on the pairing with clinical
con rmation, and on the evidence that links the two.

3. Elements that may be missing

1. User reliance and automation bias. E.4 mentions automation bias as a risk, but it is a
property of the human-device system and cannot be measured by scoring outputs alone. It
needs human-subject methods (simulated or real use) and warrants its own element or a
clearly designated con rmation requirement.
2. Transparency, traceability and faithfulness of explanation. Our Question 1 comment
treated traceability as a conditional mitigator. If it is credited anywhere in risk tiering, it
should be tested: whether citations exist, are accurate and support the claim made, and
whether stated reasoning re ects the actual basis for the output.
3. Privacy, data handling and con dentiality. Conversational devices elicit sensitive
information. Leakage, retention, and unintended disclosure across sessions or users are
safety-relevant but absent.
4. Cybersecurity and adversarial robustness beyond prompts. A.1 and S.2 mention prompt
injection, but security covers more: data poisoning in retrieval sources, tool and API
compromise, and denial of service. Existing device cybersecurity expectations are relevant
here and the interface should be made explicit.
5. System reliability and operational behaviour. Latency, outages, degraded modes, and
failure handling matter, particularly in time-pressured settings. What does the user see when
retrieval fails or the model is unavailable?
6. Currency of knowledge. E.1 mentions “current” knowledge, but there is no element for
how the device handles knowledge updates, guideline changes, or retrieval-source quality
control. This links to post-market re-benchmarking.
7. Equity beyond subgroup accuracy. R.2 covers performance consistency. It does not cover
differential access (language support, accessibility for disabilities) or differences in the
quality of communication, though these may be partly captured by R.2 and E.4 and could be
clari ed instead of added.
8. Consistency with documentation and labelling. Whether observed behaviour matches the
stated intended use, as in our Question 5 comment.
I would prioritise 1, 2 and 3 as additions, and treat 4 to 6 as clari cations of existing elements or
cross-references to other device requirements.

4. Redundancy and overlap

• S.3 and E.1 both address awareness of knowledge limits and acknowledging uncertainty.
E.1 says the device is “aware of its own knowledge limitations,” and S.3 covers calibration
and uncertainty communication. We suggest E.1 focus on knowledge accuracy and S.3 own
all uncertainty behaviour.
• S.1 and E.2 both involve recognising evolving presentations and avoiding premature
closure. They differ in emphasis (escalation versus diagnostic reasoning), but the test
scenarios will overlap. Sponsors should be able to reuse cases, and CDRH should say so to
avoid duplicate testing.
• S.2 and A.1 share prompt injection and boundary adherence. A.1 could cross-reference S.2
and cover only what is agent-speci c (planning, tool use, oversight checkpoints).
• R.1 and the rest. R.1 is described as consistency of “safety and clinical pro ciency
properties,” so it is a cross-cutting property rather than a parallel element. It is better treated

Date 18/10/2026 29 of 131 FDA-2026-N-7874

fi fi fi
fi fl fi fi fi
fi
 as a test condition applied to other elements (repeat runs, paraphrase, ordering, long
conversations) than as a separate item to score. The same is true of R.2 for subgroup
strati cation.
• E.2 versus a “uses outputs appropriately” element. Information gathering and analysis
may be better split into data gathering (asking good questions) and reasoning (using the
information), since these fail differently.
5. Possible categorisation issues

• Generalisability as a category label. R.1 and R.2 describe consistency and equity of
performance rather than generalisability in the statistical sense (transport to new settings,
populations and time). Real generalisability across sites, health systems, EHR formats and
patient populations is not clearly covered. Consider renaming to “Robustness and
consistency” and adding a deployment-transport element.
• Communication (E.4) under Clinical Pro ciency. Communication quality is partly a
safety property (misleading or coercive language, over-reassurance). It could be split:
safety-relevant communication moves under Safety, and comprehension and health literacy
stay with pro ciency or move to human-subject testing.
• Calibration under Safety. Appropriate, but calibration is measurable in quantitative terms
(con dence versus accuracy) and qualitative terms (hedging language). The paper focuses
on the qualitative. Both should be speci ed.
• “Safety” as a heading. Some listed elements measure behaviour under pressure and others
measure failure categories. A cleaner split might be failure modes (harmful content, overreassurance, over-refusal) versus control properties (scope, escalation). This is a
presentational point, not a substantive one.
• Applicability by device type. The paper says elements would be chosen by intended use
and risk. A table mapping device type and tier to default elements would improve
consistency (links to our Question 8 comment).
6. Adequacy concerns beyond the element list

These concerns apply regardless of how elements are arranged:

• Construct validity. Elements describe what to measure, not whether the tests measure it.
For each element, sponsors should show that the test items probe the claimed construct and
that scores relate to later clinical performance (Question 10).
• Rubric and adjudicator reliability. Open-ended outputs depend on scoring rubrics and
adjudicators. Inter-rater reliability should be reported. The paper notes LLM adjudicators
must meet independence criteria, and their validity against clinician judgment should be
demonstrated, not assumed.
• Coverage and sample size. No guidance exists on how many cases per element make a
result credible, particularly for rare, high-consequence behaviors, so the evidence may look
systematic without being suf ciently powered (Question 12).
• Aggregation. If element scores are combined, safety-critical elements should be treated as
gating thresholds, not averaged (Question 7).
• Static versus dynamic testing. Benchmarks are a snapshot. Devices with retrieval or model
updates require re-benchmarking, and benchmark sets need refreshing to avoid saturation.
• Evaluating the deployed system. Consistent with the paper, the full con guration is tested,
but the interaction of the device with the particular user population and work ow is outside
what benchmarking captures.
7. Externally developed standards and frameworks that could be leveraged

Date 18/10/2026 30 of 131 FDA-2026-N-7874

fl
fi
fi
fi
fi
fi
fi fi
 I list these by name as candidates. I have not veri ed their current editions or scope, so please
con rm before citing.

Area Candidate Possible use
Medical device
Hazard analysis underpinning
risk ISO 14971
the risk tier and modi er logic
management

Medical device
Lifecycle and change-control
software IEC 62304
processes
lifecycle

Usability and Evaluating user reliance,
IEC 62366-1, FDA human factors guidance
human factors comprehension, and use errors
Quality Process controls, including for
ISO 13485
management third-party components
AI
Organizational AI governance
management ISO/IEC 42001 and ISO/IEC 23894
and AI risk practices
and risk
AI risk NIST AI Risk Management Framework and its Vocabulary and risk categories
framework generative AI pro le for generative systems
FDA premarket cybersecurity guidance, and Security elements, including
Cybersecurity
related device security standards SBOM and threat modeling
Reporting guidelines for AI in clinical studies Structuring con rmation
Reporting of
(e.g., TRIPOD-type, CONSORT-AI, DECIDE-AI studies and transparent
AI studies
families) reporting
Model Foundation Model MAFs
Model cards and system cards
documentation (Question 25)
Qualifying benchmark assets
MDDT, ASCA, and FDA’s computational
FDA tools and building credibility
modeling credibility guidance
frameworks
Safety Organizing the argument that
Assurance-case approaches
assurance evidence supports safety

Two comments on leveraging these:

• Most are process or framework standards, not performance benchmarks. They can
structure and document an evaluation but do not supply clinical test content. There is likely
a gap in consensus clinical-task benchmarks speci c to GenAI, which could motivate a
standards effort or the third-party roles in Question 16.
• Credibility frameworks may be the closest analogue. The structure of the computationalmodelling credibility guidance (context of use, risk-informed credibility goals, evidence by
factor) maps well onto the two-axis tiering and could organise benchmarking evidence
without creating a new scheme.
8. Illustrative gaps in a concrete case

For a patient-facing chest-pain triage device, the current elements cover escalation, scope,
calibration, communication, robustness and subgroup performance. They do not clearly require:
testing whether patients act on a recommendation as intended, evaluating privacy of the symptom
data, testing behaviour during a retrieval outage, or evidence that cited guidelines are accurate and
Date 18/10/2026 31 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
 current. A reviewer applying only the listed elements could judge benchmarking complete while
these gaps remain.

9. Limitations and open questions

• We have no empirical evidence on whether this element set predicts real-world safety, and
we do not claim it. Pilot application to real or retrospective submissions would show which
elements discriminate between safe and unsafe devices.
• The completeness of any element list is hard to establish. A structured hazard analysis for
each device type (ISO 14971 style) could generate a device-speci c list and show where the
generic list falls short.
• Adding elements raises sponsor burden. We would favour additions tied to speci c hazards
and tiers over a larger universal checklist, consistent with least burdensome principles.
• Some proposed additions (reliance, privacy, security) overlap with requirements outside this
discussion paper, and CDRH should clarify how they interact.
• The standards table is a starting point, and I have not assessed how well each ts GenAIspeci c risks.
10. Recommendations

1. Treat benchmarking as necessary but not suf cient, and require evidence linking it to
clinical con rmation.
2. Add elements or requirements for user reliance and automation bias, traceability and
faithfulness, and privacy and data handling.
3. Cross-reference security, system reliability and knowledge currency to existing device
requirements, adding GenAI-speci c detail where needed.
4. Reduce overlap: assign uncertainty behaviour to S.3, treat R.1 and R.2 as test conditions
applied across elements, and limit A.1 to agent-speci c competencies.
5. Reconsider labels and placement: rename Generalisability or add a deployment-transport
element, and split safety-relevant communication from comprehension testing.
6. Require construct-validity evidence, rubric reliability, and justi cation of sample sizes for
each element.
7. Treat safety-critical elements as gating thresholds, not averaged.
8. Provide a default mapping of elements to device type and tier.
9. Leverage existing risk, human-factors, quality, cybersecurity and credibility frameworks,
and consider developing consensus benchmark content through standards bodies or quali ed
third parties.

Question 10 - CDRH recognises that publicly available benchmarking assets may be subject to
data contamination, saturation, and limited real-world representativeness. How should a
sponsor establish that performance on a given benchmark predicts safe and effective realworld behaviour for the device’s intended use? What evidence should support the construct
validity of a benchmark used to gate device evaluation, and what role should sponsordeveloped benchmarks play given potential concerns around independence and optimisation
to the test?

1. Summary position

Benchmark performance should not be presumed to predict real-world behaviour. The sponsor
should demonstrate it, for the speci c device and intended use, with a pre-speci ed validation

Date 18/10/2026 32 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
 argument that has three parts: (a) evidence the benchmark measures the intended construct, (b)
evidence that scores relate to performance in real or clinically representative use, and (c) evidence
the benchmark is resistant to contamination and optimisation. Sponsor-developed benchmarks
should be permitted and often necessary, but should be subordinate to independently held
material at higher tiers, with disclosure of development history and independent review. A
benchmark that gates evaluation should be treated as a measurement instrument that needs its own
validation, in the way an in vitro diagnostic or a patient-reported outcome measure does.

2. Reframing: a benchmark is a measurement instrument

The paper asks about prediction and construct validity, which are measurement concepts. A useful
structure separates:

Question Validity What it asks
concept
Do the items cover the relevant clinical content Is the benchmark
Content validity
and situations? representative of the intended
Does it measure the capability it claims (not Construct use?scores re ect the target
Do
recall, test-taking, pattern-matching)? validity competence?
Criterion / Does a higher score mean safer
Do scores track performance in real use?
predictive real-world behavior?
Is it stable and reproducible? validity
Reliability Do repeat runs, raters and
versions agree? leaked or
Has it saturated,
Does it keep working over time? Durability
been optimized against?

Established validation practice in measurement science and in quali cation programs (such as
FDA’s MDDT, which the paper cites) already offers this vocabulary, and I suggest CDRH adopt it
rather than invent new terms. I have not veri ed the speci c requirements of those programs.

3. Establishing that benchmark performance predicts real-world behaviour

3.1 Concordance on a shared case set (primary evidence). The most direct approach is to
evaluate the device on a set of real or clinically representative cases through both routes, benchmark
scoring and clinical con rmation (Section V.C), and show that they agree. Examples:

• Compare benchmark scores against outcomes from retrospective evaluation on real patient
inputs.
• Check that cases that fail in con rmation would have been agged by the benchmark
(benchmark sensitivity for real failure modes).
• Report agreement statistics with con dence intervals, not only a correlation.
3.2 Known-groups and contrast testing. Show the benchmark can separate devices or
con gurations of known different quality, for example a deliberately degraded con guration, an
earlier version with documented failures, or a weaker baseline. A benchmark that cannot
discriminate between a good and a known-poor system cannot gate anything.

3.3 Failure-mode coverage from real use. Construct a catalog of failure modes seen in real or
shadow-deployment data and show the benchmark contains items that would have caught them.
This turns real-world failures into benchmark content over time.

Date 18/10/2026 33 of 131 FDA-2026-N-7874

fi
fi
fl
fi
fi
fi
fi
fi
fl
fi
 3.4 Item-level and slice-level validity. Aggregate scores can hide the cases that matter. For safetycritical elements, validity should be shown at the level of the relevant slice (for example timecritical escalation cases), not only overall.

3.5 Explicit statement of what the benchmark does not predict. Where predictive validity is
weak or untested for an element, the sponsor should say so, and clinical con rmation should carry
the load for that element, consistent with our Question 7 comment.

3.6 Prospective anchoring at high tiers. For the highest tiers (Question 8), predictive validity
should ideally be checked against real-use behaviour including user actions, since benchmark scores
on outputs cannot show whether users act appropriately.

4. Evidence supporting construct validity

Evidence type What it shows Example
Coverage of the intended A matrix of benchmark items against
Content mapping
use, population, setting and conditions, user types, and the hazard analysis
Expert review of failureare
Items modes
clinically correct, Independent clinician review with documented
items unambiguous and in scope disagreement handling
Rubric grounding Scoring re ects clinical Rubrics tied to guidelines; inter-rater reliability
and reliability standards and is reproducible reported
Adjudicator Automated scoring agrees Agreement of an LLM judge with independent
validity (including with quali ed clinicians clinicians on a held-out sample, with error
LLM judges)
Discriminant The benchmark does not just patterns
Showingreported
scores are not explained by prompt
evidence measure something else length, formatting or surface cues
Robustness of Scores stable to paraphrase, Results under perturbed item wording and
scores ordering and rerun variance repeated runs (links to R.1)
Correlation with Predictive validity (Section
Concordance on shared cases
real-world criteria 3)
Dif culty and The benchmark can still Score distribution across systems; ceiling
headroom distinguish strong systems effects agged

A recurring risk is that a benchmark measures knowledge recall when the claim is safe interaction.
Items drawn from licensing-style questions may be informative about E.1, but are weak evidence
for S.1, S.2 or E.2, which need interactive and multi-turn designs (Question 5). Construct validity
should therefore be shown per element, not for the benchmark as a whole.

5. Contamination, saturation and representativeness

Contamination (test items seen in training). Sponsors should document what is known about the
training exposure of the underlying model (limited for third-party models, linking to the Foundation
Model MAF in Question 25) and use mitigations such as:

• Held-out or sequestered items never published.
• Newly authored or regularly refreshed items.
• Perturbed variants of public items, with analysis of the gap between original and perturbed
performance as a contamination signal.
• Reporting performance on items released after the model’s training cutoff, where that cutoff
is known.

Date 18/10/2026 34 of 131 FDA-2026-N-7874

fi fl
fl
fi fi
 None of these is conclusive. Contamination assessment should be reported as an estimate with
stated limits, not a clean bill.

Saturation. Where leading systems score near ceiling, a benchmark no longer discriminates.
Sponsors should report headroom and, where saturated, add harder or more adversarial items.
Sponsors should not treat a near-perfect score on a saturated public benchmark as strong evidence.

Representativeness. Public benchmarks often re ect curated, clean cases, not noisy real inputs
(colloquial language, missing units, incomplete histories, distress). Sponsors should show how
benchmark inputs compare with real inputs from the deployment context, for example by
comparing distributions of input features or by including a sample of real, de-identi ed inputs.
Where synthetic inputs are used, the circularity concerns of Question 13 apply.

6. The role of sponsor-developed benchmarks

Sponsor-developed benchmarks are often the only way to test device-speci c functions, and
prohibiting them would be impractical and contrary to least burdensome principles. The concerns
are independence and optimisation to the test. We suggest a graded approach:

Tier / Role of sponsor-developed
Safeguards
use assets
Lower Prespeci cation, documented development,
Acceptable as primary evidence
tiers independent clinician review of items
Acceptable for device-speci c
Middle Independent adjudication; part of the set sequestered
content, alongside independently
tiers from development; disclosure of tuning history
maintained material
Gating performed on independently held or
High Supplementary and devicesequestered sets; independent adjudication;
tiers speci c only
contamination and tuning disclosures

Key safeguards:

1. Separation of development and evaluation data. Items used to tune prompts, guardrails or
models must be separate from items used to evaluate. Sponsors should document the
rewall and the number of evaluation runs (“how many looks”).
2. Pre-speci cation before testing, including items, rubrics, thresholds and analysis plan,
consistent with the paper’s principles.
3. Disclosure of iteration history. If the device was iteratively improved against the
benchmark, say so. Performance on a benchmark used for tuning is optimistic by
construction.
4. Independent authoring or review of at least part of the set, with the independent portion
not visible to developers.
5. Third-party sequestered sets where feasible (Question 16), refreshed on a schedule, with a
policy on how often one can be used before it is treated as exposed.
6. Transparency of results, including failed runs and con gurations tried, to limit selective
reporting.
7. Pre-speci ed handling of failures. If a benchmark exposes a failure, the sponsor should not
simply re-tune and re-test on the same items without declaring it.
7. Using the benchmark as a gate

Date 18/10/2026 35 of 131 FDA-2026-N-7874

fi
fi
fi
fl
fi
fi
fi
fi
fi
fi
 The paper’s wording, a benchmark “used to gate device evaluation,” raises a speci c issue: a gate
that is too easy gives false assurance and one that is too hard blocks bene cial devices, and sponsors
have a strong incentive to optimise toward it. We suggest:

• Gate on safety-critical elements with pre-speci ed thresholds, and treat other elements as
informing, not gating (Question 7).
• Set thresholds from clinical consequences and comparator performance, not from what
current systems can achieve (Questions 14 and 15).
• Report con dence bounds, and base the gate on the bound that matters (for example the
upper bound on miss rate for time-critical conditions), not the point estimate.
• Re-validate the gate when it changes, since a refreshed or modi ed benchmark may shift
what a given score means.
• Do not allow a benchmark pass to substitute for con rmation where predictive validity
has not been shown.
8. Postmarket continuation

Predictive validity should be treated as a hypothesis that continues to be tested:

• Track whether premarket benchmark scores and real-world performance measures keep
agreeing, and treat divergence as a trigger for investigation (Section VI).
• Feed real-world failures back into the benchmark as new items.
• Re-benchmark after model or con guration changes using the same validated instrument,
with a record of the benchmark version.
9. Illustrative cases

Device Benchmark issue Suggested evidence
Patient-facing A public medical-exam Interactive, multi-turn escalation benchmark;
chest-pain triage benchmark is weak concordance with real or shadow-deployment
HCP-facing evidence for
Public triage
question sets may dispositions;
Perturbed andpaired escalation
post-cutoff reporting
items; sponsorguideline overlap with training data developed device-speci c items reviewed by
summarizer
Lab-result Clean synthetic inputs independent clinicians ed inputs; test implausible
Include real de-identi
interpretation for differ from real lab text values and unit confusion (E.3); comprehension
patientswhose
Device with missing units and testing
Evaluate on a sequestered set with a documented
Scores are optimistic
sponsor tuned rewall; report iteration history
prompts on the
These are illustrative only and not a proposed classi cation.

10. Cautions

• Do not require predictive validity that cannot be obtained premarket. For rare, highconsequence events, real-world criteria may be unavailable. In that case state the limitation
and rely on con rmation and post market evidence instead.
• Do not treat third-party benchmarks as automatically valid. Independence does not
establish construct validity, and a widely used public benchmark can be both independent
and a poor measure of the claim.
• Do not over-restrict sponsor assets. Excluding them would reduce relevance to the device
and could favour sponsors who can pay for third-party sets.
• Beware of concentration. If a few third parties control gating benchmarks, they gain
in uence over what devices are optimised for (Question 16), so refresh policies, access
terms and governance matter.
Date 18/10/2026 36 of 131 FDA-2026-N-7874

fi
fi fi
fi fi
fi fi
fi fi
fl
fi fi fi
 • LLM judges are not neutral. Scoring by a model from the same family as the device, or by
one sharing training data, can in ate scores, so adjudicator independence applies to them as
well, as the paper notes.
11. Limitations and open questions

• Evidence on how well current GenAI benchmarks predict real-world clinical behaviour is
limited, and I do not claim to summarise it here. Pilot studies pairing benchmark results with
real-use outcomes would address this directly.
• There is no agreed standard for how much concordance is enough, or what agreement
statistic should apply, and this probably varies by tier.
• Contamination is hard to detect, especially for third-party models whose training data are
undisclosed, so assessments rest partly on proxies.
• A refresh policy for sequestered sets needs a balance between independence, cost, and
comparability across time. How this should work in practice is unresolved.
• Whether CDRH, standards bodies or consortia should maintain reference benchmarks is a
governance question I ag but do not resolve.
12. Recommendations

1. Require a pre-speci ed validation argument for any gating benchmark, covering content,
construct, predictive validity, reliability and durability.
2. Establish predictive validity primarily through concordance with clinical con rmation on
a shared case set, supported by known-groups testing and real-failure-mode coverage.
3. Show construct validity per element and per slice, with rubric reliability and adjudicator
validation (including LLM judges).
4. Report contamination, saturation and representativeness assessments with stated limits, and
use sequestered, refreshed or perturbed items.
5. Permit sponsor-developed benchmarks, graded by tier: primary at lower tiers, supplementary
and subject to independent review and sequestered gating sets at higher tiers.
6. Require a development/evaluation rewall, pre-speci cation, disclosure of iteration history
and transparent reporting of all runs.
7. Base gates on safety-critical elements, clinically derived thresholds and con dence bounds,
and do not allow a benchmark pass to replace con rmation where predictive validity is
unproven.
8. Continue to test predictive validity post-market and feed real-world failures back into
benchmark content.
9. Pilot these requirements before formalising them.

Question 11 - CDRH is considering that clinical confirmation for a GenAI-enabled device
might not require a prospective clinical study in every case, and has described above a range
of approaches of increasing rigor and patient exposure. How might a sponsor select and
justify a confirmation approach tailored to a device’s intended use and proportionate to the
device’s risk profile? Are there device types or risk profiles for which one or more of these
approaches would be insufficient or inappropriate? How might the anticipated distribution of
real-world inputs be taken into consideration? Are there other methods of clinical
confirmation that might help inform the evaluation of GenAI-enabled devices?

1. Summary position

Date 18/10/2026 37 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fl
fl
fi
The choice of con rmation approach should follow from what question the evidence must
answer, not from a xed ladder of rigor. We recommend that sponsors select and justify an
approach through a short, pre-speci ed con rmation rationale that links (a) the device’s tier and
reachable maximum (Questions 5 and 8), (b) the speci c uncertainties that benchmarking cannot
resolve, and (c) what each candidate method can and cannot show. The paper’s list is ordered by
rigor and patient exposure, but the methods also differ in what they measure: most test output
quality, few test user behaviour or outcomes. For action-directing or action-taking functions at
higher tiers, methods that observe real user behaviour are needed, and several of the listed
approaches are insuf cient on their own. We suggest adding methods (listed in Section 7) and
requiring that con rmation sample the realistic input distribution, including its dif cult tail.

2. What each listed approach can and cannot show

The listed methods answer different questions. Ordering them only by rigor hides this.

Approach Can show Cannot show
Retrospective Output quality on realistic User behavior, effect of the output on decisions,
evaluation on inputs against a reference interaction effects; reference standard may re ect
real inputs standard care that was itself in uenced by clinicians
Shadow Performance in the live input Whether users would act on or be misled by
deployment stream and work ow, with no outputs; effect on outcomes
Standardized patient exposurebehavior under Real patient behavior, rare presentations, true
Conversational
patient controlled, repeatable variation in language and distress; actors may not
interactions
Clinician scenarios, including pressure behave like real patients
Appropriateness of outputs as Actual outcomes; adjudicator agreement is itself
adjudication
judged by experts variable
of real cases
Prospective Effect of the device in use, Generalization beyond the study setting; may be
study including user behavior and underpowered for rare events
(including outcomes
The practical point is that three of the ve (retrospective, shadow, clinician adjudication) are
variants of output assessment. They do not tell us what happens when a person reads and acts on
the output, which is where several of the paper’s concerns sit (automation bias, patient reliance,
delayed care).

3. How a sponsor could select and justify an approach

We suggest a con rmation rationale with four steps, submitted before the study and reviewable in
pre-submission discussions.

Step 1: State the residual uncertainties. After benchmarking, what remains unknown? Examples:
performance on real input noise, behaviour under real conversational pressure, whether users act
appropriately, rare high-consequence failures, subgroup performance in real populations.

Step 2: Map uncertainties to methods. Choose the method that can actually resolve each
uncertainty, using the table above. Several methods may be needed, in sequence or combination, as
the paper allows.

Step 3: Scale to tier and modi ers. Use the evidence emphasis from our Question 8 comment:

Factor Implication for con rmation

Date 18/10/2026 38 of 131 FDA-2026-N-7874

fi
fi
fl
fi
fi
fi
fi
fi
fl fi
fi
fi
fi
fi
fl
 Needs methods that include real users, since benchmarks cannot
Low detectability
show whether errors are caught
Action-directing or action- Needs evidence on user action, not only output quality
taking
Low reversibility or severe
Higher rigor and tighter bounds on rare failures
consequence
Time pressure Human-factors evidence under realistic time constraints
Credited safeguards Evidence that the safeguard functions in practice
Autonomous operation, no
Highest rigor; prospective or equivalent evidence
human check

Step 4: Justify proportionality and stopping. State why a less burdensome method suf ces, and
what ndings would trigger escalation to a more rigorous method (for example, shadow deployment
revealing a high rate of unsafe outputs on a subgroup).

This keeps the least burdensome principle intact: sponsors choose the lightest method that resolves
the identi ed uncertainty, with the reasoning visible.

4. Staged con rmation as a default pattern

A sequence from lower to higher exposure is natural and, we think, desirable for higher tiers:

1. Retrospective evaluation on real inputs (no exposure).
2. Shadow deployment (no in uence on care).
3. Standardised patient or simulated-user testing for conversational and pressure behaviour.
4. Limited deployment with enhanced oversight, such as clinician review of all outputs or a
restricted population, with pre-speci ed stopping rules.
5. Broader deployment with monitoring, linked to post-market requirements (Section VI).
Each stage should have pre-speci ed criteria for progressing, pausing or stopping. This resembles
the graded independence that the paper’s clinician analogy invokes, and our Question 7 comment’s
point that sequencing should be iterative.

5. Device types and risk pro les for which approaches are insuf cient or
inappropriate

Approaches
Device type or
likely Why What would help
pro le
insuf cient
Patient-facing Retrospective, Do not show whether Real-use evidence on behavior
action-directing shadow, clinician patients act appropriately and outcomes; prospective or
functions (triage, adjudication or whether care-seeking equivalent study, possibly a
self-treatment) alone improves pragmatic design
All non- No human check, so
Autonomous
prospective errors reach patients Prospective evidence, staged
action-taking
methods used directly; rare severe autonomy, strong stopping rules
functions
alone failures matter

Date 18/10/2026 39 of 131 FDA-2026-N-7874

fi fi fi
fi fi
fi fi fi fi
fl fi
 Single-turn
Full-conversation review,
Conversational adjudication;
Miss trajectory-level standardized patients with
devices with drift retrospective on
behavior (Question 5) pressure scripts, real-use
risk logged nal
trajectory sampling
outputs
Enriched or simulated cases
Rare, time-critical Any method with Cannot bound miss rates anchored on real ones, with
conditions small samples for rare events upper con dence bounds, plus
postmarket surveillance
Devices whose
Prospective or longitudinal
bene t depends on Output-quality Effect depends on use
studies measuring engagement
behavior change methods over time
and outcomes
or engagement
Users cannot assess
Measurement and Clinician Comparison against reference
outputs, and neither can
signal-processing adjudication of measurement or outcome-based
reviewers without a
functions outputs truth
reference measurement
Evaluation of action sequences
Errors can arise in
Agentic functions Output review in realistic environments, with
actions and tool
with tool use alone controlled oversight checkpoints
interactions, not only text
(Question 26)

Approaches that are inappropriate in speci c cases deserve a separate note. Standardised patient
interactions can be unsuitable, or require ethical safeguards, for scenarios involving distress or
sensitive conditions. Shadow deployment raises privacy and consent considerations because real
patient data ow to a system whose output is hidden. We note that the paper places the applicability
of human-subjects and investigational device requirements outside its scope, and we do not address
them here.

6. Taking the distribution of real-world inputs into account

The distribution of real inputs matters because GenAI devices can fail on the unusual and the
messy, which averages can hide.

1. Characterise the intended input distribution rst. Describe the expected population,
presenting complaints, language and dialect, literacy, input modality, data quality (missing
units, typos, contradictory history), and conversation length, drawing on data from the
intended deployment setting.
2. Compare the con rmation sample to that distribution. Show how the sample matches or
differs, using descriptive comparisons on the features that matter. If the sample is a
convenience sample from a single site, state what is missing.
3. Sample the tail deliberately. Random sampling will rarely capture rare, high-consequence
presentations. Use strati ed or enriched sampling for critical conditions, and report results
by stratum with con dence bounds.
4. Separate prevalence-dependent from prevalence-independent measures. Overescalation burden and predictive values depend on how common true cases are (Question 6),
so report assumed prevalence and re-examine it if deployment differs.
5. Include the full interaction record, not only the nal query. Real users supply incomplete,
emotional and repetitive input, and the distribution of conversational paths is part of the
input distribution.

Date 18/10/2026 40 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fl
fi
fi
fi
 6. Plan for distribution shift. Specify how the sponsor will detect when deployed inputs
differ from con rmation inputs, and what that triggers (re-benchmarking, additional
con rmation), linking to Section VI monitoring.
7. Use real-world data and OUS data with explicit justi cation. The paper asks about these.
Their value is realism and scale. The concerns are differences in care patterns, language,
population and reference standards, which affect transport to the intended U.S. setting.
Sponsors should show why the data are relevant and analyze subgroups where differences
are likely.
8. Be cautious with synthetic inputs. They can supplement scarce subgroups, but circularity
applies when the generator resembles the device’s model class (Question 13), so critical
estimates should rest on real or clinically representative cases.
7. Additional methods of clinical con rmation to consider

These are suggestions, not validated recommendations.

• Simulation-based and “clinical-in-the-loop” testing with real clinicians as users.
Clinicians use the device on realistic cases (in a lab or work ow setting) so that human-AI
team performance and reliance are measured. This addresses automation bias without
exposing patients.
• Randomised or counterbalanced reader studies. Used in other device areas, where users
handle cases with and without the device. These can estimate the effect of the device on
decisions and are well suited to HCP-facing functions.
• Pragmatic and stepped-wedge or cluster designs. For deployed work ows, staggered
rollout with comparison between units can provide effectiveness evidence at lower perpatient exposure than a conventional individually randomised trial.
• Comparison to the realistic counterfactual. For example, comparison against nurse triage
lines, usual self-directed search, or unaided clinician judgment (Question 15).
• Prospective observational studies with outcome follow-up. Useful when randomisation is
impractical, to track what users did and what happened, accepting confounding.
• Limited-release or staged-autonomy deployment with enhanced monitoring. Controlled
exposure with pre-speci ed stopping rules (Section 4).
• Red-team and adversarial exercises with clinicians and lay users, run on the deployed
system, to nd failure modes that scripted tests miss. These generate hypotheses and feed
benchmarks, rather than serving as formal con rmation.
• Usability and human-factors validation in simulated use environments, covering
comprehension, use errors and reliance. This aligns with existing human-factors practice,
whose current requirements I have not veri ed.
• Audit-style review of operational data from pilot sites, including escalation rates, user
override rates and downstream utilisation.
• Natural-experiment or registry-linked analyses where data allow outcomes to be linked
to device use.
8. Statistical considerations

The paper acknowledges that these methods may not be powered around traditional effectiveness
endpoints. We suggest:

• Pre-specify what the study is estimating, such as a miss rate for time-critical conditions,
agreement with an adjudicated reference, or change in user decisions. Precision targets can
then be set from the clinical consequences of an error, not from conventional power
conventions.

Date 18/10/2026 41 of 131 FDA-2026-N-7874

fl
fi
fi
fi
fi
fi
fi
fi
fi fl
 • Report con dence bounds, and base conclusions on the bound that matters (for example,
the upper bound on under-escalation).
• Handle repeated measures and clustering, since multiple conversations per user, clinician
or site are correlated.
• Account for non-determinism. Repeat runs on the same input can differ, so con rmation
should address within-case variability, not only between-case variability.
• Avoid combining benchmark and con rmation evidence into a single estimate unless
the sponsor has shown the sources are exchangeable (Question 12).
9. Illustrative cases

Device Suggested con rmation approach Rationale
Plain-language Retrospective evaluation on real user questions; Non-directive, limited
condition clinician adjudication of a sample consequence; output quality
education
HCP-facing tool Reader study with clinicians using real cases, with is the main
Question is uncertainty
effect on
guideline and without the device clinician decisions and
summarizer Retrospective on real symptom narratives, shadow reliance, not only severe,
Action-directing, accuracy
Patient-facing
deployment, standardized patients with pressure time-pressured, low
chest-pain triage
scripts, then staged limited deployment with detectability; behavior and
Lab-result outcome follow-up
Retrospective with real lab text including errors and outcomes matter
Detectability is low;
interpretation missing units; comprehension and behavior testing comprehension and actions
for patients
Autonomous with representative patients are central
Shadow deployment, then prospective evaluation Autonomous, severe, rare
order-set
with staged autonomy and stopping rules critical events
initiation in a
stroke work ow
These are illustrative only and not a proposed classi cation.

10. Cautions

• Do not treat the ladder as a quality ranking in every dimension. A well-designed
retrospective study may be more informative about output quality than a small,
underpowered prospective study. The question is what the method can show.
• Do not require a prospective study by default, since this would con ict with least
burdensome principles and delay bene cial devices. Equally, do not let lower-exposure
methods stand in for evidence they cannot produce.
• Beware of the reference standard. In retrospective work, the “truth” may itself have been
shaped by clinicians, and outcome-based truth is often confounded by treatment.
• Avoid unrepresentative convenience samples, such as a single academic centre, presented
as general evidence.
• Standardised patients are scripted. They are good for repeatability and pressure testing,
but their conversational behaviour may be more cooperative or more extreme than real
users.
• Do not assume stability. Con rmation re ects a version of the device. A model or
con guration change may require re-con rmation, linked to change control (Questions 22 to
24).
11. Limitations and open questions

•
There is no established way to decide when non-prospective evidence is enough for a given
tier. Our mapping is a proposal that would need testing against real submissions.
• We have no data on how well output-based methods predict effects on user behaviour and
outcomes for GenAI devices, which is an empirical question.
Date 18/10/2026 42 of 131 FDA-2026-N-7874

fi
fl
fi
fl
fi
fi
fi
fi
fi
fl fi
fi
 • Methods such as stepped-wedge designs and clinician-in-the-loop simulation are less
established for GenAI devices, and their ability to detect rare harms is limited.
• It is unclear how to set stopping rules and progression criteria in staged deployments, and
who reviews them.
• Ethical and privacy aspects of shadow deployment and use of real patient conversations
need separate consideration beyond this paper’s scope.
• Which approaches regulators would accept as suf cient at each tier is a governance decision
that I ag but do not resolve.
12. Recommendations

1. Require a pre-speci ed con rmation rationale linking tier, residual uncertainties and
method, with triggers for escalating to more rigorous evidence.
2. Describe methods by what they can show (output quality, user behaviour, outcomes) and
not only by rigor and exposure.
3. Treat output-assessment methods (retrospective, shadow, clinician adjudication) as
insuf cient alone for patient-facing action-directing functions, autonomous action-taking
functions, and devices with low detectability.
4. Use staged con rmation with pre-speci ed progression and stopping criteria at higher tiers.
5. Characterise the intended input distribution, compare it to the con rmation sample, sample
the tail deliberately, and include full conversation records.
6. Justify use of real-world, OUS and synthetic data explicitly, and anchor critical estimates on
real or clinically representative cases.
7. Consider adding reader studies, clinician-in-the-loop simulation, pragmatic and steppedwedge designs, counterfactual comparisons and human-factors validation to the list of
methods.
8. Set precision targets from clinical consequences, report con dence bounds, and handle
clustering and non-determinism.
9. Pilot the selection approach with sponsors and reviewers before formalising it.

Question 12 -How should sponsors achieve statistically meaningful performance measurement
for GenAI-enabled devices? Where synthetically generated inputs supplement real patient
data, how should sponsors account for differences between the synthetic and real-world
distributions when estimating performance, and under what conditions, if any, is it
appropriate to combine benchmarking evidence and clinical confirmation evidence to support
a single performance estimate?

1. Summary position

Statistical meaningfulness for GenAI devices should be built around pre-speci ed estaminets:
what quantity is being estimated, in which population of inputs, with what precision, and under
which sources of variability. We recommend that sponsors (a) de ne the estaminet for each element
in terms of its clinical consequence, (b) model the several layers of variability that GenAI devices
add (case, user, conversation, run-to-run, adjudicator), (c) anchor critical estimates on real or
clinically representative data and treat synthetic data as supplementary, with explicit bridging to the
real distribution, and (d) not pool benchmark and con rmation evidence into a single estimate
by default. Pooling should be permitted only where the sponsor has shown, with pre-speci ed
checks, that the sources measure the same quantity in the same population. Otherwise the two
should be reported side by side, each answering its own question.

2. Achieving statistically meaningful measurement
Date 18/10/2026 43 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi fl
 2.1 Start from the estaminet. Before choosing a sample size, specify:

Component Example
Miss rate for time-critical escalation; agreement with adjudicated
Quantity
reference; rate of out-of-scope outputs
Intended users, presentations, language, conversation paths (Question 11,
Population of inputs
Section 6)
Unit of analysis Case, conversation, user, or site

Handling of run-toSingle run, majority of runs, or distribution across runs
run variation

Summary and bound Point estimate plus the con dence bound that carries the clinical decision

Without this, large numbers of test items can look rigorous while estimating something no one
needs.

2.2 Account for the layers of variability. Conventional device testing treats the case as the main
random effect. GenAI devices add several:

• Case-to-case variation (the usual source).
• Run-to-run variation for the same input, since outputs are non-deterministic.
• Prompt and paraphrase sensitivity, where semantically equivalent inputs yield different
outputs (R.1).
• Conversation-level dependence, with turns correlated within a conversation.
• User, clinician and site clustering in con rmation studies.
• Adjudicator variability, including disagreement among experts and between LLM judges
and clinicians.
• Version variability, if the model or con guration changes.
Sponsors should use methods that respect this structure, such as mixed-effects or cluster-robust
approaches, and report variance components. Ignoring clustering and repeated measures makes
con dence intervals too narrow. Repeating runs on the same case improves precision about run-torun noise but does not substitute for more independent cases.

2.3 Set precision from clinical consequences, not convention. Consistent with Question 11,
precision targets should re ect what an error costs. For rare, severe failures, the relevant quantity is
the upper con dence bound on the failure rate. A useful reference point is that with zero observed
failures in n independent cases, the one-sided 95% upper bound on the rate is approximately 3/n
(the “rule of three”). Demonstrating a rate below 1 in 1,000, for example, requires on the order of
3,000 independent cases with no failures. This shows why rare high-consequence behaviours are
hard to bound premarket and why enrichment, simulation anchored on real cases, and post-market
surveillance are needed.

2.4 Pre-specify the analysis. Fix the hypotheses, thresholds, handling of missing or unscorable
outputs, number of runs, and multiplicity control before testing. Reporting many element-level and
subgroup metrics without pre-speci cation invites selective presentation. Distinguish gating
endpoints (safety-critical elements) from descriptive ones, and control error rates only where
decisions depend on them.

2.5 Evaluate subgroups with honest precision. Subgroup estimates (R.2) are often imprecise.
Sponsors should report subgroup results with intervals, state which subgroups are adequately
Date 18/10/2026 44 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fl
fi
fi
 powered and which are only exploratory, and avoid declaring equivalence from wide intervals that
merely include no difference.

2.6 Choose metrics suited to the task. Open-ended outputs often need rubric-based or ordinal
scoring. Sponsors should report rubric reliability (inter-rater agreement), avoid collapsing ordinal
safety grades into a single mean, and consider whether the metric supports the comparator logic in
Questions 14 and 15 (for example, non-inferiority to a clinician panel with a justi ed margin).

2.7 Address non-determinism explicitly. Report performance both per run and across repeated
runs, and, for safety-critical behaviours, the worst-case or “any-run” failure rate as well as the
average. A device that gives the right escalation 95% of the time on the same input has a different
safety pro le from one that does so 100% of the time, even if average accuracy looks similar.

2.8 De ne the sampling frame. Report how cases were chosen (random, strati ed, enriched,
convenience), and provide design weights or post-strati cation so estimates can be mapped to the
intended population. Enrichment for rare conditions improves precision on those strata but distorts
prevalence-dependent measures unless reweighted (Question 6).

3. Accounting for synthetic versus real distributions

Synthetic inputs can help with scarce subgroups, rare presentations, adversarial coverage and scale.
The statistical problem is that performance on synthetic inputs estimates performance on the
synthetic distribution, which may differ from the real one in ways that matter. We suggest the
following.

3.1 Treat the real distribution as the target and synthetic data as a means. Primary and gating
estimates for the intended use should rest on real or clinically representative inputs. Synthetic data
can supplement them where real data are limited, with the limits stated.

3.2 Document the generation process. Record the generator (model, version, prompts), the source
data it was modelled on, any ltering, and the review applied. Provenance matters because synthetic
data inherit the generator’s blind spots.

3.3 Assess delity and relevance before use. Compare synthetic and real inputs on the features that
drive device behaviour, not only surface similarity:

• Distributional comparison on clinical features (age, comorbidity, severity, presenting
complaint).
• Linguistic features (register, dialect, typos, missing units, length, emotional tone).
• Conversational structure (turn counts, pushback patterns).
• Task-relevant behaviour: whether the device’s error patterns on synthetic data resemble
those on a real sample. This is more informative than feature similarity alone.
3.4 Validate against a real calibration sample. Run the device on a modest real sample and on
synthetic data, then examine whether synthetic performance tracks real performance across strata.
Divergence indicates that synthetic results should not be extrapolated for those strata.

3.5 Use estimation approaches that acknowledge the gap. Options include:

• Report real and synthetic results separately and do not blend them in the headline
estimate.
• Reweighting or post-strati cation of synthetic cases to match real feature distributions,
with the caveat that this corrects only for measured features.

Date 18/10/2026 45 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi fi
fi
 • Calibration or bridging models that relate synthetic to real performance using the real
calibration sample, with uncertainty propagated into the nal interval. Methods that combine
a small labeled real sample with a larger proxy sample exist in the statistical literature (often
described as prediction-powered or doubly robust approaches), but I have not veri ed their
suitability for this setting and ag them only as candidates.
• Sensitivity analysis over plausible degrees of distributional mismatch, showing how
conclusions change. If the conclusion holds across the range, it is more persuasive.
• Bounds-based reporting, treating synthetic data as informative for coverage (“have we
probed this behaviour at all?”) and real data for rates.
3.6 Guard against circularity. As Question 13 raises, synthetic data generated by a model of the
same class as the device may reproduce the same gaps the evaluation should detect, and an LLM
that generated a case may also nd it easy to answer. Safeguards include using a generator
independent of the device’s model family, adversarial or clinician-authored generation for hard
cases, and independent clinician review of a sample of synthetic cases for realism and correct
labels.

3.7 Check label quality. Synthetic cases need reference labels. If an LLM supplies the label, errors
in the label look like device errors or hide them. Labels should come from guideline-grounded rules
or independent clinician adjudication, with reliability reported.

3.8 Limit what synthetic data can support. Suggested uses, in rough order of acceptability:

Use Acceptability
Stress-testing, red-teaming, coverage of rare Generally appropriate
scenarios
Robustness and paraphrase testing (R.1) Generally appropriate, with real calibration
Conditional on delity evidence and a real
Supplementing small subgroups (R.2)
calibration sample
Supporting a performance estimate for the Conditional, with bridging and sensitivity
intended population analysis
Sole basis for a safety-critical gating estimate Not recommended

4. Combining benchmarking and clinical con rmation evidence

The two sources usually differ in population, input realism, adjudication, whether users act on
outputs, and often device version. Combining them into one estimate risks hiding those differences
and borrowing strength that does not exist. We recommend a default of separate reporting and a
narrow set of conditions for pooling.

4.1 Conditions under which combination may be appropriate. Pooling is more defensible when
all of the following hold, with evidence for each:

1. Same estaminet. Both sources estimate the same quantity (for example, the miss rate on the
same class of presentations, scored with the same rubric).
2. Same device version and con guration. The deployed system, including prompts, retrieval
and model version, is identical or the differences are shown to be immaterial.
3. Comparable input distributions, or a defensible adjustment, with the comparison shown.
4. Comparable reference standard and adjudication, with independence and reliability
documented.

Date 18/10/2026 46 of 131 FDA-2026-N-7874

fi
fi
fl
fi fi
fi
fi
 5.
Exchangeability tested, not assumed. A pre-speci ed check of heterogeneity between
sources, such as comparing estimates on a shared case set (Question 10). Where
heterogeneity is found, pooling is not appropriate.
6. Independence of the data. Cases and tuning are not shared across sources in ways that
double-count evidence, and no benchmark items were used for development.
4.2 Forms of combination, from least to most assumption-laden.

Approach Description Comment
Parallel
Each estimate reported with its own interval Default; transparent
reporting
Hierarchica Benchmark treated as prior information, Requires a justi ed, prespeci ed
l or down-weighted by an estimated or discount and sensitivity analysis; I
Bayesian prespeci ed discount, updated with have not veri ed regulatory
borrowing con rmation data acceptability here
Calibration
Benchmark scores mapped to expected real- Depends on the strength of the
-based
world performance using the shared case set benchmark-to-reality relationship
adjustment
Naive
Treat all cases as one sample Not recommended
pooling

4.3 Dynamic borrowing. Where borrowing is used, the amount borrowed should decrease as
con ict between sources increases, and the rules should be set in advance. A xed weighting chosen
after seeing results is not acceptable.

4.4 Division of labor is often better than combination. A cleaner design is to assign roles:
benchmarking provides coverage and breadth (many scenarios, adversarial and subgroup probes),
while con rmation provides the rate estimate for the intended population. The device’s claim
then rests on con rmation for rates and on benchmarking for demonstrated coverage, with
concordance between them as the link (Questions 7 and 10).

4.5 Situations where pooling is especially inappropriate.

• Safety-critical gating estimates, where the con dence bound matters and optimism from
benchmark data would be hazardous.
• When the benchmark was used in development, so its scores are optimistic by construction
(Question 10).
• When con rmation involves user behaviour and the benchmark scores outputs only.
• When the device version changed between sources.
• When the benchmark depends on synthetic inputs that were not calibrated to real data.
5. Illustrative cases

Scenario Statistical approach Combination
Chest-pain Real symptom narratives, strati ed for acute Separate; con rmation carries the rate
triage, time- conditions; upper bound on miss rate; any- claim
critical
Small miss run Realfailure rate; synthetic
calibration cases
sample plus for coverage
synthetic
Synthetic results reported separately
pediatric supplementation, reweighted and bridged,
and as a bounded supplement
subgroup with sensitivity analysis
with little real Rubric-scored sample of real user questions; Benchmark and con rmation may be
Education
tool, low tier reliability reported combined if estimand, version and
distribution match, with heterogeneity
Date 18/10/2026 47 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fl
 Lab-result Real lab text with errors; synthetic edge Real data for rates; synthetic data for
interpretation cases for unit confusion coverage of implausible values

These are illustrative only and not a proposed classi cation.

6. Cautions

• Large n of synthetic cases is not large effective sample size. Cases from one generator are
correlated and may share blind spots, so the information content is lower than the count
suggests.
• Do not mistake repeated runs for independent cases.
• Do not let a narrow interval from pooled data stand in for evidence about the real
population. Precision without validity is misleading.
• Avoid post hoc choice of data sources, metrics or weights.
• Keep non-inferiority margins and thresholds clinically justi ed, not set to match what
the device achieved.
• Avoid false equivalence. “No signi cant difference” from underpowered subgroup or
synthetic comparisons does not show similar performance.
7. Limitations and open questions

• There is no consensus methodology for combining benchmark, synthetic and real-world
evidence for GenAI devices, and the approaches above are candidates that need evaluation,
including for regulatory acceptability.
• How to estimate the effective sample size of LLM-generated data is unresolved.
• Appropriate discounting in borrowing approaches is hard to justify without data on how well
benchmarks predict real performance, which is the empirical gap noted in Question 10.
• Handling of adjudicator disagreement and LLM-judge error in the nal uncertainty is not
standardised.
• Whether versions that differ slightly can be treated as exchangeable is unclear and probably
depends on the change.
• Guidance on acceptable precision, such as bounds for rare events by tier, would bene t from
stakeholder input and pilot applications.
8. Recommendations

1. Require pre-speci ed estaminets (quantity, input population, unit, run handling, bound),
with precision targets set by clinical consequence.
2. Model layered variability (case, run, paraphrase, conversation, user, site, adjudicator) and
report variance components, with con dence intervals that respect clustering.
3. For safety-critical behaviours, report upper bounds on failure rates and any-run failure
rates, not only averages, and justify sample size accordingly.
4. Anchor primary and gating estimates on real or clinically representative data, and treat
synthetic data as supplementary.
5. For synthetic supplementation, require documentation of generation, delity assessment,
validation against a real calibration sample, label quality checks, independence from the
device’s model class, and sensitivity analysis.
6. Report benchmark and con rmation evidence separately by default, with roles assigned
(coverage versus rate estimation) and concordance shown.
7. Allow combination only when estaminet, version, distribution, reference standard and
independence are shown to match, exchangeability is tested, and borrowing rules are prespeci ed and dynamic.

Date 18/10/2026 48 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi fi
fi fi
fi
fi
 8. Prohibit pooling for safety-critical gating estimates, benchmark data used in development,
and uncalibrated synthetic inputs.
9. Pilot these statistical expectations on real or retrospective submissions before formalising
them.

Question 13 - For which clinical domains, device functions, or subpopulations is synthetic data
particularly well-suited, or particularly inadequate, as a supplement to real-world evidence?
What safeguards would mitigate the risk that synthetic data generated by models of the same
class as the device under evaluation reproduces the very performance gaps the evaluation is
intended to detect, particularly for underrepresented subgroups?

1. Summary position

Synthetic data suitability should be judged by what the data must faithfully represent and
whether the generator can be trusted to represent it. Synthetic data are best suited to tasks where
the relevant structure is rule-governed, veri able and independent of the generator’s
knowledge, such as unit-conversion errors, dosing arithmetic, scope-boundary probing and
paraphrase robustness. They are least suited to tasks where the relevant variation is tacit, culturally
embedded, rare or poorly documented, such as authentic patient language, atypical presentations,
and the experience of underrepresented subgroups. The core risk is circularity: a generator of the
same class as the device shares its blind spots, so synthetic cases may be easy for the device exactly
where real cases would be hard. We recommend a layered set of safeguards (Section 5), with the
central principle that independence and real-data anchoring matter more than volume, and that
synthetic data should not be the sole basis for subgroup claims.

2. Why the circularity problem is real

Several mechanisms can make synthetic evaluation data uninformative about the gaps it is meant to
expose:

Mechanism How it undermines evaluation

Shared If the generator does not know a presentation, dialect or guideline, it will not
knowledge gaps produce it, so the gap is never tested

Stereotype and Generators tend toward prototypical, “clean” cases, and underrepresent atypical,
homogenization noisy or marginal presentations
Distributional Outputs concentrate on likely patterns, shrinking the tail where failures
smoothing concentrate

Stylistic A model may handle text in its own generation style more easily than real
familiarity human text, in ating performance
Label
If a model assigns the “correct” answer, its errors become ground truth
contamination
Shared training Generator and device may have seen overlapping sources, including the same
data guidelines and the same biases
Caricature of Prompting for a subgroup can yield exaggerated or stereotyped language rather
subgroups than real variation, which is a different failure from the one that matters

Date 18/10/2026 49 of 131 FDA-2026-N-7874

fi
fl
 The last point is easy to overlook. Synthetic subgroup data can fail in two opposite ways: omission
(the subgroup’s real dif culty is absent) or caricature (the generated text is not how real members
of that group write or speak). Either one makes a subgroup performance estimate uninterpretable.

3. Where synthetic data are particularly well-suited

These uses share three features: the target property is checkable without the generator’s
judgment, the failure mode is structural rather than demographic, and over-optimism would be
detected by other evidence.

Domain, function or
Why it suits synthetic data
use
Quantitative and Correct answers can be computed (weight-based dosing, renal adjustment,
measurement tasks unit conversion), so labels are objective. Implausible values, missing units
(E.3) and transcription errors can be injected systematically
Robustness and
Paraphrase, reordering, added noise and irrelevant context can be applied
perturbation testing
to real seed cases, preserving realism while multiplying coverage
(R.1)
Scope and boundary Adversarial, prompt-injection and out-of-scope probes are not about
adherence (S.2) patient realism, and can be generated at scale and re ned by red teams
Safety-critical
recognition on rule- Where escalation criteria are de ned by explicit red- ag rules, scenario
de ned scenarios variants can be built from those criteria, with labels from the rules
(S.1)
Stress-testing long or
Context length, topic switching and cumulative drift can be engineered,
multi-turn behavior
since the point is structural pressure
(R.1, Question 5)
Coverage of rare
Used to ask “does the device handle this at all?”, not “at what rate?”
scenarios, as a probe
Data-poor conditions
needing proof of Early-stage exploration where real data do not yet exist, with explicit limits
concept
Real inputs altered in controlled ways (changing a lab value, adding a
Perturbed real cases contraindication) keep real-world texture while creating counterfactual
pairs

The last row deserves emphasis: synthetic modi cations of real cases are generally safer than fully
synthetic cases, because the realistic structure is inherited from real data and only the targeted
variable changes.

4. Where synthetic data are particularly inadequate

Domain, function or
Why synthetic data fall short
use
Authentic patient Real patients use idiosyncratic, emotional, fragmented, culturally speci c
language and code-switched language that generators smooth over (E.4, R.2)

Date 18/10/2026 50 of 131 FDA-2026-N-7874

fi
fl
fi
fi
fi
fi
fi
Subgroup
performance claims, The generator is least reliable exactly where training data are thin, and
especially for caricature is a risk. Synthetic data cannot establish that a device works
underrepresented for a group the generator cannot represent
groups
Generators reproduce typical presentations, so atypical forms of common
Atypical and rare diseases are underrepresented (for example atypical myocardial
presentations infarction in women or older adults, which is a point about the clinical
literature that I describe from general knowledge, not a cited nding)
Synthetic distributions do not carry real base rates, so over-escalation
Prevalence and rate
burden, predictive values and population-level effects cannot be
estimation
estimated
Measurement and
Real noise, artifacts and instrument-speci c behavior are hard to simulate
signal-processing from
faithfully, and users cannot assess them (Question 1 detectability)
real sensors or assays
Automation bias, minimization, pushback and care-seeking decisions
Real user behavior depend on real people. Simulated patients are poor proxies for how real
users act on advice (Question 5)
Pediatric, geriatric,
pregnancy and other Population-speci c physiology and presentation are where generators are
physiologically distinct least trustworthy, and errors are consequential
groups
Mental health, distress
Authentic affect, risk disclosure and ambiguity are dif cult to simulate,
and crisis
and caricature could mislead evaluation of S.1 and E.4
communication
Low-resource
The generator’s competence is lowest there, which is also where the
languages, dialects and
device is likely to be weakest (R.2)
low health literacy
Rare diseases with The generator has little to draw on, so invented cases may be clinically
sparse literature implausible
Sole basis for gating on
Any residual circularity directly threatens patient safety (Question 12)
safety-critical behavior

A useful rule of thumb: synthetic data are weakest where the device is most likely to fail,
because both depend on how well the model class represents the population. That is the substance
of the circularity concern.

5. Safeguards against reproducing the gaps the evaluation should detect

5.1 Independence of the generator.

• Use a generator from a different model family, developer and, where possible, training
lineage than the device’s underlying model. This reduces shared blind spots but does not
remove them, since many models share web-scale data.
• Disclose generator identity, version and prompts, and the relationship between the generator
and the device model.
• Where independence is impossible (few available models), state the limitation and weight
the synthetic evidence accordingly.
• Avoid using the device itself or its foundation model to generate or label its own test data.
5.2 Human authorship and grounding.
Date 18/10/2026 51 of 131 FDA-2026-N-7874

fi
fi
fi
fi
 • Clinician-authored cases for high-consequence and atypical scenarios, which are slower
but not tied to generator knowledge.
• Seeding from real cases, de-identi ed, with controlled perturbation rather than free
generation.
• Community or patient involvement in writing and reviewing subgroup-relevant inputs,
including people who actually use the dialects, registers and contexts of interest, to reduce
caricature.
• Adversarial authoring by red teams instructed to nd what the device gets wrong, since
synthetic data generated “to be representative” tends to avoid failures.
5.3 Validation against real data.

• Keep a real calibration sample for every stratum where synthetic data are used and
compare device behaviour on both (Question 12, Section 3.4).
• Report whether error types on synthetic data match those seen on real data. A synthetic set
on which the device makes none of the mistakes seen in real use is suspicious.
• Do not rely on feature similarity alone. Check that the synthetic set exposes failures the
real set does.
• Where a subgroup has almost no real data, state that synthetic evidence cannot substitute
and ag the subgroup as unvalidated.
5.4 Realism and delity assessment.

• Independent clinician review of a sample for clinical plausibility and correct labels, with
agreement reported.
• Detectability testing: can reviewers or a classi er distinguish synthetic from real inputs? If
easily, the synthetic data may differ in ways that affect device behaviour. This is a signal, not
a proof.
• Measure diversity and tail coverage, including lexical and clinical variety, and compare it
with real data. Report how much of the real distribution’s tail is represented.
• Check for caricature in subgroup data via review by members of the relevant community or
experts in the relevant language and culture.
5.5 Label integrity.

• Source labels from guideline-grounded rules, computation or independent clinician
adjudication, not from a model of the same class.
• If an LLM adjudicator is used, validate it against clinicians on a held-out sample and report
error patterns (Question 10).
• Report label reliability, and treat disagreement as information.
5.6 Controls on how synthetic data are used in estimation.

• Separate reporting of real and synthetic results, with no blending into headline estimates
(Question 12).
• Sensitivity analysis over plausible mismatch between synthetic and real distributions.
• Treat synthetic data as supporting coverage claims, not rate claims, and not as the sole basis
for any safety-critical gating or subgroup equivalence claim.
• Do not count synthetic cases as independent samples. Their effective sample size is
smaller than their number (Question 12).
5.7 Process safeguards.

• Pre-specify generation methods, review procedures and how synthetic data will be used
before testing, so that data are not generated until the device passes.
• Maintain a development/evaluation rewall: synthetic cases used to tune the device cannot
be used to evaluate it (Question 10).

Date 18/10/2026 52 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fl
 • Refresh and sequester evaluation sets so that generators and devices do not converge on
the same patterns over time.
• Document failures to generate realistic cases for a subgroup. If the generator could not
produce plausible content, that is itself evidence about the limits of the approach.
5.8 Subgroup-speci c safeguards.

• For underrepresented subgroups, prioritise collecting real data (targeted recruitment,
partnerships, de-identi ed data from relevant sites) over scaling synthetic data, and report
the sample size achieved.
• Where real data are unavailable, label subgroup performance claims as limited by data
availability and rely on post-market monitoring strati ed by subgroup (Section VI).
• Evaluate mismatch between demographic descriptors and real variation. A synthetic
“patient with limited English pro ciency” is not a validated representation of such patients.
• Avoid constructing subgroup cases by swapping demographic labels into otherwise
identical cases without checking that this re ects real differences. This can detect certain
biases (counterfactual fairness probes), but it does not show performance on real subgroup
language or presentation. It is a probe of sensitivity to demographic cues, a different
question.
6. A suitability screen sponsors could apply

A short pre-speci ed screen, submitted with the evaluation plan:

Question If “no” or “unknown”
Is the target property checkable without the
Do not rely on synthetic data for this property
generator’s judgment?
Is the generator independent of the device’s Downgrade the evidentiary weight, and add
model class? human-authored data
Do real data exist to calibrate against for this
Treat synthetic results as exploratory only
stratum?
Do synthetic and real error patterns match in the
Do not extrapolate to the real distribution
calibration sample?
Is the use for coverage or probing rather than
Not acceptable for rate or gating claims
rates and gating?
Has independent review con rmed realism and
Do not use
label quality?
Would an error in this stratum cause severe or Require real or clinician-authored data as the
irreversible harm? primary evidence

7. Illustrative cases

Scenario Suitability Suggested approach
Dosing calculations across renal Computable labels, systematic variation; con rm
Well-suited
function levels on a real sample
Robustness of triage advice to Perturb real seed cases; check any-run failure
Well-suited
paraphrase and noise rates
Prompt-injection testing of a scope
Well-suited Red-team-authored and generated probes
boundary

Date 18/10/2026 53 of 131 FDA-2026-N-7874

fi
fl
fi
fi
fi
fi
fi
fi
 Triage performance for patients Inadequate Real data from the relevant community;
writing in a regional dialect or as primary community review; synthetic data only for
non-standard English evidence probes
Inadequate
Atypical cardiac presentation in Clinician-authored and real cases; synthetic data
as primary
older women for coverage only
evidence
Synthetic computation for arithmetic; real or
Pediatric dosing for infants Mixed clinician-authored cases for presentation and
context
Inadequate Clinician and lived-experience input, carefully
Distress and self-harm disclosure
as primary designed standardized scenarios; synthetic data
handling
evidence only for limited probing
Mixed to Clinician-authored cases from literature and
Rare disease differential
inadequate registries, with expert review

These are illustrative only and not a proposed classi cation.

8. Cautions

• Volume is not validity. Large synthetic sets can look rigorous while carrying shared blind
spots.
• Independence from the generator is partial. Different model families often share training
sources and similar biases, so independence reduces but does not eliminate circularity.
• Synthetic data can create false reassurance for underrepresented groups, which is
worse than having no data, because it suggests a group was tested.
• Do not equate a counterfactual-fairness probe with subgroup validation.
• Privacy is not a justi cation by itself. Synthetic data derived from real patient data may
still carry privacy risk, and its use should not become a way of avoiding collection of
representative real data.
• Avoid overcorrecting. Excluding synthetic data entirely would remove useful, scalable
tools for robustness, boundary and computation testing, and would con ict with least
burdensome principles.
9. Limitations and open questions

• I am not aware of an established, validated method for measuring how well a given synthetic
set exposes the failure modes of a given device, and the checks above are proposals. Studies
that compare device failure rates on synthetic versus matched real data across subgroups
would be directly informative.
• Whether generators from different families are independent enough to matter is an empirical
question I do not answer.
• Detectability of synthetic data (can it be told from real data) is an imperfect proxy for
delity.
• The minimum real data needed to calibrate synthetic data for a subgroup is unknown and
likely varies.
• Evidence on caricature in synthetic subgroup text is limited, and I describe the concern from
general understanding of the eld without citing speci c studies.
• How to credit synthetic data for subgroups where real data cannot be obtained at all is a
policy question that I ag but do not resolve.
10. Recommendations

Date 18/10/2026 54 of 131 FDA-2026-N-7874

fl
fi
fi
fi
fi
fl
fi
 1. Treat synthetic data as well-suited for computable, structural and adversarial properties
(quantitative tasks, robustness, scope boundaries, rule-de ned escalation, perturbation of
real cases) and inadequate as primary evidence for authentic language, atypical
presentations, real user behaviour, prevalence and rates, and underrepresented or
physiologically distinct subgroups.
2. Prefer perturbation of real cases over fully synthetic generation where realism matters.
3. Require generator independence from the device’s model class, disclosure of generator and
prompts, and no use of the device or its foundation model to generate or label its own test
data.
4. Require human-authored and community-reviewed content for high-consequence,
atypical and subgroup-speci c scenarios.
5. Require a real calibration sample for each stratum, with comparison of error patterns (not
just feature distributions) between synthetic and real data.
6. Require independent clinician review of realism and label quality, and guideline-grounded
or independently adjudicated labels.
7. Do not allow synthetic data to be the sole basis for safety-critical gating or for subgroup
equivalence claims, and report subgroups lacking real data as unvalidated.
8. Report synthetic and real results separately, use sensitivity analysis, and do not count
synthetic cases as independent samples.
9. Pre-specify generation and use, maintain a development/evaluation rewall, and refresh
sequestered sets.
10. Prioritise collection of real data for underrepresented subgroups, and use subgroupstrati ed post-market monitoring where it remains scarce.
11. Support research that directly compares device performance on synthetic and matched real
data, and pilot a suitability screen before formalising it.

Question 14 - For open-ended device outputs, how should performance comparators and
acceptance criteria be selected? When a panel of qualified clinicians serves as the comparator,
how should the applicable standard (for example, the standard of care versus the
performance of a median clinician in practice) be defined and justified? Should generalist or
specialist physicians be used as a performance standard? When should human-AI team
performance, rather than the device operating alone, serve as the basis for evaluation?

1. Summary position

The comparator should be chosen to match the decision the device is meant to change, and
acceptance criteria should be derived from clinical consequences, not from what current systems
can achieve. We recommend that sponsors pre-specify a comparator rationale covering (a) the
reference type (outcome-based truth where available, otherwise adjudicated expert consensus), (b)
the performance standard (a de ned standard of care for safety-critical behaviours, and a
demonstrated clinician distribution for non-critical ones), (c) the clinician population (matched to
the intended role, with specialist input for the reference and generalist performance as the realistic
baseline where the device supports generalists), and (d) the unit evaluated (device alone, or humanAI team, depending on intended use). “Equal to or better than a median clinician” is a useful default
for some tasks but is inadequate on its own for safety-critical behaviours, where the median can be
a low bar and where device errors are systematic and replicated at scale (Question 7).

2. Selecting comparators for open-ended outputs

Date 18/10/2026 55 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
 Open-ended outputs often have no single correct answer, so the comparator has to do two jobs that
are often con ated:

Role Question it answers Typical source
Reference Is this output acceptable or Outcome-based truth, or expert panel
standard correct? consensus against guidelines
Performance Is the device as good as what it
Clinician performance on the same task
benchmark replaces or supports?

Keeping these separate avoids a circular design in which clinicians are both the yardstick and the
competitor.

Options, with their strengths and weaknesses:

Comparator Strengths Weaknesses
Outcome-based truth
Objective; independent Often unavailable; confounded by treatment;
(con rmed diagnosis,
of opinion not de ned for many open-ended outputs
observed course)
Applicable to openCostly; panels disagree; may embody
Expert panel consensus ended tasks; can encode
opinion rather than evidence
guidelines

Guideline or rubric Transparent, Guidelines can be silent, outdated or
adherence reproducible inapplicable to the individual case

Realistic; re ects what Practice variation is large; the median may
Median or typical
the device would be suboptimal; re ects conditions the
clinician in practice
replace clinician works in
Pooled or best-practice May exceed what is achievable in routine
Demanding standard
clinicians care
No-device counterfactual
Directly tests bene t Needs a de ned alternative
(Question 15)

A single comparator will rarely suf ce. A common sensible structure is expert-adjudicated
reference for correctness, with clinician performance on the same cases for context.

3. De ning the standard: standard of care versus median clinician

These are different constructs and answer different questions.

Standard Meaning Appropriate when
Standard of What a reasonable, well- Safety-critical behaviors; escalation,
care informed clinician should do, contraindications, dosing; anything where being
(normative)
Median anchored in guidelines and common
The deviceis not beingoracceptable
replaces supplements usual practice
What clinicians actually do
clinician and the aim is non-inferiority to it; non-critical
(descriptive)
High- tasks where
Devices practice
intended varies without
to extend clear
specialist harm
capability;
What experts achieve
performing or where the bene t claim is expert-level
or specialist performance

Date 18/10/2026 56 of 131 FDA-2026-N-7874

fi fi
fi fl fl fl fi fi fi
fi
 Why the median alone is risky. A device matching the median clinician reproduces the median
error rate, but unlike a clinician it does so systematically and at scale, and with the same errors
across all users. A device that matches median performance may be acceptable for low-consequence
tasks and unacceptable for time-critical ones. The more severe the consequence of an error, the less
appropriate a descriptive standard becomes.

How a sponsor could de ne and justify the standard:

1.State the construct (normative or descriptive) and why it ts the intended use and tier.
2.De ne the reference process explicitly, including panel size, composition, specialty mix,
independence from the sponsor and foundation model developer (consistent with the paper’s
adjudication principles), blinding to whether an output came from a device or a clinician,
and how disagreements are resolved.
3. Ground the standard in documented sources (current guidelines, consensus statements)
and record where judgment replaced them.
4. Report adjudicator reliability, and do not treat panel unanimity as given. Where experts
disagree, the disagreement is information about the task, and a case set restricted to
consensus cases will overstate device performance on genuinely ambiguous situations.
5. Handle unacceptable-but-common practice. Where clinicians themselves often deviate
from a guideline, the sponsor should state whether the device is held to the guideline or to
the observed practice, and justify the choice.
6. Specify the clinician sample for any performance comparison: number, experience,
setting, whether they worked under realistic time and information conditions, and how they
were selected, since volunteer clinicians in a study tend to perform better than in routine
practice.
7. Version the standard. Guidelines change, so the date and version of the standard should be
recorded and re-examined at re-benchmarking (Section VI).
A tiered approach follows naturally: a normative standard with a pre-speci ed oor for safetycritical elements, and a descriptive clinician-distribution comparison for other elements.

4. Selecting acceptance criteria

4.1 Derive from consequences. The margin should re ect what an error costs. A non-inferiority
margin of a few percentage points may be tolerable for a low-consequence informational task and
unacceptable for a missed time-critical escalation.

4.2 Use different criterion types for different elements.

Element type Suggested criterion
Safety-critical (S.1,
Absolute oor or ceiling on a failure rate, with an upper con dence bound,
S.2, safety-critical
prespeci ed from the harm analysis; not relative to clinicians alone
R.1)
Clinical pro ciency Non-inferiority to a de ned clinician comparator, or agreement with the
(E.1 to E.3) adjudicated reference above a threshold
Rubric thresholds with reliability, ideally with comprehension outcomes in
Communication (E.4)
representative users
Subgroup Consistency criteria across subgroups with stated precision, and no
performance (R.2) subgroup below the safety oor

Date 18/10/2026 57 of 131 FDA-2026-N-7874

fl
fi
fi
fi
fl
fl
fi
fi
fi
fl
fi
fi
 4.3 Justify margins. Non-inferiority margins should be tied to clinical importance (for example, the
largest loss of accuracy that would not change expected outcomes), not to the device’s observed
performance, and not chosen after seeing data.

4.4 Be explicit about direction. For some behaviours the aim is “no worse than”; for others (a
known gap in practice that the device is meant to close) it is superiority. The claim should determine
the test.

4.5 Avoid composite scores that hide failures. As in Questions 7 and 12, safety-critical elements
gate individually, and strong performance elsewhere does not offset a failure.

4.6 Account for variability in the comparator. Clinician performance varies between individuals.
“Better than a clinician” should say whether it means the average clinician, a majority of clinicians,
or a speci ed percentile, and the comparison should use appropriate methods for multiple readers
and cases (as reader studies do).

4.7 Pre-specify handling of disagreement between device and reference (which cases are
reviewed, by whom, blinded or not), so that disagreements are not resolved in the device’s favour
after the fact.

5. Generalist versus specialist physicians as the standard

This links to Question 4 and Question 15. We suggest separating who de nes correctness from
who is the realistic competitor.

Role Suggested population Rationale
De ning the Clinicians with expertise in the Correctness in a specialist area requires
reference (what is domain of the task, with specialist specialist judgment
correct)
Performance input for
The specialist-domain
clinician population the A generalist-support tool should be
comparator (what device would actually be used by compared with generalist performance,
the device replaces
Aspirational or in place of
Specialists, where the claim is and a specialist-support
Needed toolmakes
only if the sponsor with that
benchmark expert-level performance claim

Practical implications:

• Device meant to extend specialty knowledge to generalists: compare device-supported
generalists with unaided generalists (the realistic counterfactual) and check performance
against a specialist-adjudicated reference. Equaling specialists may not be necessary for
bene t, but safety-critical oors still apply, and the device should not be presented as
equivalent to a specialist unless shown.
• Device meant to replace specialist review (for example autonomous interpretation): the
specialist standard is the relevant comparator, since the device takes over a specialist
function.
• Device used by specialists: compare with specialist performance, since the bene t would be
ef ciency or error reduction at expert level.
• Mixed or unclear user populations: evaluate per user group, and label the claims
accordingly.
A caution on choosing the lower bar. Selecting generalists as the comparator makes the device
look good when the generalist baseline is weak. That is legitimate where generalists are the real
alternative, and misleading where the device could be used in place of a specialist. The sponsor

Date 18/10/2026 58 of 131 FDA-2026-N-7874

fi
fi
fl
fi
fi
fi
fi
 should justify the comparator by actual deployment pathways, not by convenience. Regional and
system differences matter too, since the available specialist access varies.

6. When human-AI team performance should be the basis for evaluation

The unit of evaluation should match the unit of use.

Intended use Basis for evaluation

Fully autonomous operation (no human Device alone, with human-AI evidence not
review before action) applicable, and highest rigor

Clinician reviews and decides on every Human-AI team as the primary basis; device-alone
output (decision support) performance supporting

Human oversight that is nominal or Both: the team as actually operating, and device
intermittent (spot-check, exception review, alone as a safety oor, since the human check may
monitoring) not catch errors
Device alone, plus evidence of patient behavior (the
Patient-facing, no clinician in loop
patient is the “team member”)
Human supervision credited for risk tier
Team evidence required to justify the credit
reduction (Question 1)

Reasons to evaluate the team where a human is in the loop:

• Interaction effects. A device that is accurate alone can degrade clinician performance
through automation bias, and a less accurate device can still help if clinicians catch its
errors. Device-alone accuracy does not predict team accuracy reliably.
• Credit for supervision should be earned. If a lower tier depends on HCP supervision, the
team’s ability to catch device errors has to be demonstrated, not assumed (Question 1).
• Realism. Team evaluation re ects the actual work ow, time pressure and information
available.
Reasons to also report device-alone performance:

• It reveals what the human is being asked to catch, and how often.
• Human oversight degrades over time with fatigue and complacency, so device-alone safety
is the oor if oversight weakens.
• Device changes (model updates) alter device-alone behaviour in ways that require reevaluation of the team.
Design considerations for team studies:

• Measure whether users catch errors, by including cases where the device is wrong, in
realistic proportions. A study with few device errors cannot show that reviewers would catch
them.
• Compare against unaided performance and, where relevant, against a different
con guration (for example a display that shows reasoning and one that does not).
• Use realistic users, time and work ow, and report training and experience.
• Measure reliance and override patterns, including inappropriate agreement and
inappropriate overrides.
• Pre specify the endpoint (decision accuracy, time, safety events) and the clustering by
clinician.
Date 18/10/2026 59 of 131 FDA-2026-N-7874

fl
fl
fl
fl
fi fl
 • Do not assume the team result transfers across user groups. A study with specialists may
not transfer to generalists.
7. Illustrative cases

Device Comparator and reference Criterion Unit
Patient-facing Outcome-based or expert- Absolute sensitivity oor for acute Device
chest-pain adjudicated reference on real coronary syndrome with upper alone, with
triage narratives; nurse triage or usual bound on miss rate; over-escalation patient
HCP-facing self-directed care as
Guideline-based realistic
rubric with expert reported separately
Non-inferiority (Questionwith
on accuracy, 6) behavior
Human-AI
guideline review; unaided clinician on same prespeci ed margin; no critical team
summarizer
Specialist- cases errors
Specialist-adjudicated reference; Improvement over unaided Human-AI
domain unaided generalists as realistic generalists, plus safety oor on team, with
interpretation baseline missed critical ndings devicesupporting
Autonomous Very low error ceiling on alone
Guideline standard and clinician Device
antibiotic contraindication and dosing; nonadjudication alone
prescribing inferiority to clinician prescribing
for con rmed Expert-adjudicated rubric;
Lab-result Accuracy threshold plus Device
interpretation comprehension in representative comprehension and behavior alone, plus
for patients patients criteria patient
behavior
These are illustrative only and not a proposed classi cation.

8. Cautions

• Do not use clinicians as both the reference and the competitor without separation, or the
comparison becomes circular.
• Do not de ne acceptable performance by current device capability. A threshold set to
match what systems can achieve is not tied to safety.
• Avoid selecting easy comparators. Weak or non-representative clinician samples, or
unrealistic conditions, in ate relative performance.
• Avoid restricting the case set to consensus cases. Ambiguous cases are where open-ended
devices behave least predictably.
• Do not treat “as good as a clinician” as suf cient for rare, severe harms, since scaled,
correlated device errors differ from independent human errors.
• LLM adjudicators need independence and validation against clinicians, as the paper
notes.
• Beware of study conditions that differ from practice, including time, information and
incentives.
• Do not assume the comparator stays xed. Guidelines and practice evolve.
9. Limitations and open questions

• There is no agreed method for de ning “the standard of care” for open-ended GenAI
outputs, and legal and clinical notions of the standard differ. We use the term descriptively
and do not address its legal meaning.
• Inter-clinician variability in open-ended tasks is large and not well characterised for many
tasks, which complicates margin-setting.
• Evidence on how clinicians respond to GenAI errors, and how much human oversight
catches, is limited, so team-based credit is dif cult to quantify. This is an empirical question
I do not answer.

Date 18/10/2026 60 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fl
fl
fl
fi
fi
fi
fi
 • How to set margins and oors by tier is unresolved and would bene t from stakeholder
input and pilot applications.
• Whether CDRH, consensus standards or sponsors should de ne task-speci c standards is a
governance question I ag but do not resolve.
• Comparisons with specialists may be unavailable where specialist data do not exist or access
is the very problem the device addresses.
10. Recommendations

1. Require a pre-speci ed comparator rationale that separates the reference standard
(correctness) from the performance benchmark (relative performance).
2. Use outcome-based truth where available, otherwise independent, documented expert
adjudication with reliability reported and disagreement cases retained.
3. Apply a normative standard (a de ned standard of care) with a pre-speci ed oor for
safety-critical behaviours, and a descriptive clinician-distribution comparison for lowerconsequence tasks. Do not rely on the median clinician alone for severe or time-critical
functions.
4. Derive acceptance criteria and margins from clinical consequences, set them before testing,
and report con dence bounds.
5. Use specialist input to de ne correctness in specialist domains, and choose the
performance comparator by actual deployment pathway (generalist, specialist, or unaided
counterfactual), with the choice justi ed.
6. Evaluate the human-AI team where a clinician reviews outputs, and require demonstration
(including seeded device errors) that supervision catches errors before crediting it for a
lower tier. Evaluate the device alone for autonomous and patient-facing functions, and
report it alongside team results as a oor.
7. Gate safety-critical elements individually and avoid composite scores.
8. Document clinician sample characteristics, study conditions and standard versions, and reexamine them at re-benchmarking.
9. Pilot comparator and margin-setting approaches with sponsors and reviewers before
formalising them.

Question 15 - Are there ways in which performance might be assessed relative to the care,
technology, or course of action likely to occur in the absence of the device, rather than to the
comparators described in this section? What approaches might be used to identify and justify
a comparator such as unaided clinical judgment, delayed specialist review, or no intervention?

1. Summary position

Yes. Assessing a device against the counterfactual (what would happen without it) answers a
different question from comparison with a clinician panel. The panel comparison asks “is the output
as good as an expert’s?” The counterfactual comparison asks “does using the device leave patients
and clinicians better off than the realistic alternative?” For many GenAI devices, especially those
that extend access (generalist support, patient-facing guidance, after-hours triage), the second
question is the one that bears on bene t-risk. We recommend that sponsors identify the
counterfactual from actual care pathways in the intended setting, justify it with data where
possible, and use it alongside, not instead of, an absolute safety oor on safety-critical behaviours
(Question 14). A device that beats a poor alternative can still be unsafe in absolute terms.

2. Why the counterfactual matters

Date 18/10/2026 61 of 131 FDA-2026-N-7874

fl
fi
fi
fi
fl
fi
fi
fl fi
fi
fi
fl
fl
fi
fi
 • It re ects bene t, not only competence. A device slightly worse than a specialist may still
improve care if the alternative is a four-week wait.
• It re ects the claim. Devices that expand access or speed rest their bene t on the gap
between what they provide and what patients otherwise get.
• It reframes risk. The relevant harm is the difference in harm between the device pathway
and the alternative pathway, including harms of doing nothing.
• It matches the paper’s bene t-risk orientation and the least burdensome principle, since
it may support authorisation of devices that would struggle against a specialist-level
standard but offer clear net bene t.
It also has costs: it is context-speci c, the alternative changes over time, and favourable
comparison against a weak baseline can mask unacceptable absolute risk.

3. Types of counterfactual

Counterfactual Meaning Suited to

Unaided
Decision-support tools for
clinical The same clinician without the device
HCPs
judgment

Usual care Whatever the setting currently does (triage line,
Work ow-embedded devices
pathway standard work ow, routine referral)
Delayed
Tools giving interim guidance
specialist The patient waits for specialist input
to generalists or patients
review
No professional Patient self-manages, searches online, or does Patient-facing consumer-style
input not seek care tools
Existing non- Search engines, general chatbots, symptom Patient-facing information
regulated tools checkers already in use functions
Existing Where a predicate-like
A legally marketed comparator device
cleared devices comparison is available
Nothing happens (for example, no monitoring or Surveillance, outreach, and
No intervention
no outreach) monitoring functions

The right choice depends on what the user would otherwise do, which is an empirical question.

4. Approaches to assess performance against the counterfactual

4.1 Randomised designs. Randomise users, clinicians, clinics, or time periods to device or usual
care. This gives the cleanest estimate of effect on decisions and outcomes. Options include
individual, cluster, and stepped-wedge designs (Question 11). Limits: cost, contamination between
arms when clinicians use the device for some patients and not others, and under powering for rare
events.

4.2 Paired or crossover reader studies. The same clinicians handle the same cases with and
without the device, ideally with washout and counterbalanced order. This measures the device’s
effect on decisions without exposing patients, and suits HCP-facing functions. Limits: simulated
conditions, and carryover effects.

4.3 Pragmatic and quasi-experimental designs. Where randomisation is impractical:

Date 18/10/2026 62 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fl
fl
fl
fl
 •Before-after comparisons, which are vulnerable to secular trends.
•Interrupted time series with comparison units.
•Difference-in-differences across sites that did and did not adopt.
•Matched cohorts of device users and non-users.
These can use real-world data but carry confounding, and the assumptions (parallel trends,
no unmeasured confounding) should be stated and tested.
4.4 Historical or external controls. Compare with data from the pre-device period or from other
sites. Acceptable only with demonstrated comparability of populations, care patterns, and outcome
de nitions, and with bias analysis. Weakest for fast-changing practice.

4.5 Retrospective counterfactual comparison on real cases. Run the device on historical inputs
and compare its recommendations with what actually happened (the observed counterfactual),
judged against an adjudicated reference or later outcomes. For example: how often would the
device have escalated cases that were in fact missed or delayed in usual care? Useful and lowexposure, but it shows what the device would have said, not what users would have done with it
(Question 11, Section 2).

4.6 Shadow deployment against actual decisions. Record device outputs alongside decisions
actually made, and examine where they diverge and which was right. Gives the realistic baseline
performance of usual care on the same cases.

4.7 Modelling and simulation of pathways. Use decision-analytic or simulation models
combining measured device performance, measured baseline performance, and assumptions about
user uptake and behaviour to estimate net effects (for example time to treatment, missed diagnoses,
unnecessary visits). Appropriate as supporting evidence or where trials are infeasible, provided
assumptions are explicit and sensitivity analysis is reported. Not appropriate as the sole evidence at
higher tiers.

4.8 Natural experiments and registry-linked analyses. Staggered rollouts, access disruptions, or
registry data can provide counterfactual contrasts with real outcomes, at the price of confounding.

4.9 Net-bene t and harm-bene t framing. Rather than comparing a single accuracy number,
express results as changes in clinically meaningful events: missed emergencies averted, delays
avoided, unnecessary visits added, errors introduced. This captures both directions of error
(Question 6) and the harms of the alternative.

5. Identifying and justifying a counterfactual

A sponsor could submit a short counterfactual rationale, pre speci ed, with these elements:

1. Describe the care pathway without the device in the intended setting: who the user is,
what they would otherwise do, what resources exist, and how long each step takes.
2. Ground it in data. Sources might include observational data on current practice, wait times,
triage line performance, rates of delayed or missed care, surveys or logs of what users do
when they have no professional access, and published performance of existing tools. Where
data are limited, say so and test sensitivity to the assumed baseline.
3. Quantify the baseline’s own performance on the same measures and cases, not only the
device’s. An unmeasured baseline cannot support a relative claim.
4. Show representativeness. Is the baseline from the same population and setting as the
intended use? Academic-centre baselines may not represent community or rural care.

Date 18/10/2026 63 of 131 FDA-2026-N-7874

fi
fi
fi fi
 5. Address heterogeneity. The counterfactual differs by setting (urban versus rural, insured
versus uninsured, daytime versus after-hours). Report by setting, and avoid generalising
from one pathway.
6. Address how the device changes the pathway. Devices alter behaviour: they may increase
care-seeking, shift referrals, or lead users to skip professional care they would have sought.
The comparison should include these displacement effects, not just the device-user
interaction.
7. State the claim the comparator supports, and avoid claiming more. “Better than waiting
for specialist review” does not support “equivalent to a specialist.”
8. De ne in advance what would make the comparator inappropriate, and a fallback.
6. Conditions under which counterfactual comparison is appropriate or
insuf cient

Situation Counterfactual role
Access-extending device where alternative is delay Strong primary framing, with an absolute
or no care safety oor
Decision support where clinicians remain Unaided clinician comparison, via reader or
responsible pragmatic studies
Low-consequence informational tools Often suf cient with modest evidence
High-consequence, time-critical, autonomous Necessary but not suf cient; an absolute oor
functions on failure rates still applies
Devices whose alternative is itself unsafe or Informative, but the device should not be
unreliable (for example unvetted online advice) authorized only because the alternative is poor
Settings where the baseline is changing rapidly (for
Baseline needs periodic re-estimation
example widespread use of general chatbots)

A recurring caution is the oor problem: choosing a weak counterfactual makes almost any device
look bene cial. This is the main risk and is why we recommend pairing counterfactual evidence
with absolute safety thresholds on safety-critical elements, and why sponsors should justify the
counterfactual by data, not convenience.

7. Speci c comparators raised in the question

Unaided clinical judgment. Suitable for HCP decision support. Justify by showing the clinician
population and conditions match intended use. Measure unaided performance on the same cases
under the same time and information conditions. Note that clinicians who know they are in a study
may perform differently from routine practice.

Delayed specialist review. Suitable where the device gives interim guidance pending specialist
input. Justify with data on actual wait times and what happens during the wait (deterioration, ED
visits). Evaluate whether the device shortens time to appropriate care, avoids harm during the wait,
and does not lead to replacing the referral that should still occur. A device that reduces specialist
referral for cases that needed it would turn a delay comparison into a substitution comparison,
which is a different claim.

No intervention. Suitable for monitoring, outreach, or surveillance functions where, without the
device, nothing is done. Justify by showing that the condition is otherwise undetected or
unaddressed. Here the risk of over-detection (false alarms, over-diagnosis, workload) should be

Date 18/10/2026 64 of 131 FDA-2026-N-7874

fl
fl
fi
fi
fi
fi
fl
fi
fi
 weighed against missed detection (Question 6), since “something is better than nothing” does not
hold when the something causes harm.

8. Cautions

• A weak counterfactual atters the device. Justify with data, and test sensitivity to the
assumed baseline.
• Relative bene t does not replace absolute safety. Apply oors on severe, time-critical
failures regardless of the comparator (Question 14).
• Baselines drift. What users do in the absence of a device changes as other tools spread, so
the counterfactual should be re-examined at re-benchmarking and in post market review.
• Beware of selection into device use. Users who adopt a device may differ from those who
do not, so observational comparisons are confounded unless adjusted.
• Account for harms of the alternative as well as of the device. Harms of delay and of
unveri ed advice are real, and should be counted symmetrically.
• Do not let the counterfactual justify scope creep. A device validated against delay is not
thereby validated for replacing specialist review.
• Ethical limits on control arms. A “no intervention” arm may be unacceptable where the
device addresses a serious, time-sensitive condition, which favours designs that compare
against usual care rather than withholding care. I do not address regulatory requirements for
such studies, which the paper places out of scope.
9. Illustrative cases

Device Plausible Approach Safety oor
counterfactual
Usual care: nursePragmatic or stepped-wedge study; Yes,
After-hours
line, wait until retrospective comparison with what patients sensitivity
patient triage
morning, or self- actually did; net-bene t on missed oor on timeGeneralist Unaided search
directed generalist, emergencies and unnecessary visits critical
Yes, missed
Reader study with and without device; waitsupport for and delayed serious
time data; referral appropriateness
dermatology dermatology lesions
differentials No
Post- referral
monitoring, or Matched cohort or stepped-wedge; time to Yes, missed
discharge scheduled follow- detect deterioration; alert burden deterioration
symptom
Interim up only specialist Outcomes during the wait; referral behavior;
Delayed
Yes
guidance review check device does not displace referral
while
Plain- Existing online Comprehension and behavior testing versus Lower tier,
language information existing sources calibration
condition and accuracy
These are illustrative only and not a proposed classi cation.

10. Limitations and open questions

• There is no standard method for de ning the “realistic alternative” when it varies widely by
setting, and the approaches above are proposals, not validated practice.
• Quantifying what users would do without the device often depends on survey or
observational data of uncertain quality.
• Quasi-experimental designs rest on assumptions that are hard to verify, and I have not
evaluated which are acceptable to regulators.
• Net-bene t analyses require value judgments about relative harms, as in Question 6, and I
do not propose weights.

Date 18/10/2026 65 of 131 FDA-2026-N-7874

fi
fi
fl
fi
fi
fi
fl fl
fi
fl
 • It is unclear how to handle devices that change the baseline itself (for example by shifting
standard practice once widely adopted).
• Whether and how counterfactual evidence could alter the evidence tier for a given device is
a policy question I ag but do not resolve.
11. Recommendations

1. Permit and encourage counterfactual-based assessment as a complement to clinician-panel
comparison, particularly for access-extending, interim-guidance and monitoring devices.
2. Require a pre-speci ed counterfactual rationale describing the no-device pathway,
grounded in data from the intended setting, with the baseline’s own performance measured.
3. Match design to the claim: reader or crossover studies for HCP decision support,
pragmatic, stepped-wedge or cluster designs for work ow-embedded devices, and quasiexperimental or retrospective comparisons where randomisation is impractical, with
assumptions and bias analyses stated.
4. Report results as net clinical effect (events averted and events introduced, in both error
directions), not only accuracy.
5. Keep absolute safety oors on safety-critical behaviours regardless of how favourable the
counterfactual comparison is.
6. Require sponsors to justify that the counterfactual is not unduly weak, report results by care
setting, and run sensitivity analyses on the assumed baseline.
7. Ensure claims do not exceed what the comparator supports, in particular distinguishing
delay-reduction from substitution of specialist review.
8. Re-examine the counterfactual at re-benchmarking and through post market monitoring,
since baselines drift.
9. Pilot counterfactual-based evidence packages with sponsors and reviewers before
formalising them.

Question 16 - Should independent third parties be involved in some or all aspects of a
competency-based approach, including device benchmarking and clinical confirmation? If so,
in what ways might qualified, independent third-party participation contribute to this
approach, and what qualifications and independence criteria should apply? Are there aspects
of the assessment for which third-party involvement would be impractical or inadvisable?
What safeguards or program design features would be critical to prevent third-party
participation from limiting competition or preventing innovation?

1. Summary position

Yes, for some aspects, but not as a blanket requirement. Independent third parties are most valuable
where independence itself is the scarce resource: holding sequestered test material, adjudicating
outputs, and validating benchmarks (Question 10). They are least valuable, or inadvisable, where
the work depends on device-speci c knowledge, iterative development, or sponsor
accountability. We recommend a tiered and modular model: third-party roles are optional at
lower tiers, expected for speci c functions at higher tiers (gating on sequestered sets, independent
adjudication), and always supportive of, not a substitute for, CDRH review and sponsor
responsibility. Program design must guard against four failure modes: capture, concentration, cost
barriers and stagnation. I describe existing programs (ASCA, MDDT) only as the paper does, and I
have not veri ed their current requirements.

2. Where third parties add value

Date 18/10/2026 66 of 131 FDA-2026-N-7874

fl
fi
fi
fl
fi
fl
fi
 Function Contribution Why independence matters
Maintaining Held-out material the sponsor Directly addresses optimization to the
sequestered test cannot see or tune against test and contamination (Questions 10,
sets
Independent Clinician panels (and validated 13)
Removes sponsor in uence on scoring;
adjudication LLM judges) scoring outputs the paper already requires adjudicator
Benchmark Shared, versioned, construct- independence
Avoids each sponsor building and
development and validated assets validating its own; reduces cost
validation
Running the Executing tests on the deployed Prevents selective reporting and repeated
benchmark as a system and reporting results “looks”
service
Red teaming Adversarial testing by people not Finds failures that scripted or in-house
invested in thepatient
deviceprograms, tests miss
Clinical Standardized Pooled infrastructure lowers cost and
con rmation reader-study infrastructure, multi- improves comparability
support site data collection
Curated, de-identi ed real-world Enables real-data anchoring without
Data stewardship
datasets for calibration (Questions every sponsor assembling its own
Postmarket re- 12, 13) independent re-testing and Independence matters most when the
Periodic
benchmarking and sample-based clinician review sponsor has a commercial interest in
monitoring
Standards (Section VI)
Consensus test methods and continued authorization
Consistency across submissions
development reporting norms
A useful framing: third parties can provide independence, scale and shared infrastructure, which
are exactly what a competency-based approach needs and what individual sponsors nd hard to
supply.

3. Where involvement would be impractical or inadvisable

• Device-speci c development and tuning. Third parties cannot own iteration. Involving
them in development would breach the development/evaluation rewall.
• Fast iteration cycles. If every change needs a third-party run, turnaround could slow
development and discourage frequent safety improvements. Sponsors need internal testing
for rapid cycles, with third-party evaluation at de ned milestones.
• Novel or niche devices. Where no quali ed evaluator exists for the clinical domain, a
mandatory requirement would stall review.
• Real-time or continuous monitoring. Day-to-day operational monitoring belongs to the
manufacturer, who is accountable for it. Third parties can audit or sample, not replace it.
• Assessment of sponsor-speci c design decisions (guardrail architecture, change control),
which CDRH reviewers and the quality system handle.
• Determinations of safety and effectiveness. The paper’s concept of a third-party
“certi cate” that CDRH could consider is acceptable as input, but the authorisation decision
and the bene t-risk judgment must remain with FDA. Delegating the determination would
blur accountability.
• Con dential or proprietary access. Some sponsors, especially those using third-party
foundation models, may not be able to give evaluators access to model internals or training
data. Evaluation should rely on behaviour of the deployed system.
• Small sponsors with limited budgets, if third-party fees are mandatory and high (see
Section 6).
4. Quali cations and independence criteria

4.1 Independence criteria. The paper already names independence from the sponsor and from the
foundation model developer. We suggest making it operational:

Date 18/10/2026 67 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fl
fi
fi
fi
fi
fi
fi
fi
 Financial No equity, contingent fees, or revenue concentration above a stated share from
independence a single sponsor
Contingency Payment must not depend on the outcome of the evaluation
Organizational No shared ownership, board or management with the sponsor or foundation
independence model developer
Development
Not involved in developing or tuning the device under evaluation
independence
Competing
interests of Adjudicators and authors disclose consulting, advisory and research ties
individuals
Cross-role An organization that sells development services to sponsors does not also gate
separation those same sponsors ( rewall or exclusion)
Foundation
Disclosure of any relationship with the device’s underlying model developer,
model
including use of that developer’s models in the evaluator’s own tooling
relationship

The last item matters for automated evaluation. An evaluator whose scoring model comes from the
same developer as the device’s model may share blind spots.

4.2 Competence criteria.

• Clinical expertise matched to the domain, with specialty coverage for specialist tasks and
documented credentials of adjudicators.
• Methodological expertise in measurement validation, statistics (clustering, nondeterminism, Question 12), and study design.
• Technical capability to evaluate deployed GenAI systems, including multi-turn, adversarial
and agentic testing.
• Quality systems: documented procedures, version control of test sets, audit trails, data
security and privacy controls.
• Demonstrated reliability: inter-rater agreement, reproducibility across runs and across
evaluator sites, and validation of any LLM-based scoring against clinicians.
• Security of sequestered material: controls against leakage, since a compromised test set is
a weakness for every sponsor using it.
4.3 Assurance of the evaluator. Quali cation should be assessed and periodically renewed, with
performance review. The paper cites ASCA and MDDT as precedents for accreditation and tool
quali cation, and these could inform design, though I have not veri ed how readily they transfer to
GenAI evaluation.

5. Program design features to prevent harm to competition and innovation

The paper explicitly asks about this risk. The main failure modes and safeguards:

Risk How it arises Safeguards
Capture and Evaluator depends Independence criteria above; fee structures not contingent
con icts of on sponsor fees or on outcome; sponsor-blind assignment of evaluators where
interest industry funding feasible; disclosure and audit
One or few bodies Multiple accredited evaluators; interoperable, openly
Gatekeeper
control the gating documented methods; rules against exclusivity; periodic
concentration
benchmark review of market concentration

Date 18/10/2026 68 of 131 FDA-2026-N-7874

fi
fi
fi
fl fi
 Developers
optimize to a xed Sequestered sets that are refreshed and rotated; held-out
Teaching to the
set, narrowing what variants; limits on repeated submissions; evaluation of
test
devices are built to device-speci c content in addition to shared sets
do
Slow update cycles
Stagnation of De ned refresh cadence; processes to add failure modes
lock in outdated
the benchmark from real use (Question 10); sunset and review of assets
tests
Fees or data
requirements Tiered pricing; fee transparency or caps; reduced evidence
Cost and exclude small expectations at low tiers; shared public-good assets;
access barriers developers, optional rather than mandatory use at lower tiers; support
academic groups for non-commercial developers
and startups
Duplication Parallel third-party Clear acceptance rules (what FDA will rely on), de ned
and delay and FDA review turnaround, reuse of results across submissions
Evaluators gain
Intellectual access to Con dentiality obligations; rewalls between evaluation
property and proprietary device and any competing product work; limits on retention and
con dentiality and model reuse
information
One approach
Lock-in of becomes the de Allow sponsors to propose alternative methods with
methods facto standard justi cation; consensus processes with open participation
regardless of t
FDA defers
Regulatory CDRH retains authority to examine underlying data, re-test,
excessively to thirdover-reliance and reject; results treated as evidence, not determinations
party results
Responsibility
Sponsor remains accountable for safety and effectiveness
diffuses between
Accountability (consistent with Question 21); evaluator accountable for the
sponsor, evaluator
gaps integrity of its work; mechanisms for correction and
and foundation
withdrawal of erroneous results
model developer

Several of these are in tension. Sequestration protects against optimisation but concentrates control,
and openness supports competition but invites gaming. We suggest layering: open, public assets for
development; independently held sequestered sets for gating; and the ability for sponsors to
supplement with device-speci c tests.

6. Proportionality by tier

Consistent with the tier-to-evidence mapping in Question 8 (placeholder, untested):

Tier Suggested third-party role
Optional. Sponsor-run benchmarking with prespeci cation and clinician review of
Lower
items. Third-party tools usable voluntarily
Independent adjudication expected; part of the test set independently held or reviewed;
Middle
third-party validation of any sponsor-developed benchmark

Date 18/10/2026 69 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi fi
fi
fi
fi
fi
fi
 Gating on independently held or sequestered sets; independent adjudication;
Higher independent red teaming; third-party involvement in con rmation (for example readerstudy or standardized-patient infrastructure) where feasible

Mandatory involvement at low tiers would add cost without proportional bene t, which con icts
with least burdensome principles.

7. A possible operating model

• Accreditation of evaluators against published independence and competence criteria, with
renewal and audit.
• Modular scope: an evaluator may be accredited for particular functions (adjudication,
sequestered benchmarking, red teaming) and domains.
• Versioned, validated assets with documentation of construct validity evidence (Question
10), refresh schedule and exposure policy (how many times a set can be used before it is
treated as compromised).
• Reporting standard: evaluators report all runs, con gurations tested and failures, not only
passing results.
• Result portability: results reusable across submissions for the same device version, with
clear rules on when a change requires re-evaluation (Questions 22 to 24).
• Appeals and dispute process for sponsors who contest an evaluation.
• Monitoring of the program itself: evaluator performance, inter-evaluator agreement,
market structure, and cost, with periodic public review.
8. Illustrative cases

Situation Third-party role Comment
Patient-facing Sequestered escalation benchmark, independent Independence matters most
chest-pain triage, adjudication, red teaming; support for here; rapid-cycle tuning stays
high tier standardized patient testing
Small developer of Optional use of a shared public benchmark; with sponsor
Mandatory evaluation would
a low-tier sponsor-run testing with independent clinician be disproportionate
education
HCP-facing tool item review clinician adjudication; validation Moderate tier; shared assets
Independent
guideline of sponsor-built test set reduce cost
summarizer
Device built on a Evaluator independent of both sponsor and Model developer cannot be
third-party model developer; evaluation of the deployed the evaluator
foundation model
Rare-condition system
Third-party adjudication may be impractical;
Flexible route needed
tool with few consider sponsor panel with disclosed con icts
experts and CDRH review
These are illustrative only and not a proposed classi cation.

9. Cautions

• Independence is not validity. An independent evaluator can still use a poor benchmark, so
construct validity evidence is still required (Question 10).
• Accreditation can become a barrier. Burdensome quali cation could entrench incumbents,
so criteria should be proportionate and transparent.
• LLM-based evaluators are third-party systems too. They need the same independence
and validation scrutiny as human evaluators.
• Do not outsource judgment. Evaluators generate evidence, and the bene t-risk decision
stays with FDA and accountability with the sponsor.

Date 18/10/2026 70 of 131 FDA-2026-N-7874

fl
fi
fi
fl fi
fi
fi
fi
 • Beware of a “pass the third-party test” culture that replaces clinical thinking with
compliance.
• Avoid exclusivity in access to sequestered data or sets, including preferential access for
af liated sponsors.
10. Limitations and open questions

• I am not aware of evidence on how well third-party evaluation of GenAI devices works in
practice, including cost, turnaround and effect on innovation. Pilot programs would provide
it.
• It is unclear how many quali ed evaluators exist or could emerge, and market structure
could differ by domain.
• The right refresh cadence and exposure limits for sequestered sets are unsettled and involve
trade-offs between independence, cost and comparability.
• How to handle con icts when the best-quali ed evaluators also consult for industry is
unresolved.
• Whether existing mechanisms (ASCA, MDDT, recognised standards) could be adapted, or
whether a new program is needed, depends on details I have not assessed.
• Governance of the shared benchmark ecosystem (who funds, owns and updates it) is a
policy question I ag but do not resolve.
11. Recommendations

1. Support modular, tiered third-party roles, optional at lower tiers and expected for speci ed
functions (sequestered sets, independent adjudication, red teaming) at higher tiers.
2. De ne operational independence criteria ( nancial, contingency, organisational,
development and foundation-model relationships) and competence criteria (clinical,
methodological, technical, quality systems, security).
3. Require disclosure and reporting of all runs and failures by evaluators, and construct
validity evidence for any gating asset.
4. Keep authorisation decisions with FDA and accountability with the sponsor, treating
third-party results as evidence, with CDRH retaining access to underlying data.
5. Protect competition through multiple accredited evaluators, open documentation of
methods, rules against exclusivity, and monitoring of market concentration.
6. Address cost barriers through tiered fees, shared public-good assets, and optional use at
low tiers.
7. Guard against stagnation and teaching to the test with refreshed, rotated sequestered sets
and processes to add real-world failure modes.
8. Preserve sponsor-side internal testing for rapid iteration, with independent evaluation at
de ned milestones.
9. Allow alternative routes where quali ed evaluators do not exist, with disclosed con icts
and CDRH review.
10. Establish appeals processes and periodic public review of the program, and pilot before
formalising.

Question 17 - CDRH is exploring whether a competency-based approach could be applied to
devices that incorporate a variety of underlying model architectures, such as multimodal
vision-language models and generative or predictive world models. Are there aspects of the
described approach that might be ineffective or inapplicable to these devices? What
additional or distinct considerations might need to be addressed?

Date 18/10/2026 71 of 131 FDA-2026-N-7874

fi
fl
fi
fi
fi
fi
fl
fl
fi
fi
fi
 1. Summary position

The competency-based structure (benchmarking, then clinical con rmation, scaled by risk tier) is
largely transferable in its logic but not in its content. The paper’s elements, rubrics and examples
are written for text-centred conversational devices. For multimodal and world-model devices, three
things change: the inputs and outputs are no longer language (so rubric-based clinician scoring
and conversational probes t less well), the ground truth is often more objective (images, signals,
measurements), which in some respects makes evaluation easier and in others exposes the device to
different regulatory expectations, and the failure modes are different (perception errors, spurious
visual cues, compounding prediction error). We recommend that CDRH treat the existing elements
as a core set and publish architecture- or modality-speci c extensions, rather than assuming the
text-oriented elements apply unchanged. I describe world models only in general terms, since this is
a rapidly changing area and I have not veri ed how any speci c architecture behaves clinically.

2. What transfers well

Component Why it carries over
Independent of architecture; the same questions about
Risk tiering by activity and
directiveness, detectability and reversibility apply (Question
consequence
1)

Evaluation of the deployed
Even more important where a vision encoder, language
system, not the foundation model
model and tool layer are combined
alone

Two-stage logic (benchmark, then Still needed; benchmark-to-reality validity is still
con rm) unestablished (Question 10)
Prespeci cation, adjudicator
Architecture-neutral
independence, sequestered data
Safety elements S.1 to S.3 Escalation, scope and calibration remain relevant, though test
(conceptually) methods change
Subgroup performance (R.2) and Central for imaging and sensor data, where acquisition
robustness (R.1) differences are a known driver of failure
Postmarket re-benchmarking and Applies, and drift is often more concrete for imaging (new
change control scanner, protocol, population)

3. Aspects that may be ineffective or inapplicable

3.1 The clinician-credentialing analogy weakens. The analogy rests on open-ended reasoning and
conversation. A vision-language model reading a radiograph resembles a diagnostic reader, for
which established reader-study and diagnostic-accuracy methods already exist. A world model that
predicts patient trajectories or simulates physiology has no close human counterpart being
credentialed, so “passing an examination” is a poor model of what is being assessed. For the latter,
the analogy is closer to validating a prognostic or simulation model, where calibration and
counterfactual validity matter more than competence.

3.2 Rubric- and adjudicator-based scoring may not t. Elements built on clinician scoring of
free-text outputs (E.4 communication, parts of S.3) assume language is the output. For image-in,
Date 18/10/2026 72 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
fi
 label-out or measurement-out tasks, performance is better assessed against a reference standard with
conventional accuracy metrics (sensitivity, speci city, localisation, measurement error), and the
paper’s adjudication machinery is a poor t unless the output includes narrative text.

3.3 Conversational probes and multi-turn trajectories. S.1, S.2 and the trajectory work in
Question 5 assume dialogue. Many multimodal and world-model devices are single-shot or batch
(an image or a data stream in, an output out), so these tests may be inapplicable. Where a
multimodal device does converse (for example, a patient uploads a photo and chats about it), the
conversational and perceptual risks combine, and neither element set alone is enough.

3.4 Prompt-based adversarial testing. Prompt-injection and jailbreak-style tests (S.2, A.1) target
text channels. For vision models, the corresponding threats are adversarial perturbations, text
embedded in images, and manipulated metadata that can steer behaviour, which the current
elements do not describe. This is an area where I expect the threat landscape to change quickly.

3.5 Benchmark construction through synthetic and paraphrase variation. The paper’s reliance
on synthetic data and paraphrase testing (Questions 12 and 13) assumes inputs that can be varied in
language. For images and signals, the analogue is controlled variation in acquisition, but synthetic
medical images carry their own circularity and realism problems (generators may omit the artifacts
and anatomical variation where failures occur), so the Question 13 safeguards apply with additional
force.

3.6 Standardised patient interactions and shadow deployment. Standardised patients are poorly
suited to imaging or sensor devices. Shadow deployment remains useful but is run on the data
stream (scans, waveforms), and the measurement-and-signal-processing consideration in Section IV
(users cannot independently evaluate outputs) becomes the dominant risk, pushing devices toward
higher tiers via the detectability modi er.

3.7 “Reasonable clinician comparator” for open-ended outputs. For perception tasks,
comparators are typically readers with reference standards con rmed by pathology, follow-up or
consensus. For world models forecasting outcomes, the comparator may be observed outcomes,
and the clinician-panel standard (Question 14) may be irrelevant.

4. Distinct considerations for multimodal vision-language devices

Consideratio
Why it matters Possible approach
n
Perception A wrong conclusion can stem from Evaluate perception ( ndings,
versus misreading the image or from faulty localization) separately from
reasoning reasoning, which need different xes and interpretation, with intermediate outputs
errors different tests where available
Visual Counterfactual tests: remove or alter the
Models may describe ndings not
grounding image, mismatch image and history,
present, or ignore the image and rely on
and check whether the output changes
text cues or priors
hallucination appropriately
Shortcut Performance can depend on acquisition Site- and scanner-strati ed testing;
learning and site, markers, laterality tags or external validation; controlled removal
spurious cues demographics instead of pathology of non-pathological cues
Acquisition Device model, protocol, resolution,
Prespeci ed robustness testing across
and quality compression and patient positioning shift
acquisition conditions (R.1 extended)
variation inputs

Date 18/10/2026 73 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
fi
fi
 Test handling of contradictory or
Cross-modal Image and text may con ict (history says
missing modalities, including whether
inconsistency one thing, image another)
the device ags the con ict
Real-world data are incomplete, and a Prespeci ed testing with absent or
Modality
missing modality may change behavior degraded modalities and de ned fallback
dropout
silently behavior
Localization
and Free-text answers can be right while the Region-level and measurement-level
measurement localization is wrong metrics in addition to text rubrics
accuracy
Report
generation A uent report can hide missed ndings,
Check completeness and omission, not
versus and omission is hard to see (a
only correctness of stated ndings
nding detectability problem)
detection
Automation Reader studies measuring reliance and
Visual overlays and drafted reports can
bias in image miss rates when the device is wrong
anchor readers
reading (Question 14)
Images, faces and metadata can be Privacy testing extended to image
Privacy
identifying content and embedded data

5. Distinct considerations for generative or predictive world models

I use “world model” loosely to mean a system that learns a dynamic representation of a patient,
physiology or environment and simulates or predicts how states evolve, including under
hypothetical actions. The statements below are general and should be revisited as concrete devices
appear.

Consideratio Why it matters Possible approach
n
Predictive A forecast of what will happen differs from a Distinguish the claim in the intended
versus simulation of what would happen under an use, since each needs different
generative action
Simulating “what if we give drug X” is a evidence
Validation against randomized or
Counterfact
causal claim. Observational training does not quasi-experimental evidence where it
ual validity
guarantee it, and it cannot be checked exists; explicit statement of causal
against the same patient’s alternative
Calibration Users may act on risk estimates or assumptions;
Calibration andlimited claims
discrimination, with
of trajectories calibration across subgroups and over
probabilistic
Compoundin time
Performance reported as a function of
Multi-step rollouts can drift from reality as
g error over prediction horizon, with a de ned
errors accumulate
horizon horizon beyond which the device
Distribution World models can produce con dent but does not claim validity
Out-of-distribution detection,
shift and unreliable predictions outside their training
abstention, and prespeci ed shift tests
out-of- regime
distribution
Use in If a world model drives recommended Evaluate the decision outcome, and
planning or actions or an agent, errors propagate into the model as a component; link to
agentic loops Acting
decisions
on(Question
predictions26)
changes the system agentic elements
Evaluation designsA.1that account for
Feedback
being predicted (for example, predicted intervention-contaminated labels;
effects
deterioration leads to intervention, which care with outcome-based reference
prevents deterioration) standards

Date 18/10/2026 74 of 131 FDA-2026-N-7874

fi fl fi fl
fl fi fi fi fi fi fi
fl
 Validation Simulated scenarios may have no observable State what can and cannot be
without counterpart validated, and avoid claims that
ground truth Users may not be able to inspect why a
Interpretabil cannot in
Weigh bethe
tested
detectability modi er;
ity of the trajectory was predicted require sanity checks against known
simulation
Use for A world model used to generate evaluation physiology or clinical rules
training, data creates circularity with other devices Independence and real-data anchoring
testing or (Question 13)
synthetic
An important point: where a world model is used to supply the test environment for another
device (for example, simulated virtual patients for benchmarking, which the paper mentions), its
own validity becomes part of the evidence chain. The paper’s mention of virtual patient avatars
should be paired with a requirement to establish the delity and validity of the simulator, in the
way simulation credibility frameworks already require, whose current details I have not veri ed.

6. Cross-cutting issues for all architectures

• Element set is text-centric. E.4 (communication), parts of S.3, and the multi-turn tests
assume language. A modality-aware element set is needed, with perception, measurement
and prediction metrics added.
• Reference standards differ. Imaging and signal tasks usually have stronger, more objective
ground truth than open-ended conversation, so the comparator problem (Question 14) is
different. In its place, the challenge becomes reference standard bias (for example,
veri cation bias, reading by the same experts who trained the model) and spectrum bias in
case selection.
• Existing device evaluation practice already covers parts of this. Machine-learning
imaging devices have established evaluation approaches (standalone performance, reader
studies, external validation). The competency-based approach should build on and not
duplicate these, and CDRH should clarify where it applies in addition. I have not veri ed
the details of current FDA expectations for imaging AI.
• Mixed-architecture devices (a vision model feeding a language model feeding a
recommender) need evaluation at the system level and at interfaces, since errors cross
component boundaries. A good component score does not guarantee a good pipeline.
• Foundation model transparency (Question 25). Vision-language and world-model
backbones may be even less documented than text models, and model cards would need
modality-speci c content (training data modalities and sources, acquisition coverage, known
failure conditions).
• Change control. Updating an image encoder or retraining on new scanner data changes
behaviour in ways that re-benchmarking must capture, and the PCCP approach (Questions
22 to 24) should specify modality-relevant triggers.
• Tiering consistency. Measurement and signal-processing functions are already agged in
Section IV as potentially higher risk. For many multimodal and world-model devices the
detectability modi er will apply, which in our proposed scheme raises evidence
expectations.
• Equity. Imaging and sensor devices have known performance differences across skin tone,
body habitus, age and acquisition setting (a point I make from general understanding
without citing speci c studies). R.2 should explicitly cover physical and acquisition-related
subgroups and not only dialect and literacy.
7. Illustrative cases

Date 18/10/2026 75 of 131 FDA-2026-N-7874

fi
fi
fl
fi
fi
fi fi
fi
fi
 Elements Elements that
Device Additions needed
that carry do not
Vision-language model Tiering; overR.2; Conversational Perception versus reasoning separation;
drafting chest reader-based probes; omission testing; site and scanner shift;
radiograph reports for con rmation communication automation bias study
radiologists
Patient-facing photo- S.1, S.2, E.4, rubric (partly)
Radiologist-style Image-quality handling, skin-tone
based skin lesion trajectories reader design subgroup performance, visual
advisor with
World model chat Tiering; Rubric scoring, hallucination tests, escalation
Horizon-dependent calibration,after
forecasting calibration; clinician-panel feedback-contaminated labels, drift
deterioration in postmarket comparator
World model simulating Tiering; team Output-quality monitoring, alert-burden
Causal validation, expliciteffects
limits on
treatment options for a evaluation adjudication counterfactual claims, evidence from
clinicianpatient
Virtual Prespeci cati randomized data
Simulator delity validation and
N/A
simulator used to test on, circularity safeguards
other devices independence
These are illustrative only and not a proposed classi cation.

8. Cautions

• Do not force text-based elements onto non-text devices. Checklist compliance can create
the appearance of evaluation while missing the real failure modes.
• Do not assume stronger ground truth means easier evaluation. Imaging reference
standards are subject to veri cation and spectrum bias, and many world-model claims have
no ground truth at all.
• Avoid duplicating established imaging AI evaluation. Layering new requirements on
well-validated practice adds burden without added assurance, contrary to least burdensome
principles.
• Avoid overextending claims for world models. Predictive accuracy does not establish that
simulated interventions would work.
• Beware of fast-moving architectures. Elements tied to speci c techniques will date
quickly, so extensions should be stated in terms of failure modes and claims, not
implementation.
• Do not neglect interfaces. Multimodal pipelines can fail at the hand-offs between
components.
9. Limitations and open questions

• This area is changing quickly, and I do not claim to describe the current state of multimodal
or world-model devices in clinical use. Several considerations above are anticipatory.
• The extent to which current imaging AI practice already satis es the paper’s goals is
something I ag but do not assess.
• It is unclear how to validate counterfactual claims from world models premarket, and
whether any such claim could be supported at all without randomised evidence.
• Evidence on how well multimodal benchmarks predict real-world performance is limited, so
the Question 10 concerns apply.
• I have not worked out how to de ne intended use when a model accepts many modalities
and tasks (the behavioural-envelope problem in Question 5 extends to modality as well as
conversation).
• Whether modality-speci c extensions should live in one framework or in separate guidance
is a policy question I do not resolve.
10. Recommendations

Date 18/10/2026 76 of 131 FDA-2026-N-7874

fi fi
fi
fi
fi
fi
fl
fi
fi
fi
 1. Retain the risk tiering, two-stage structure, pre-speci cation and independence
principles as architecture-neutral, and publish modality- and architecture-speci c
extensions to the element set.
2. For vision-language devices, add elements for perception versus reasoning, visual
grounding, spurious-cue robustness, acquisition and site shift, cross-modal con ict, and
omission, and extend R.2 to acquisition and physical subgroups.
3. For image-, signal- and measurement-output devices, use conventional diagnosticaccuracy and reader-study methods with strong reference standards, and clarify how the
competency framework builds on existing imaging AI practice.
4. For world models, require the intended use to distinguish prediction from simulation of
interventions, report calibration and horizon-dependent performance, address feedback
effects and out-of-distribution behaviour, and limit counterfactual claims to what can be
validated.
5. Where a world model or simulator is used to generate test environments, require evidence
of its delity and apply circularity safeguards (Question 13).
6. Extend adversarial testing to non-text channels (embedded text, perturbations, metadata).
7. Evaluate mixed-architecture pipelines at component, interface and system level.
8. Require modality-speci c content in foundation model documentation, and modalityrelevant triggers in change control.
9. State extensions in terms of failure modes and claims, not speci c techniques, so they
remain valid as architectures change, and pilot them on real devices before formalising.

Question 18 - CDRH is considering whether it may be appropriate to accept greater
premarket uncertainty regarding a GenAI-enabled device’s benefit-risk profile through
greater reliance on post market monitoring. Under what conditions might such an approach
be appropriate, and what characteristics of a monitoring program would need to be in place
to justify reduced premarket evidence? Are there device types or risk profiles for which this
approach would not be appropriate?

1. Summary position

Greater reliance on post market monitoring can be appropriate, but only for a de ned class of
uncertainty and only when the monitoring program can detect the relevant harm quickly
enough, attribute it to the device, and trigger a response that actually limits exposure. Post
market evidence is good at estimating rates in the real population and detecting drift. It is poor at
establishing the safety of failures that are rare, silent, irreversible or time-critical, because by the
time they are observed the harm has already occurred and has been replicated across users. We
recommend that CDRH treat this as conditional, tiered and bounded: premarket evidence should
not be reduced on safety-critical elements at any tier, reductions should apply to speci c, named
uncertainties rather than to the evidence package generally, and every reduction should be paired
with a pre-speci ed, tested monitoring-and-response plan with exposure limits. This is a riskallocation decision, and the paper’s own framing (Question 18, Section VI) treats it as one.

2. What kind of uncertainty can post market evidence address?

Not all premarket uncertainty is equivalent. A useful division:

Can postmarket
Type of uncertainty monitoring Comment
resolve it?
Date 18/10/2026 77 of 131 FDA-2026-N-7874

fi
fi
fi
fl
fi
fi
fi
fi fi
 Rate of common, non-severe Large volumes give precise estimates;
Yes
errors in the real population errors are detectable and recoverable

Performance drift (input
Yes, and it is Premarket evidence cannot cover it by
population, data environment,
needed regardless de nition
model changes)
Depends on whether subgroup
Subgroup performance where
Partly membership and outcomes are captured
real premarket data were scarce
(Question 13)
Real user behavior (reliance, care- Observable only in use, though
Yes
seeking, override) confounded
Rare, severe or irreversible Few events, delayed detection, harm
Poorly
failures already incurred
Silent failures (wrong output not The detectability problem (Question 1)
Poorly
noticed by user or system) applies to monitoring too
Time-critical errors (missed Detection after the fact does not prevent
Poorly
emergencies) the harm
Harms that cannot be attributed Confounded by the underlying condition
Poorly
to the device and other care
Scope or boundary violations Observable in logs, but only if logging is
Partly
(S.2) adequate and reviewed

The practical rule: post-market evidence can substitute for premarket evidence where the
uncertainty is about rates, drift and real-world behaviour of recoverable errors, and cannot
substitute where the uncertainty is about whether a severe, irreversible failure can occur at all.

3. Conditions under which reduced premarket evidence may be appropriate

We suggest that all of the following should hold, each with evidence:

1. Bounded severity. Errors from the function are of limited or moderate consequence and are
largely reversible (the lower-left region of Figure 1, after modi ers).
2. A premarket oor is met. Safety-critical elements (S.1, S.2, safety-critical R.1) have been
demonstrated at pre-speci ed thresholds. Reductions apply to additional evidence (breadth,
precision, subgroup coverage, con rmation rigor), not to this oor (Questions 7 and 8).
3. Detectability exists. Errors are likely to be noticed, by users, clinicians or automated
checks, soon enough to act. Where detectability is low, monitoring depends on indirect
signals and is weaker.
4. Exposure can be limited. Deployment can be staged or capped (restricted population, site,
volume, or clinician-reviewed outputs) so that harm from an undiscovered failure is
bounded while evidence accrues.
5. Response is fast and credible. The sponsor can pause, roll back or restrict the device
quickly, and has shown it can (for example through a tested rollback or kill-switch for a
model or con guration).
6. Data capture is adequate. The sponsor can observe the inputs, outputs, user actions and,
where feasible, outcomes needed to estimate the performance measures that matter, within
privacy and legal limits.
7. Attribution is feasible. The program can distinguish device-caused harm from background
rates, which requires a baseline or comparator (Question 15).

Date 18/10/2026 78 of 131 FDA-2026-N-7874

fi fi fl fi fl
fi fi
 8.
The uncertainty is speci cally named. The sponsor identi es what remains unknown, why
it cannot be resolved premarket, and which monitoring analysis will resolve it, with a
decision rule.
9. Bene t justi es it. There is a credible, evidenced bene t from earlier access (for example, a
serious unmet need or an access gap), consistent with how FDA already considers
uncertainty in bene t-risk determinations, whose current details I have not veri ed.
If any of 1 to 3 fails, we would not support reducing premarket evidence.

4. Characteristics a monitoring program must have to justify reduced premarket
evidence

4.1 Pre-speci ed, not discretionary. The plan, including measures, data sources, analysis methods,
thresholds, review cadence and responsible parties, is xed before authorisation and is part of what
is authorised. Monitoring that the sponsor designs after seeing problems cannot justify reduced
premarket evidence.

4.2 De ned performance measures tied to the named uncertainty. For each uncertainty
accepted, specify the metric, the target, and the con dence bound that carries the decision (Question
12). Examples: upper bound on under-escalation in the deployed population; subgroup-speci c
override rates; rate of out-of-scope outputs.

4.3 Triggers and actions. A table of thresholds and consequences, for example:

Threshold (sponsorSignal Prespeci ed response
speci ed, reviewed)

Safety-critical failure rate Any con rmed event class, or Immediate restriction or pause;
exceeds bound bound breached noti cation; root-cause review

Input or performance shift Re-benchmarking; additional
Drift beyond tolerance
above threshold con rmation
Subgroup gap beyond Restrict claims for subgroup or collect
Gap or insuf cient data
margin targeted data
Any change noti ed or Re-benchmark before or promptly after
Foundation model update
detected rollout (Question 24)
Out-of-scope use above
Unexpected usage pattern Strengthen boundaries; review labeling
threshold

4.4 Statistical adequacy. The program must have enough volume and event rate to detect the harm
within a useful time. A rule-of-three style calculation (Question 12) shows how long it takes to
bound a rare event: if the device serves a modest number of users, a one-in-a-thousand failure may
never be bounded within the review period. Sponsors should state the time to detection for the key
harms at the expected deployment scale. Where this is too long to be protective, reduced premarket
evidence is not justi ed.

4.5 Independent review of samples. Periodic quali ed, independent clinician review of sampled
interactions (as the paper lists), sampled to re ect clinically relevant presentations and enriched for
high-risk cases, since random samples will rarely include rare severe events. Reviewer
independence and reliability apply as in Questions 10 and 14.

4.6 Outcome ascertainment. Where possible, link device output to what happened afterward
(follow-up, utilisation, adverse events). Without outcome data, monitoring sees only what the
Date 18/10/2026 79 of 131 FDA-2026-N-7874

fi
fi
fl
fi
fi
fi
fi
fi
fi
fi
fi fi
fi
fi
fi
fi fi fi fi fi fi
fi
 device said, not whether it was right. Where outcomes cannot be captured, the program is limited to
process measures, which weakens the case for reduction.

4.7 Multiple signal sources. Combine automated analytics, user and clinician reports, complaint
handling, sampled review, and external data (registries, institutional audits). No single channel
suf ces, particularly for silent failures.

4.8 Equity and subgroup coverage. Collect the data needed to see subgroup performance,
including language, age, literacy and acquisition-related groups, since reduced premarket subgroup
evidence is justi ed only if subgroups can be observed (R.2, Question 13).

4.9 Machine-based supervisory agents, if used. The paper asks about these. Where used, they
must be validated against clinician review, have known error rates, and not be the sole check on the
device. A supervisory model of the same class may share the device’s blind spots (the circularity
concern in Question 13). Treat them as a triage layer that prioritises human review, not as a
replacement.

4.10 Version control and linkage. All monitoring results are tied to the exact device version and
con guration, including foundation model version, so that changes can be attributed. This requires
that the sponsor knows when third-party model changes occur (Question 24).

4.11 Transparency to FDA. Regular reporting of results, including negative and ambiguous
ndings, with FDA access to underlying data on request. Aggregate summaries alone can hide
problems.

4.12 Resourcing and governance. Named accountable roles, adequate staf ng, and a qualitysystem home for the program. A monitoring plan on paper that is under-resourced offers little
protection.

4.13 Tested response capability. The sponsor demonstrates, premarket, that the pause or rollback
mechanism works and how quickly, and that users would be informed.

5. Staged and bounded deployment as the bridge

Reduced premarket evidence is more defensible when paired with graduated exposure:

1. Initial limited release: restricted setting or population, higher oversight (such as clinician
review of all or many outputs), intensive monitoring, pre-speci ed stopping rules.
2. Expansion on evidence: widen scope only when monitoring meets criteria (for example, a
bound on the key failure rate over a stated number of interactions).
3. Broad deployment with routine monitoring once performance is characterised.
This mirrors the graded independence in the paper’s clinician analogy, and our staged con rmation
pattern (Question 11). It also lets FDA tie each expansion to evidence, so that reduced premarket
evidence becomes evidence deferred and bounded, not evidence waived.

6. Device types and risk pro les for which the approach would not be
appropriate

Why postmarket reliance is
Pro le
inadequate

Date 18/10/2026 80 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
fi
fi
 Harm is direct, rapid and may be
Autonomous action-taking with severe consequences
irreversible; no human check before
(for example, initiating a time-critical order set)
action
Missed emergencies are not recoverable
Time-critical care escalation (stroke, MI, sepsis triage)
after detection (Question 6)
Patient-facing action-directing functions with low Users cannot spot errors, and silent
detectability failures may not be reported
Dosing and prescribing of high-risk drugs (insulin, Severe, irreversible harms from single
anticoagulants, chemotherapy) errors
Functions where harm is delayed or diffuse (for
Detection lag exceeds the useful
example, misdiagnosis whose effect appears months
response window
later)
Devices for vulnerable populations (children, Higher harm severity and less ability to
cognitively impaired, acute distress) report problems
Rare-condition devices where events are too Statistical adequacy cannot be achieved
infrequent to ever bound postmarket
Devices lacking outcome ascertainment or data access Monitoring cannot see the harm
Actions may be unrecoverable before
Agentic devices with irreversible tool actions
review (Question 26)
Devices built on third-party models with no change Sponsor cannot attribute or anticipate
noti cation behavior changes (Question 24)
Sponsors without demonstrated monitoring capability Plan is aspirational

For these, premarket evidence on the safety-critical behaviours should remain at the level the tier
would otherwise require, and post market monitoring should be additional, not substitutive.

7. Where the approach is likely most appropriate

Illustrative, not a classi cation:

Pro le Reasoning
Errors are recoverable and often caught;
Non-directive informational functions, limited
breadth and subgroup precision can accrue
consequence, HCP-facing
postmarket
Documentation and summarization tools with
Detectable errors, human check, reversible
clinician review (where they are devices)

Moderate-tier decision support with demonstrated Team performance can be monitored, with
effective oversight override and error-catch data

Functions with a strong premarket safety oor and
Matches what postmarket evidence does best
uncertainty mainly about drift or subgroup breadth

Access-extending devices addressing a real gap,
Bene t argument supports earlier access, with
deployed in staged fashion with enhanced
exposure limits
monitoring

Date 18/10/2026 81 of 131 FDA-2026-N-7874

fl
fi
fi
fi
fi
 8. Illustrative cases

Device Reduction considered Judgment
HCP-facing Smaller premarket subgroup and breadth Plausible, given recoverable errors and
guideline evidence, with postmarket sampled clinician review
summarizer
Patient-facing review
Reducedand drift
con monitoring
rmation, relying on Not appropriate; time-critical and low
chest-pain postmarket data for miss rate detectability
triage
Education tool Reduced con rmation, relying on user Plausible at lower tier, with scope and
for common feedback and sampled review calibration oors
conditions
Lab-result Postmarket monitoring in place of Partly: depends on whether outcome or
interpretation behavioral testing behavior data can be captured; keep
for patients
Autonomous accuracy oor premarket
Any reduction Not appropriate
order initiation

These are illustrative only and not a proposed classi cation.

9. Cautions

• Post market monitoring is not a safety net for what it cannot see. Silent, rare and
irreversible failures are the least observable.
• Exposure is the cost of deferral. Each patient exposed while evidence accrues bears risk,
so the ethical justi cation depends on bounded exposure and real bene t, and I do not
address regulatory requirements beyond what the paper places in scope.
• Do not let the option become a default. If sponsors expect reduced premarket evidence as
normal, the incentive is to launch with minimal evidence and defer problems.
• Beware of asymmetry. Sponsors bene t from earlier market access and bear limited cost
for slow detection, so incentives and enforcement need to align (accountability, Question
21).
• Monitoring effort can decline over time. Plans should persist and be audited, with
consequences for lapses.
• Real-world data are biased. Selection, missing outcomes and confounding can make a
failing device look ne, so analyses should address these.
• Do not double-count. A monitoring plan that also serves as a post market obligation
unrelated to premarket reduction should not be presented as compensating for missing
evidence.
• Avoid false reassurance from aggregates. Overall performance can hold while a subgroup
or scenario fails.
• Reduction should be reversible. If monitoring reveals problems, FDA should be able to
require additional evidence or restrict use.
10. Limitations and open questions

• I am not aware of evidence on how well post market monitoring has detected harms from
GenAI devices, since the experience is limited, and I describe monitoring capabilities from
general understanding.
• It is unclear how to quantify the “exchange rate” between premarket evidence and post
market monitoring, and I deliberately propose no formula.
• Time-to-detection thresholds that would be considered protective for each tier are unsettled.
• The feasibility of outcome linkage across health systems, and privacy limits on logging
conversations, vary widely and may restrict what is achievable.

Date 18/10/2026 82 of 131 FDA-2026-N-7874

fi
fi
fi fi
fi
fi
fl
fl fi
 • How regulators could enforce commitments, and what authorities exist for conditions of
authorisation or post-market requirements, is outside the paper’s stated scope and my own,
which I ag but do not resolve.
• Whether machine-based supervision can be made reliable enough to carry part of the
monitoring load is an open empirical question (Question 20).
• The interaction with PCCP approaches (Questions 22 and 23) needs development, since
monitoring triggers could de ne when modi cations are allowed.
11. Recommendations

1. Treat reliance on post-market monitoring as conditional and bounded: applicable to named
uncertainties about rates, drift, subgroup breadth and real-world behaviour of recoverable
errors, and not to safety-critical premarket oors.
2. Require that detectability, limited severity and reversibility be established before any
reduction is considered.
3. Require a pre-speci ed monitoring-and-response plan as part of the authorised package,
with measures, thresholds, actions, cadence, accountable roles and resourcing.
4. Require sponsors to state the time to detection for key harms at expected scale, and reject
reductions where it is too long to protect patients.
5. Pair reductions with staged or capped deployment and pre-speci ed expansion and
stopping criteria.
6. Require outcome ascertainment or an explicit justi cation for its absence, and enriched
sampling for high-risk cases.
7. Require demonstrated, tested rollback or restriction capability and noti cation
mechanisms, including for third-party model changes.
8. Treat machine-based supervisory agents as triage tools validated against clinicians, not
independent safeguards.
9. Treat the approach as not appropriate for autonomous severe-consequence actions, timecritical escalation, low-detectability patient-facing directive functions, high-risk dosing,
delayed-harm functions, vulnerable-population devices without strong safeguards, and
devices without data access or change noti cation.
10. Preserve FDA’s ability to require additional evidence or restrict use if monitoring reveals
problems, and require transparent reporting of negative ndings.
11. Pilot the approach with real devices before formalising it, and evaluate whether monitoring
programs actually detected what they were designed to detect.

Question 19 - Please comment on the potential approaches to post market performance
evaluation, including periodic re-benchmarking, sample-based clinician review, and
performance degradation monitoring. What additional approaches should CDRH consider,
and how should the cadence and triggering events for reassessment be determined?

1. Summary position

The three approaches the paper lists answer different questions and should be treated as
complementary layers, not alternatives. Periodic re-benchmarking asks whether the device still
meets its premarket standard on a xed instrument. Sample-based clinician review asks whether
real-world outputs are acceptable. Degradation monitoring asks whether the inputs or behaviour are
changing. None observes patient outcomes or user behaviour on its own, and none is reliable for
rare, silent failures (Question 18). We recommend a layered program in which the layers are
chosen by tier and by the uncertainties accepted at authorisation, with cadence set by exposure,

Date 18/10/2026 83 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fl
fi
fi
fi
fi
fl
 rate of change and time-to-detection, and with event-driven triggers taking precedence over
calendar schedules wherever a change to the device or its environment is known.

2. What each listed approach can and cannot do

Approach Can show Cannot show Main vulnerabilities

Whether behavior on
the validated Real-world
Saturation, leakage and
instrument has performance or user
Periodic re- optimization over repeated
changed; regression behavior; failures
benchmarking use (Question 10); benchmark
after changes; outside the
may stop re ecting real inputs
comparability over benchmark’s coverage
time

Appropriateness of
Rates for rare events Reviewer cost, variability and
real outputs in real
Sample-based (unless enriched); independence; sampling bias;
context, including
clinician review outcomes; silent privacy limits on accessing
failure modes the
failures conversations
benchmark missed

Shifts in input mix,
output distributions, Drift can be benign, and
Performance Whether a shift is
con dence, refusal or harmful change can occur
degradation harmful; correctness,
escalation rates, and without detectable drift;
(drift) monitoring without labels
proxy performance thresholds are hard to set
measures

The practical point is that each is a detector with blind spots. Benchmarking sees what it was built
to see, clinician review sees what it samples, and drift monitoring sees what changes in measurable
features.

3. Comments on each approach

3.1 Periodic re-benchmarking.

• Treat it as a regression test against the premarket baseline, not as proof of ongoing safety.
Its main value is detecting unintended change after a model, prompt or retrieval update
(Questions 22 to 24).
• Use versioned instruments and record the benchmark version, device version and
foundation model version with every run, so that a change in score can be attributed.
• Refresh and rotate items. A xed set run repeatedly invites optimisation and saturation.
Maintain a sequestered portion not used in development (Questions 10 and 16).
• Add items from observed real-world failures so the instrument tracks actual failure modes.
• Report the full results, including per-element and safety-critical slice results, with
con dence bounds. Gating elements should be re-tested at their original thresholds, not
averaged into a composite (Question 7).
• Check periodically that benchmark scores still agree with real-world measures
(concordance, Question 10). Divergence means the instrument has lost validity.

Date 18/10/2026 84 of 131 FDA-2026-N-7874

fi
fl
fi
fi
 • Note run-to-run variability (Question 12). A change in score is only informative relative to
the noise, so thresholds for “meaningful change” should be pre-speci ed using repeat-run
variance.
3.2 Sample-based clinician review.

• Enrich the sample for high-risk content (escalation decisions, dosing, low model
con dence, user distress, long conversations, user overrides) alongside a random
component. A purely random sample will rarely contain severe events.
• Sample across subgroups and interaction patterns so equity can be assessed (R.2), and
include full conversations, not only nal outputs (Question 5).
• Pre-specify review criteria, reviewer quali cations, blinding where feasible, independence
from the sponsor and foundation model developer, and inter-rater reliability reporting.
• Seed known-error cases (clinician-authored or past failures) into the review stream to
measure whether reviewers actually detect errors. Review fatigue and drift in reviewer
standards are real risks.
• Use review outcomes both to estimate rates and to feed new items into benchmarks.
• State the sample size rationale in terms of the bound needed on the relevant failure rate, not
a convention such as “a xed percentage” (Question 12).
• Address privacy and consent for accessing real conversations, which may constrain
sampling and which I do not resolve here.
3.3 Performance degradation monitoring.
The word “performance” is doing a lot of work here. Without labels, what can be monitored are
proxies. We suggest distinguishing:

Monitoring target Examples Limitation
Population mix, presenting complaints, Shows the world changed, not
Input drift
language, conversation length, input quality that the device got worse
Distribution of dispositions, escalation and
Shift may be appropriate or
Output drift refusal rates, directiveness levels (Question
inappropriate
2), con dence statements
Only covers what the probes
Behavioral stability Canary or sentinel prompts run continuously
cover, but catches silent
on xed probes through the deployed system
upstream changes
Safety-boundary Out-of-scope outputs, prohibited transitions, Depends on logging and
signals hard-limit triggers (Question 5) detection quality
User-behavior Override, edit and abandonment rates; Confounded, but one of the
signals complaint rates; repeat contact after advice few windows on real reliance
Delayed-label Agreement with later diagnoses, utilization Slow, incomplete, subject to
performance or outcomes confounding

Thresholds should be pre-speci ed and tied to clinical consequence (what shift would matter),
with statistical process control or equivalent methods used to separate signal from noise. A common
failure is alert thresholds that are either so sensitive that they are ignored or so loose that they never
re. The sponsor should show, ideally using historical or simulated shifts, that the monitor would
have detected the kinds of change it is meant to catch.

4. Additional approaches CDRH should consider

• Canary and sentinel probing of the deployed system. A small, continuously or frequently
run set of xed prompts, including safety-critical scenarios, executed against the live

Date 18/10/2026 85 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi fi
fi
fi
 con guration. This is cheap and detects silent upstream model or retrieval changes quickly,
which matters for devices built on third-party models (Question 24). It is a narrow
instrument and not a substitute for re-benchmarking.
• Shadow evaluation of candidate changes. Before a model or con guration update goes
live, run it in parallel on real traf c and compare with the current version, with clinician
review of disagreements.
• Enriched and adversarial post-deployment red teaming, periodic and independent,
aimed at new failure modes and newly discovered jailbreaks or misuse patterns.
• Incident and near-miss reporting channels for clinicians and patients, with structured
categories and feedback to developers. Complaint data are insuf cient but necessary,
particularly for failures users notice.
• Outcome-linked surveillance, using registries, institutional audits or linked health records
where permitted, to evaluate whether advice was followed and what happened (Question 18,
Section 4.6).
• Subgroup surveillance with pre-speci ed strati cation and a rule for what happens when a
subgroup has too little data to monitor, since “no signal” may mean “no visibility.”
• Comparative surveillance against the counterfactual. Monitor care-seeking, delay and
utilisation against baseline pathways (Question 15), to catch effects such as over-escalation
load or displaced referrals.
• Periodic re-con rmation studies for higher tiers, such as a repeated reader study or a
standardised-patient exercise, not only re-benchmarking, since benchmarks do not measure
user behaviour (Question 11).
• Monitoring of the knowledge base and retrieval layer, including guideline currency,
source quality and citation faithfulness, since many failures in deployed systems arise from
stale or corrupted content.
• Human-AI team monitoring where clinicians are in the loop: error-catch rates (using
seeded errors), automation bias indicators, and changes in clinician behaviour over time
(Question 14).
• Aggregated, cross-sponsor surveillance via independent or consortium bodies for shared
foundation models, so that a defect in one underlying model is detected across the devices
that use it. This links to the Foundation Model MAF idea (Question 25) and to the thirdparty roles in Question 16, and raises governance questions I do not resolve.
• Machine-based supervisory agents as a triage layer for prioritising human review
(Question 20), validated against clinicians and not used as the sole check.
• Audit of the monitoring program itself, including whether alerts were reviewed, how
quickly they were acted on, and whether past problems were detected by the program or by
outsiders.
5. Determining cadence

Calendar cadence should re ect how fast risk can accumulate. We suggest cadence be set from four
factors, justi ed in the sponsor’s monitoring plan.

Factor Higher frequency when... Lower frequency when...
Risk tier and reachable Non-directive, limitedmaximum (Questions 1, Directive, severe, low-detectability functions consequence, easily
5) detected errors
Many users per unit time; a defect would
Exposure volume Low volume
affect many quickly

Date 18/10/2026 86 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fl
fi
fi
fi
 Frequent model, prompt or content updates;
Frozen model and
Rate of change third-party model auto-updates; fast-changing
content, stable inputs
guidelines
Time to detection and Harms materialize quickly and need quick Harms are slow and
harm latency correction recoverable
Uncertainty accepted
More deferred evidence means more intensive Premarket evidence was
at authorization
early monitoring comprehensive
(Question 18)
Long record of stable,
Monitoring history New device, or recent problems
veri ed performance

A useful layering by frequency, as a design pattern and not a prescription:

• Continuous or near-continuous: automated safety-boundary signals, canary probes, input
and output drift dashboards.
• Frequent (for example weekly to monthly early in deployment): enriched clinician
review of high-risk strata, user-behaviour and complaint review.
• Periodic (for example quarterly to annually, by tier): full re-benchmarking, subgroup
performance review, concordance check between benchmark and real-world measures.
• Occasional or event-driven: re-con rmation studies, red teaming, comparative
surveillance.
The intervals above are illustrative and not proposed thresholds. A more intensive early period
that relaxes as evidence accumulates and the program demonstrates it can detect problems is a
natural default, and this matches staged exposure (Question 18). Relaxation should require
evidence, not simply the passage of time, and should be reversible.

6. Determining triggering events

Event-driven reassessment should override the calendar. We suggest pre-specifying triggers in
categories, with the depth of response scaled to the expected impact (Question 22).

Trigger category Examples Suggested response
Model update, retraining, prompt,
Re-benchmark affected elements;
retrieval or guardrail change, new
Device change con rmation if behavior or claims
feature, interface change, expanded
change; PCCP rules where applicable
intended use
Foundation model version change, Immediate canary check; reUpstream thirddeprecation, silent update, change in benchmark; contractual noti cation
party change
provider policy (Question 24)
Knowledge or New guideline, retrieval source Targeted re-testing of affected content
content change update, drug safety communication (E.1, E.3)
Drift beyond threshold, failure-rate
Investigation; targeted review; restrict
Monitoring signal bound breached, subgroup gap, rise
or pause if safety-critical
in overrides or complaints
Serious adverse event or con rmed Root-cause analysis; reassessment of
Safety event
near-miss attributable to the device affected elements; possible restriction
New site, population, language,
Con rm in the new context; adjust tier
Population or work ow, or use by a different user
if reachable maximum changed
setting change group (for example a generalist tool
(Question 5)
used by patients)
Date 18/10/2026 87 of 131 FDA-2026-N-7874

fi
fi fi
fi fi fl fi
 Published failure modes, newly
External evidence discovered attack, reports about a Targeted adversarial testing and review
shared model in other devices
Benchmark Saturation, evidence of leakage, Replace or refresh the instrument; revalidity concern divergence from real-world measures run with the new version
Regulatory or Updated recommended practices or
Gap assessment
standard change recognized standards

Two principles apply to triggers:

1. Depth should match the expected impact. A copy-text change does not need full rebenchmarking, while a foundation model swap does. This is the scaling question in Question
22, and the monitoring plan should de ne categories and the evidence each requires.
2. Unknown changes are the hardest case. Where a third party can change a model without
notice, the sponsor needs detection mechanisms (canaries, version checks, behaviour
ngerprinting) as well as contractual ones, since a trigger the sponsor cannot see will not
re.
7. Setting thresholds and avoiding monitoring failure modes

• Anchor thresholds to the premarket baseline and to clinical consequence, with
con dence bounds for rare events (Question 12). “Statistically signi cant change” is not the
same as “clinically important change.”
• Control false alarms and missed signals. State expected alert rates and the staf ng to
handle them. Alert fatigue defeats a monitoring program, as does excessive reliance on
automated alerts nobody reads.
• Pre-specify what a signal triggers, who reviews it, in what time, and who can restrict the
device, so that thresholds lead to action.
• Test the monitoring itself by replaying historical incidents or injecting synthetic faults, to
show it would have caught them.
• Avoid self-referential monitoring. If the same model that powers the device evaluates its
own outputs, errors may be correlated (Question 13).
• Watch for adaptation to the monitor. If developers tune the device toward the monitored
metrics, measures stop re ecting underlying performance (the Question 10 optimisation
problem, now in operation).
• Guard against shrinking effort. Sponsors have an incentive to relax monitoring over time,
so requirements should persist and be audited (Question 18).
8. Illustrative cases

Device Suggested layering Cadence and triggers
Continuous canaries and safetyIntensive early period; any model,
boundary monitoring; frequent
prompt or retrieval change triggers rePatient-facing chest- enriched clinician review of
benchmarking of S.1; any con rmed
pain triage (high tier) escalation decisions; outcomemissed emergency triggers restriction
linked surveillance; periodic reand root-cause review
benchmarking and re-con rmation
Sampled clinician review with
HCP-facing
seeded errors; drift monitoring on Quarterly review; guideline update
guideline summarizer
content currency; periodic re- triggers targeted re-testing
(moderate tier)
benchmarking of E.1

Date 18/10/2026 88 of 131 FDA-2026-N-7874

fi
fi
fi
fl
fi
fi
fi
fi fi
Education tool for Complaint and feedback channels;
Update-triggered re-testing; relaxed
common conditions annual re-benchmarking; light drift
cadence if stable
(lower tier) monitoring
Device on third-party Daily canaries; version monitoring; Upstream-change triggers dominate;
foundation model rapid re-benchmark on any contractual noti cation plus technical
with auto-updates detected behavior change detection
Lab-result Monitoring of implausible-value
Triggered by assay or unit-format
interpretation for handling; comprehension and
changes at connected laboratories
patients behavior signals; sampled review

These are illustrative only and not a proposed classi cation.

9. Cautions

• Do not equate monitoring with safety. A program can run on schedule and still miss rare,
silent or irreversible failures.
• Do not rely on re-benchmarking alone. It tracks the instrument, not users or outcomes.
• Do not let calendar cadence substitute for triggers. A device can change dramatically
between scheduled reviews.
• Do not credit monitoring that is not resourced or acted on. Evidence of past responses to
real signals is stronger than a plan.
• Avoid uniform requirements across tiers. Proportionality matters, and low-tier devices
should not carry the full program.
• Avoid over collecting conversation data. Monitoring needs must be balanced against
privacy, which I do not resolve here.
• Beware of manufacturer-only visibility. Failures may be seen rst by clinicians,
institutions or patients, and channels should let them report (Question 21).
10. Limitations and open questions

• I am not aware of validated, empirically tested monitoring programs for GenAI devices, so
the layering and cadence suggested here are design proposals, not established practice.
• There is no agreed method to set drift thresholds that correspond to clinical harm.
• The effectiveness of canary probes, supervisory agents and enriched sampling at detecting
real failures is unknown, and pilots comparing detection rates would be informative.
• How much real-conversation access is permissible and practical under privacy and consent
constraints varies, and I have not assessed it.
• Cross-sponsor surveillance of shared foundation models raises competition, con dentiality
and governance questions I ag but do not resolve.
• Whether cadences should be prescribed by CDRH, set by consensus standards, or proposed
by sponsors and reviewed is a policy question I do not resolve.
11. Recommendations

1. Treat re-benchmarking, sample-based clinician review and degradation monitoring as
complementary layers with distinct blind spots, and require sponsors to state what each
layer is meant to detect.
2. Add canary or sentinel probing, shadow evaluation of changes, outcome-linked
surveillance, subgroup surveillance, re-con rmation for higher tiers, retrieval and
content monitoring, human-AI team monitoring and incident reporting channels to the
approaches considered.

Date 18/10/2026 89 of 131 FDA-2026-N-7874

fi
fl
fi fi
fi
fi
 3. Specify that re-benchmarking use versioned, refreshed and partly sequestered
instruments, report gating elements individually, and check concordance with real-world
measures.
4. Specify that clinician review be enriched for high-risk cases, include full conversations,
use independent reviewers with reliability reporting, and include seeded errors.
5. De ne degradation monitoring in terms of speci c input, output, behavioural and userbehaviour measures, with thresholds tied to clinical consequence, and require
demonstration that the monitor would detect relevant changes.
6. Set cadence from tier, exposure, rate of change, time to detection and accepted
premarket uncertainty, with an intensive early period that relaxes only on evidence and is
reversible.
7. Make event-driven triggers (device, upstream model, content, population, signal, safety
event, external evidence, benchmark validity) take precedence over calendar schedules, with
response depth scaled to expected impact.
8. Require detection mechanisms for unnoti ed third-party changes, in addition to
contractual noti cation.
9. Require pre-speci ed actions, owners and response times for each signal, and audit
whether alerts are reviewed and acted on.
10. Pilot the monitoring layers and cadences on real devices, and evaluate whether they detect
the failures they target, before formalising them.

Question 20 - Please comment on whether the proposed approaches to post market
monitoring can be facilitated by machine-based supervisory agents. What considerations,
including the evaluation and reliability of the supervisory agent itself, should CDRH take into
account for such an approach?

1. Summary position

Machine-based supervisory agents can facilitate post-market monitoring, mainly by extending
coverage and speed (screening every interaction, prioritising human review, running probes
continuously). They should not be treated as a substitute for independent human judgment on
safety-critical questions. The central issue is that the supervisor is itself a GenAI system that can
fail, and may fail in the same ways, on the same cases, as the device it supervises. We recommend
that CDRH (a) permit supervisory agents as a triage and detection layer, (b) require them to be
evaluated as measurement instruments with known sensitivity and speci city against
independent clinicians, (c) require independence from the device’s model class where feasible, (d)
never allow a supervisor to be the sole safeguard or the sole basis for credit toward reduced
premarket evidence (Question 18), and (e) require the supervisor to be monitored and changecontrolled like any other component whose performance matters.

2. Where supervisory agents could help

Monitoring task Contribution Comment
Flag out-of-scope outputs,
Screening all Coverage of 100% of traf c, which human
prohibited transitions, unsafe
interactions review cannot match
advice, missed red ags
Route high-risk or uncertain
Prioritizing
conversations to humans Likely the best-supported use
clinician review
(enrichment, Question 19)

Date 18/10/2026 90 of 131 FDA-2026-N-7874

fi
fi
fl
fi
fi
fi fi
fi
 Summarize shifts in topics,
Drift detection directiveness levels, refusal and Useful for input and output drift
escalation patterns
Canary and Generate and score probes against
Cheap and frequent
sentinel probing the live system
Re-benchmarking Run and score large test sets after Depends on validated scoring (Question
at scale changes 10)
This is a device component, not
Real-time Block or revise outputs before
monitoring, and should be evaluated as
guardrail checks delivery
part of the device
Complaint and Classify and cluster incident
Modest risk, high ef ciency gain
report triage reports
Retrieval and Verify that cited sources exist and
Partly checkable by non-LLM methods
citation checking support claims
Subgroup Strati ed analysis of outputs by
Depends on data availability
surveillance user characteristics
Draft review summaries and audit
Documentation Low risk, needs human sign-off
trails

The paper itself raises the idea for post monitoring in general. The most defensible value is
detecting and prioritising, with humans deciding.

3. Why the supervisor’s reliability is the central problem

3.1 Correlated errors. A supervisor built on the same model family as the device shares training
data, blind spots and biases. It may nd the device’s uent, con dent, wrong answers plausible.
This is the circularity problem from Question 13, applied to monitoring. Silent failures are exactly
where a correlated supervisor is weakest.

3.2 Detectability applies to the supervisor too. If an error is hard for users to detect (Question 1),
it may also be hard for a model to detect, particularly omissions, subtle dosing errors and contextdependent misjudgments.

3.3 Known weaknesses of model-based judges. Without citing speci c studies, I note general
concerns that LLM judges can favour uent or lengthy outputs, favour outputs from their own
family, be sensitive to prompt wording and ordering, and be inconsistent across runs. These are
properties to test, not to assume.

3.4 Rare events. Supervisors are typically calibrated on common cases. Their sensitivity on rare,
severe events is the quantity that matters most and the hardest to estimate (Question 12).

3.5 Adversarial exposure. If users or inputs can in uence the supervisor (prompt injection through
conversation content), the monitor can be manipulated or blinded. The device and the supervisor
read the same untrusted text.

3.6 Automation complacency. Reviewers who see only what the supervisor ags may stop looking
at the rest, and a quiet supervisor can create false reassurance.

3.7 Optimisation pressure. If device developers tune against the supervisor’s outputs, the device
may learn to avoid being agged rather than to be safe (Question 10, optimisation to the test).

Date 18/10/2026 91 of 131 FDA-2026-N-7874

fl
fi
fi
fl
fl
fl
fi
fl
fi
fi
 4. Evaluating the supervisory agent

Treat it as a diagnostic instrument with its own validation, mirroring Question 10.

Evaluation What to establish
Detection of each safety-relevant failure type against an
Sensitivity and speci city by
independent clinician reference, reported separately for safetyfailure class
critical classes with upper con dence bounds on misses
Performance on hard and Enriched, clinician-authored, and real past-failure cases, not only
rare cases typical ones
Inter-rater reliability between supervisor and expert panel,
Agreement with clinicians
compared with clinician-clinician agreement
Run-to-run and prompt-variation stability (Question 12, nonReproducibility
determinism)
Whether detection differs by dialect, literacy, demographic or
Bias and subgroup behavior
language group (R.2)
Robustness to adversarial
Resistance to injection and manipulation via conversation text
content
Whether its ags and scores mean what they claim, since
Calibration of its con dence
thresholds depend on it
Independence from the device Model family, training lineage, and any shared prompts or tools
Latency, throughput, failure handling and behavior when it is
Operational performance
unavailable
Ability to catch historical incidents and injected faults the device
Detection in replay
is known to produce

Evidence should be tied to the device’s actual deployment context, since a supervisor validated on
generic medical text may perform poorly on a particular function or population.

Two metrics deserve emphasis. Miss rate on safety-critical failures is the gure that determines
whether the supervisor can carry any safety load. Flag precision determines whether human
reviewers will be overwhelmed. The tradeoff between them should be explicit and justi ed, and
pre-speci ed like the operating points in Question 6.

5. Design considerations

• Independence. Prefer a supervisor from a different developer or model family, with
different prompts and, where possible, non-LLM components (rule-based checks, classi ers
trained on labeled failures, deterministic validators for dosing, units and citations). Hybrid
systems reduce shared failure modes. Independence is partial, since many models share
web-scale data.
• Separation of duties. The supervisor should not share a process, credentials or context with
the device it monitors, and should not be able to alter it without a de ned approval path.
• Defense in depth. Combine supervisor ags with random and enriched human sampling,
user reports and outcome data. Random human sampling is the check on the supervisor’s
own blind spots: without it, nothing measures what the supervisor misses.

Date 18/10/2026 92 of 131 FDA-2026-N-7874

fi fi
fi fl fi fi fi fl fi fi
 • Human sampling of the un agged. Pre-specify review of a sample of non- agged
interactions, with seeded known errors, to estimate the supervisor’s real miss rate in
operation (Question 19).
• Clear authority. Specify what the supervisor can do automatically ( ag, log, route) versus
what needs human decision (restrict, pause, report). Automatic remediation actions on a live
medical device bring their own risks and should be evaluated.
• Explainable ags. Flags should cite the conversation segment and the criterion, so
reviewers can verify quickly rather than defer.
• Security. Protect the supervisor’s prompts, thresholds and logs, and treat conversation
content as untrusted input.
• Data minimisation. Supervisory access to full conversations raises privacy considerations,
and any third-party supervisor service multiplies them. I do not resolve these here.
6. Ongoing reliability of the supervisor

• Version control and change control. Supervisor model, prompts, thresholds and tools
should be versioned and linked to monitoring results. A supervisor update can change
measured device performance without any device change, so monitoring series need
continuity checks, such as running old and new supervisors in parallel.
• Re-validation triggers. Re-validate after supervisor or underlying model updates, after
device changes that alter the failure pro le, and on drift in the supervisor’s own ag rates.
• Monitoring the monitor. Track ag rates, agreement with human reviewers on a continuing
basis, and error patterns found in human review of its output.
• Third-party supervisor dependence. If the supervisor relies on an external model provider,
silent changes there affect monitoring, as for the device (Question 24).
• Fallback behaviour. De ne what happens if the supervisor fails or is unavailable: reduced
deployment, increased human sampling, or pause for higher tiers.
• Auditability. Retain agged and un agged samples and decisions so FDA or independent
assessors can reexamine performance.
7. How this should interact with the risk framework

Tier or pro le Appropriate role for a supervisor
Lower tier Primary screening is acceptable, with periodic human sampling

Triage and coverage layer, with enriched human review and validated miss
Middle tier
rates

Higher tier, time- Supplementary only. Human review and independent measures remain
critical or primary, and a supervisor cannot be the basis for reducing premarket
autonomous evidence
Real-time
Treat as part of the device and evaluate it premarket, not as monitoring
intervention
Low-detectability
Be cautious, since the supervisor may share the detection weakness
functions

A supervisor should earn credit in the monitoring plan in proportion to demonstrated performance,
and a reduction in premarket evidence (Question 18) should not rest on a supervisor’s coverage
unless its miss rate on the relevant failures has been shown to be low and independently veri ed.

8. Illustrative cases

Date 18/10/2026 93 of 131 FDA-2026-N-7874

fi
fl
fl
fl
fi
fl
fl
fl
fi
fl
fl
fi
 Supervisor ags chest-pain triage Appropriate as triage, with human review of ags and a
conversations that may have under- sampled check of un agged conversations; miss rate on
escalated, routing
Supervisor is the to clinicians
only check on a missed
Not emergencies
appropriate; highvalidated
consequence, low detectability,
Supervisor veridosing
patient-facing assistant correlated-error risk
es citations in an HCPAppropriate, partly with deterministic checks
summarizer
Supervisor of same model family scores Weak evidence unless validated against independent
its own device’s escalation quality clinicians, with disclosed relationship
Supervisor drafts monthly drift reports Low risk, with human sign-off

These are illustrative only and not a proposed classi cation.

9. Cautions

• A supervising model is not an independent check merely because it is a separate system.
• No ags is not evidence of no failures. Silence from a supervisor needs to be tested.
• Do not let supervisors reduce human expertise in the loop, since reviewers need to keep
detecting errors.
• Avoid circular validation: validating the supervisor against labels produced by the same
model family.
• Avoid feedback loops in which supervisor output trains or tunes the device without
separation.
• Do not overstate coverage. Reviewing 100% of traf c with a weak detector is not 100%
oversight.
• Beware of added complexity. A monitoring stack with several models can become hard to
audit, and can fail silently.
• Avoid disproportionate burden. Requirements should scale by tier, and a simple rulebased monitor may be adequate for lower-tier devices.
10. Limitations and open questions

• I am not aware of empirical evidence on how well supervisory agents detect real failures in
deployed clinical GenAI systems, and the performance claims above are concerns to test,
not ndings. Pilot comparisons of supervisor ags against independent clinician review
would be informative.
• How much independence from the device’s model class is achievable in practice, given
shared training data, is unclear.
• There is no agreed standard for acceptable miss rates for safety-critical failure classes, and
this likely varies by tier.
• How to estimate a supervisor’s performance on rare events premarket is unresolved
(Question 12).
• Whether supervisory agents can legitimately be credited as safeguards in risk tiering
(Question 1) is a policy question I answer cautiously, with no credit for high-tier functions,
but do not resolve.
• Governance of shared or third-party supervisory services, including con dentiality and
concentration, parallels Question 16.
11. Recommendations

1. Accept machine-based supervisory agents as a detection and triage layer that extends
coverage, with humans making safety-critical determinations.

Date 18/10/2026 94 of 131 FDA-2026-N-7874

fi
fi
fl
fl
fl
fi
fl
fi
fl fi
 2. Require the supervisor to be validated as a measurement instrument, with sensitivity,
speci city, upper-bounded miss rates for safety-critical classes, reproducibility, subgroup
behaviour and robustness, against independent clinician references.
3. Require independence from the device’s model family and developer where feasible,
disclosure of any relationship, and use of hybrid designs with non-LLM checks.
4. Require ongoing human sampling of un agged interactions, including seeded errors, to
measure the supervisor’s operational miss rate.
5. Do not allow a supervisor to be the sole safeguard, and do not credit it toward reduced
premarket evidence or lower tiering for high-consequence functions.
6. Treat supervisors as change-controlled components with versioning, re-validation triggers,
drift monitoring of their own behaviour, parallel-run continuity checks and de ned fallback.
7. De ne separation of duties and authority limits, with automatic actions restricted to
agging and routing unless separately evaluated.
8. Protect the supervisor against adversarial content, and address privacy and data-access
implications.
9. Scale requirements by tier, and pilot supervisory approaches with real devices, evaluating
detection against independent clinician review before formalising expectations.

Question 21 - What roles might clinicians, healthcare institutions, professional societies,
standards-setting bodies, and other stakeholders appropriately play in post market
monitoring, and how can these roles be structured without diffusing manufacturer
accountability?

1. Summary position

Stakeholders other than the manufacturer can contribute things the manufacturer cannot see or
cannot credibly supply: observation of real use, independent judgment, local context, and
aggregate visibility across devices. But their roles should be contributory and informationgenerating, while duties to act (investigate, correct, restrict, report, maintain evidence) stay with
the manufacturer. We recommend a structure built on three principles: (a) accountability follows
control, so whoever can change the device owns its safety and effectiveness; (b) others are
accountable for the quality of what they contribute and for their own local use decisions, not
for the device; (c) every external role needs a de ned handoff back to the manufacturer with a
response clock, so that information never terminates in a place with no authority to act. The paper
already states that manufacturers are responsible for monitoring their devices (Section VI.B), and
the comment below is about how to build on that without eroding it.

2. Why other stakeholders matter

• Visibility. Many failures appear rst at the point of use, to clinicians or patients, not in
sponsor logs (Question 19).
• Outcome data. Institutions hold the records needed to link outputs to outcomes (Question
18, Section 4.6).
• Independence. Some checks are credible only if done by parties without a stake in the
device (Question 16).
• Local context. Work ow, population and local practice determine how a device behaves in
a given site, which the manufacturer cannot fully anticipate.
• Aggregation. No single manufacturer sees patterns across devices, shared foundation
models, or sites.
3. Roles by stakeholder
Date 18/10/2026 95 of 131 FDA-2026-N-7874

fi
fi
fl
fi
fl
fi
fi
fl
 What they should not
Stakeholder Appropriate contributions
be asked to own
Detecting all device
Reporting errors, near-misses and unexpected
errors; being the safety
Clinicians behavior; exercising judgment and override;
mechanism by default
(users) participating in sampled review; feedback on
(automation bias,
usability and reliance
Question 14)
Local governance and validation before deployment; Re-validating the
site-level performance audits; outcome linkage; device’s general safety;
Healthcare
incident reporting; controlled con guration and maintaining the model;
institutions
access; training and credentialing of users; decisions owning design-level
about where and how to deploy defects
Reporting problems through accessible channels;
Patients and participation in comprehension and experience Judging output
caregivers evaluation; advocacy input on harms the correctness
manufacturer may not track
Clinical content standards and guidelines; de ning Certifying or approving
Professional expected competence and use criteria; endorsing speci c devices in place
societies reporting taxonomies; convening expert panels; of FDA, or setting
education manufacturer obligations
Consensus test methods, reporting formats, Deciding acceptance
Standardsinteroperability of logs and incident data, criteria for individual
setting bodies
terminology for failure modes (Questions 9, 16) devices
Independent Accountability for the
Sequestered re-benchmarking, red teaming, crossevaluators and manufacturer’s quality
device surveillance (Questions 16, 19)
consortia system
Foundation Noti cation of changes, model documentation, Device-level safety,
model incident disclosure, cooperation with downstream unless they are also the
developers investigations (Questions 24, 25) manufacturer
Payers and
Requiring monitoring evidence in procurement; Substituting commercial
health systems
supporting data access for outcome studies criteria for safety criteria
purchasers
Researchers and Independent post-deployment studies, failure-mode Obligations of
academic groups analyses, replication continuous monitoring
Other federal
Complementary oversight within their remit (privacy, Replacing FDA
and state
professional practice, consumer protection) postmarket obligations
authorities
EHR and
Logging, telemetry and interface behavior; Device performance
platform
deployment con guration; data access claims
vendors

4. Structuring roles without diffusing accountability

4.1 Keep a single accountable party for the device. The manufacturer remains answerable for the
device’s safety and effectiveness across its life cycle, including performance on third-party
components (Question 24). Contractual allocation of tasks to others should not shift this. The same
logic applies to a manufacturer who outsources monitoring to an independent evaluator or
supervisory agent (Question 20): the task can be delegated, the accountability cannot.

Date 18/10/2026 96 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
 4.2 De ne duties by function, and make the interfaces explicit. A simple allocation:

Function Primary owner Contributors
Monitoring plan design and execution Manufacturer Evaluators, institutions
Institution and Manufacturer provides channels
Detecting and reporting local events
clinician and training
Investigating and root-cause analysis Manufacturer Institution supplies case data
Corrective action ( x, restrict, recall) Manufacturer FDA oversight
Local deployment decisions, con guration, Manufacturer provides labeling
Institution
user training and support
Independent veri cation of claims Third parties Manufacturer provides access
Consortium or
Aggregate surveillance across devices Manufacturers contribute data
authority

4.3 Create duties to receive and respond. Information ows only protect patients if someone is
obliged to act on them. We suggest:

• Manufacturers must accept, log and triage external reports, acknowledge them, and
respond within de ned times scaled to severity.
• Institutions and clinicians must have clear pathways to the manufacturer and, where
applicable, to FDA, with no requirement to prove causation before reporting.
• Reports of safety-relevant events should feed into the manufacturer’s complaint and quality
system, so they cannot be set aside.
4.4 Use agreements that allocate tasks and preserve accountability. Deployment contracts
between manufacturers and institutions should specify data sharing, logging and access, reporting
obligations, change noti cation, local con guration limits, and support commitments, while stating
that the manufacturer retains responsibility for the device as authorised. I do not address liability
law, which is outside the paper’s scope and my own.

4.5 Make local modi cation a boundary. If an institution changes prompts, knowledge sources,
work ow integration or intended population, it may alter the device’s behaviour. The framework
should state when a local change makes the institution responsible for assessing its effects, and
when it triggers manufacturer review (Questions 22 to 24). Without this, accountability for a failure
becomes disputed.

4.6 Distinguish accountability for contribution quality. Each external party is accountable for the
integrity of its own contribution: evaluators for the independence and reliability of their work,
institutions for accurate local reporting, societies for the basis of their standards. This is different
from device accountability, and should be stated.

4.7 Prevent responsibility displacement. Several patterns would erode accountability:

Pattern Risk Mitigation

Manufacturer relies on user Credit human oversight only where its
“The clinician is
vigilance as the safeguard despite effectiveness is demonstrated
responsible” labeling
automation bias (Questions 1, 14)

Date 18/10/2026 97 of 131 FDA-2026-N-7874

fl
fi
fi
fi
fi
fi
fi
fi
fi
fl
 “Institutional
Manufacturer under-invests in own Manufacturer monitoring plan is
governance will
monitoring required irrespective of local programs
catch it”
“The foundation
Manufacturer attributes failures Manufacturer must detect and respond
model developer
upstream to upstream changes (Question 24)
changed it”
“A third party Certi cates are evidence, not
Certi cates replace judgment
certi ed it” determinations (Question 16)
Consortium-level De ne routing of consortium ndings
surveillance with no Signals identi ed, nobody acts to manufacturers and FDA with
authority response duties
Standards
Meeting a standard treated as Standards inform, and do not de ne,
compliance as a safe
suf cient adequate safety
harbor

4.8 Align incentives. Accountability is weakened when manufacturers bene t from deployment
while costs of detection fall on others. Features that help: manufacturer-funded provision of logging
and reporting infrastructure for institutions, clear consequences for failing to act on reports, and
protection for clinicians and institutions who report (no penalty for good-faith reporting).

5. Considerations for speci c roles

Clinicians.

•Treat reporting as easy and low-friction, built into the work ow, or reports will be rare.
•Do not rely on override rates as the main safeguard, and measure whether clinicians catch
errors (Question 14).
• Training should address the device’s limits and failure patterns, and reliance risks.
Institutions.

•Local governance bodies (for example, committees reviewing AI deployments) can validate
locally, monitor local performance, and decide on use. The paper does not specify these, and
their capacity varies enormously. Large academic centres may have such capability, while
small or rural sites may not, and requirements should not assume it. This is an equity
concern: devices deployed where monitoring capacity is weakest may be least well
monitored.
• Institutions can provide outcome ascertainment, which manufacturers usually cannot. Datasharing terms and privacy limits then become central.
Patients.

•Direct reporting channels (not only through clinicians) matter for patient-facing devices,
since patients may be the only party who sees a failure. Reporting needs to be accessible
across language and literacy levels.
Professional societies.

•
They are well placed to de ne clinically meaningful failure categories, expected standards
of care for reference sets (Question 14), and guidance for appropriate use. They are less
suited to enforcement, and have their own interests (membership, industry funding), so
disclosure of con icts matters.
Standards bodies.

Date 18/10/2026 98 of 131 FDA-2026-N-7874

fi
fl
fi
fi
fi
fi
fl
fi
fi
fi
fi
fi
fi
 •
Most useful for common formats: incident taxonomies, log schemas, version identi cation,
test reporting. These reduce the cost of monitoring and enable aggregation. Consensus
processes are slow relative to the rate of change, so standards should address stable
properties (formats, failure categories) over speci c techniques (Question 17).
Aggregated or consortium surveillance.

• Cross-device and cross-site analysis could reveal patterns that single manufacturers miss,
especially for shared foundation models. It raises questions of con dentiality, antitrust, data
governance and funding, which I ag and do not resolve. It should have a de ned route to
manufacturers and FDA.
6. Illustrative cases

Scenario Role allocation
Clinician notices a triage Clinician reports through a simple channel; manufacturer must
device repeatedly under- acknowledge, investigate within a de ned time, and decide on
escalates a
Hospital symptom
measures pattern restriction
higher Institution or x; site
shares institution may pause
data under local use
agreement; meanwhilecompares
manufacturer
override rates after a model across sites, investigates the update, and communicates ndings
update
Foundation model provider Manufacturer’s canaries detect change; provider’s noti cation
silently updates its model obligations apply; manufacturer re-benchmarks and acts. Failure to
Professional society Societydoes
notify not shiftmanufacturer
publishes; responsibility
assesses content currency and republishes a revised tests affected elements (Question 19)
guideline
Institution customizes the Institution assesses local changes; manufacturer’s labeling de nes
device with its own permitted customization; changes beyond it return responsibility to
Consortiumbase
knowledge nds a pattern the institutionoti
Consortium or es
trigger manufacturer
affected reviewand FDA; each
manufacturers
across several devices on manufacturer responds for its own device
one model
These are illustrative only and not a proposed allocation.

7. Cautions

• Do not treat the ecosystem as a substitute for manufacturer monitoring. Shared
responsibility should add layers and not replace the primary one.
• Do not assume capacity. Smaller institutions and under-resourced settings may be unable to
perform local monitoring, so expectations should be proportionate and manufacturers should
support them.
• Avoid unfunded mandates. Placing reporting and audit burdens on clinicians without
resourcing reduces compliance and worsens burnout.
• Beware of underreporting. Voluntary reporting systems in medicine are known to capture
a fraction of events. Passive reliance on clinician reports will miss silent failures.
• Guard against con icts of interest among societies, evaluators and institutions with
industry ties.
• Protect reporters. Fear of blame or liability can suppress reporting, and the framework
should include protections consistent with existing safety-reporting norms, whose speci cs I
have not veri ed.
• Avoid fragmentation. Multiple overlapping reporting channels can leave events
unreconciled, so a common intake and routing standard helps.
• Do not reduce patients to data sources. Their role should include accessible channels and
feedback on what was done with reports.
8. Limitations and open questions

Date 18/10/2026 99 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
fi
fi
fl
fl
fi
fi
fi
fi
 • I am not aware of evidence on how shared monitoring responsibilities have worked for
GenAI devices, and the allocations above are design proposals.
• Legal allocation of responsibility among manufacturers, institutions and clinicians is outside
the paper’s scope and my own, and the practical effect of the structure above will depend on
it.
• It is unclear who funds shared infrastructure (consortia, standards, aggregate surveillance)
and how costs are distributed.
• The capacity of institutions to carry local governance functions is uneven, and the evidence
on what works is limited.
• How to make reporting systems reach patients with limited literacy or access is a design
question I do not resolve.
• Data-sharing arrangements for outcome linkage face privacy, security and competitive
barriers.
• How these roles interact with existing adverse-event and complaint-handling requirements
for devices is not addressed in the paper, and I have not assessed it.
9. Recommendations

1. State explicitly that the manufacturer remains accountable for monitoring, investigation
and correction of the authorised device, and that delegation of tasks does not transfer
accountability.
2. De ne stakeholder roles as contributory and information-generating, with a function-byfunction allocation of who detects, reports, investigates and corrects.
3. Require manufacturers to provide accessible reporting channels for clinicians, institutions
and patients, and to acknowledge, triage and respond within severity-based timeframes.
4. Require deployment agreements that cover data access and logging, reporting duties,
change noti cation, permitted local con guration and support, while preserving
manufacturer accountability.
5. De ne when local modi cation shifts responsibility to the institution and when it triggers
manufacturer review.
6. Encourage institutional governance and local performance audit where capacity exists,
and require manufacturer support where it does not, to avoid inequity in monitoring.
7. Use societies and standards bodies for clinical content, taxonomies, log and incident
formats and test-reporting conventions, and not for device-level determinations or
enforcement.
8. Establish routing and response duties for ndings from consortia and independent
evaluators, so signals reach a party with authority to act.
9. Address responsibility-displacement patterns explicitly: user-vigilance labelling,
upstream-model attribution, certi cate reliance, and standards as safe harbour.
10. Protect good-faith reporters, fund shared infrastructure sustainably, and pilot the structure
with real devices before formalising it.

Question 22 - CDRH envisions that a manufacturer’s premarket competency-based
assessment might serve as a baseline against which post-deployment modifications could be
re-evaluated. How might the extent of re-benchmarking or other evidence be scaled to the
nature and expected impact of a given modification? For example, are there categories of
change that might not significantly affect safety or effectiveness of a GenAI-enabled device, or
might be appropriately managed within a sponsor’s quality management system versus
requiring FDA premarket review and authorisation before implementation? Are there
categories of changes that might be appropriate for inclusion in a PCCP?

Date 18/10/2026 100 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
 1. Summary position

The premarket competency-based assessment is a good baseline for change evaluation, provided it
is designed from the start to be re-runnable: versioned instruments, pre-speci ed thresholds,
recorded device and model versions, and a sequestered portion that is not used in development
(Questions 10 and 16). We recommend that the evidence required for a change be scaled by
expected impact on the device’s behaviour envelope and risk tier, not by the technical size of
the change. A one-line prompt edit can matter more than a large retraining. We propose three
pathways: changes managed within the quality management system (QMS) with targeted regression
testing, changes within a pre-speci ed PCCP with de ned evidence, and changes needing FDA
review before implementation. The sorting should rest on a published, impact-based classi cation
with a documented route for sponsors to justify placement, and an ambiguity rule that places
uncertain changes in the more rigorous pathway. I describe the PCCP and QMS mechanisms only as
the paper does, and I have not veri ed their current requirements.

2. Why technical size is a poor guide for GenAI devices

In conventional software, the size of a code change roughly tracks the risk. For GenAI devices,
behaviour depends on the interaction of model, prompts, retrieval content, guardrails, orchestration
and interface (Section II of the paper). Consequences:

• Small changes can have large, non-local effects. A prompt wording change can shift
directiveness, refusal or escalation behaviour across many scenarios.
• Large changes can be benign. Infrastructure migration with no change to model or
prompts may leave behaviour unchanged, though this should be veri ed, not assumed.
• Effects are hard to predict from the change description. Hence the need for empirical
regression testing, not reliance on the sponsor’s assertion that a change is minor.
• Non-determinism complicates comparison. A before-and-after score difference must be
judged against run-to-run variance (Question 12).
So classi cation should rest on what the change could do to behaviour, con rmed where feasible
by testing.

3. Dimensions that determine expected impact

Dimension Lower impact Higher impact
Component Hosting, logging, UI Foundation model, ne-tuning, system prompt,
changed cosmetics guardrails, retrieval sources, orchestration logic
Effect on
New indication, population, user group, function, or
intended use or None
higher reachable activity level (Question 5)
claims
Effect on risk tier Raises activity, consequence, or detectability
Unchanged
or modi ers (Question 1)
Effect on safety- Provably isolated from
Plausibly touches escalation, scope, calibration
critical behavior S.1, S.2, S.3
Scope of
Narrow, wellbehavioral Broad or hard to characterize (full model swap)
characterized
change
Instant rollback
Reversibility Hard to undo, or data/state effects
available

Date 18/10/2026 101 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
fi fi fi
 Deterministic or veri ed
Predictability Emergent, third-party, unnoti ed
by regression
Subgroup effects None expected, veri ed Could alter subgroup performance
Staged or canaried
Exposure Immediate full deployment
rollout
Same category of
Prior evidence change with a clean Novel type of change
record

4. A three-tier evidence scale

Placeholder categories for discussion, not validated thresholds.

Impact class Typical changes Evidence expected Pathway
Infrastructure, logging, cosmetic UI, Veri cation that behavior is
bug xes outside model behavior, unchanged: canary and
A. Minimal QMS
security patches with no behavioral smoke tests, hash or version
effect checks, documented rationale
Retrieval content updates within
Targeted re-benchmarking of QMS if
de ned sources, guideline refreshes,
affected elements, plus gating inside
prompt or guardrail tightening that
safety elements (S.1 to S.3) if prespeci e
B. Bounded narrows behavior, adding language
reachable; regression on d bounds;
support within validated scope,
sequestered slice; subgroup otherwise
performance optimization with
check where relevant PCCP
unchanged model
Full re-benchmarking of
PCCP if
Foundation model swap or version applicable elements against
fully
change, ne-tuning or retraining, the baseline thresholds;
prespeci e
system-prompt redesign, new tools or trajectory and pressure-path
C. Material d;
agentic capability, changes that tests; concordance check
otherwise
broaden output types, any change that against real-world data;
FDA
could raise directiveness con rmation evidence scaled
review
to tier
FDA
D. Change in New indication, new population, New or extended competency review
intended use higher activity level, new user group, assessment and clinical before
or risk autonomous operation con rmation implement
ation

Note that gating safety elements are re-tested for any change that could plausibly affect them,
regardless of class. The tier of the device sets the rigor within each class (Question 8): a Class B
change to a high-tier device warrants more than the same change to a low-tier one.

5. Categories that may not signi cantly affect safety or effectiveness

These can plausibly be managed in the QMS, conditional on veri cation:

• Infrastructure and operations: hosting, scaling, latency optimisation, logging, monitoring
tools, provided canary tests show unchanged behaviour.

Date 18/10/2026 102 of 131 FDA-2026-N-7874

fi
fi
fi fi
fi
fi
fi
fi
fi
fi fi
fi fi
 •Cosmetic or accessibility changes to the interface that do not change content, order,
emphasis or warnings that affect how outputs are read. UI changes can alter reliance and
comprehension, so those affecting presentation of outputs, uncertainty or escalation
messages should not be treated as cosmetic.
• Bug xes to non-model components with isolated, tested effects.
• Security patches with no behavioural effect, tested.
• Documentation and labelling clari cations that do not alter intended use or claims.
• Content corrections that move the device closer to current guidelines in a way that is
veri ed against the sources (with targeted E.1 and E.3 testing).
• Restricting scope or adding safeguards (narrower outputs, additional refusals, tighter hard
limits), which usually lower risk, though they can raise over-refusal (S.2) or over-escalation
(Question 6) and so need testing for those.
Three cautions apply:

1. “Presumed minor” must be shown. Each category should be a default with a minimum
veri cation, not an exemption.
2. Cumulative drift. A series of individually minor changes can accumulate into a material
one. The QMS should track cumulative change against the baseline, with periodic rebenchmarking and a trigger when accumulated change passes a threshold.
3. Restricting changes can have side effects, so risk-lowering intent does not remove the
need for regression testing.
6. Categories appropriate for a PCCP

A PCCP works where the change can be speci ed in advance, tested with a pre-speci ed
protocol, and bounded. The paper notes that PCCP concepts may need adaptation for GenAI
(Question 23). Candidate categories:

Category Why it ts Needed in the plan
Retrieval and
Content
knowledge-base updates Source inclusion criteria, update procedure, currency
changes recur
within de ned source checks, regression slice, citation-faithfulness testing
predictably
types and quality criteria
Foreseeable,
Guideline-driven Mapping of guideline change to affected test items, reexternally
content updates benchmarking of E.1 and E.3
triggered
Allows
De ned acceptance rule against baseline: gating
Re-benchmarked model adopting
elements not worse than baseline by a prespeci ed
version updates within a newer
margin; no new failure classes; subgroup parity; anyde ned envelope versions of a
run failure rates (Question 12)
model family
Language and dialect Per-language benchmark sets, native-speaker and
Predictable
additions within validated community review, subgroup validation, real
expansion
scope calibration data (Question 13)
Prompt and guardrail Bounds on what can change (no change to scope,
Frequent
re nements inside directiveness ceiling, escalation rules), regression on
tuning
prespeci ed bounds sequestered set
Threshold and
Classic PCCP
parameter adjustments Ranges, tests, stopping rules
territory
with prespeci ed ranges

Date 18/10/2026 103 of 131 FDA-2026-N-7874

fi
fi fi fi fi
fi fi fi fi fi fi fi fi fi
 Expansion to additional
Predictable Site validation protocol, staged exposure, monitoring
sites or settings with the
rollout (Question 18)
same intended use
Performance
improvements to
Isolated
modular components Interface-level and system-level tests
change
(for example a retrieval
ranker)
Fine-tuning on Foreseeable Data inclusion criteria, development/evaluation
prespeci ed data sources retraining rewall, full re-benchmarking, rollback

A de ning condition: the PCCP should name the acceptance criteria and the evidence for each
change type, tied to the baseline assessment. The acceptance criteria should not be loosened after
seeing results.

7. Categories that should require FDA review before implementation

• Change in intended use or indication, target population, or user group (for example a
clinician tool opened to patients).
• Increase in reachable activity level or consequence class (informational to actiondirecting, advisory to autonomous), per Question 5.
• Addition of agentic capabilities or tools that take actions (Question 26).
• Foundation model changes that fall outside the PCCP’s de ned envelope, such as a
different model family, architecture or modality (Question 17), or a change so large that
baseline comparability is doubtful.
• Changes that alter the baseline assessment’s validity, such as a change in the output
format that invalidates scoring rubrics.
• Removal or weakening of safety-critical controls (hard limits, escalation rules, refusal
boundaries).
• Any change that fails the PCCP acceptance criteria, or where re-benchmarking shows
degradation in a gating element or a new failure class.
• Changes whose impact cannot be bounded in advance, for example unnoti ed third-party
updates not covered by detection and rollback.
• Changes after a signi cant safety signal in post market monitoring, pending root-cause
analysis.
8. Using the baseline well: what the premarket assessment must support

For the baseline to work, the premarket package should be designed with change in mind:

1. Versioned instruments with documented content, scoring rubrics and run protocols, so later
runs are comparable.
2. Recorded baseline distributions, including run-to-run variance, so changes can be judged
against noise.
3. Gating thresholds and a comparison rule (for example non-inferiority to baseline with a
justi ed margin on each gating element, not a point comparison).
4. A sequestered, refreshed portion that developers have not tuned against, because repeated
use of the same test set during change development in ates scores (Question 10).
5. Element-to-component mapping, stating which components can affect which elements, so
that targeted re-testing is principled.
6. Concordance evidence linking benchmark results to real-world performance, so that rebenchmarking still means something (Question 10).
Date 18/10/2026 104 of 131 FDA-2026-N-7874

fi
fi
fi fi
fi fi fi fl
 7. Baseline preservation. Retain the old version for parallel runs and rollback, since “better
than baseline” requires the baseline to be runnable.
Two further points on the comparison itself:

• Non-inferiority to a baseline that itself drifted. Repeated acceptance of small
degradations can ratchet performance downward (“benchmark creep”). Compare against the
original authorised baseline, not only the previous version, with a cumulative tolerance.
• Improvement claims need superiority evidence. If a change is intended to improve
performance, and that improvement is relied upon, it needs evidence beyond non-inferiority
and should be tied to the claim.
9. Scaling by tier and modi ers

Device pro le How the scale shifts
Lower tier, non- More changes can sit in QMS or PCCP Class B; lighter re-benchmarking;
directive sponsor-run testing acceptable
Class B changes need targeted regression including S.2 and S.3; independent
Middle tier
adjudication of regression results for material changes
Higher tier,
Even Class B changes touching escalation, scope or dosing need re-testing of
directive or
gating elements on sequestered sets; Class C changes need con rmation
autonomous,
evidence, and FDA review is more likely unless the PCCP is tightly speci ed
time-critical
Low
Users cannot detect regression, so the burden of pre-release testing rises
detectability
Agentic or toolMore changes (new tools, new permissions) fall into higher classes
using

10. Staged release and rollback as part of the evidence

For changes that pass regression, staged rollout adds protection: shadow evaluation against live
traf c with clinician review of disagreements (Question 19), canary release to a fraction of users,
de ned monitoring thresholds, and a tested rollback. This lets a sponsor use real-world evidence to
supplement benchmarks for Class B and C changes, and lessens pressure to over-test premarket. For
higher tiers it should be an addition to, not a substitute for, pre-release evidence on gating elements
(Question 18).

11. Illustrative cases

Change Device Suggested class and pathway
Migrating inference
hosting with unchanged Any A; QMS, with canary and version-equivalence checks
model and prompts
Quarterly update of
HCP-facing B; PCCP with prespeci ed source criteria and E.1/E.3
guideline sources in the
summarizer re-testing
retrieval layer
PatientAdding Spanish within a facing B to C; PCCP with per-language benchmarks and
validated clinical scope education community review, if prespeci ed
tool

Date 18/10/2026 105 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
fi
 Upgrading to a newer C; PCCP only if acceptance criteria are tight; S.1 reChest-pain
version of the same model tested on sequestered set, trajectory tests, staged release;
triage
family otherwise FDA review
Rewriting the system Medication C; may shift directiveness, so test E.4, S.2, S.3 and
prompt to make answers information directiveness distribution; treat as material despite its
friendlier assistant appearance
Adding a tool that places Clinical
D; FDA review
orders assistant
Extending a clinician tool Dosing
D; FDA review
to patient use support
Unannounced upstream Device on
C by default; immediate re-benchmark, possible
model update detected by third-party
rollback, FDA noti cation path per plan (Question 24)
canaries model

These are illustrative only and not a proposed classi cation.

12. Cautions

• Do not classify by the sponsor’s description alone. Require testing-based evidence of
impact, since descriptions of GenAI changes are unreliable predictors of behaviour.
• Avoid a mechanical lookup table. The classes are a default with a justi cation route, and
the ambiguity rule should push uncertain cases up.
• Guard against change-splitting to keep each step under a threshold. The cumulativechange tracker addresses this.
• Avoid over-burdening low-risk updates. Frequent, small, bene cial updates (content
currency) should be easy, or devices will stagnate or use stale knowledge, which is itself a
safety risk.
• Beware of re-benchmark overuse. Frequent re-running of the same instrument against
developers’ changes leads to tuning toward it. Keep a sequestered set and limit looks.
• Do not treat passing a benchmark as suf cient for Class C and D changes where
predictive validity is untested or user behaviour may change (Question 11).
• Account for non-determinism. Declare “no change” only within variance bounds, with
enough runs to detect a meaningful shift.
• Do not forget the human side. Changes to presentation, tone or explanations can alter user
reliance without altering factual content, which benchmarks may not capture.
13. Limitations and open questions

• There is no empirical basis for the class boundaries or evidence levels above. Pilot
application to real change histories (for example, retrospectively classifying past updates
and checking which affected behaviour) would test whether the classes track real impact.
• It is unclear what margin should de ne “not worse than baseline” for each gating element,
and how to set cumulative tolerance.
• Predicting which components affect which elements is imperfect, so targeted re-testing may
miss unexpected interactions, and sponsors may need periodic full re-benchmarking
regardless.
• How to treat changes to a model the sponsor does not control, when behaviour shifts without
a described change, is unresolved (Question 24).
• Whether QMS-managed changes can be adequately audited by FDA, and how, is a question
I ag but do not assess.

Date 18/10/2026 106 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fl fi
fi
 • The legal and procedural scope of a PCCP and which changes may be authorised in advance
are outside the paper’s stated scope and my own.
14. Recommendations

1. Design the premarket assessment to be re-runnable: versioned instruments, recorded
baseline variance, pre-speci ed gating thresholds and comparison rules, a sequestered
portion, an element-to-component map, and preserved baseline versions.
2. Scale evidence by expected impact on behaviour and risk, not technical size, using a
published, impact-based classi cation with a justi cation route and an ambiguity rule that
places uncertain changes in the more rigorous class.
3. Allow a narrow set of QMS-managed changes (infrastructure, isolated bug xes, tested
security patches, labelling clari cations, risk-narrowing changes) conditional on minimum
veri cation of unchanged behaviour.
4. Re-test gating safety elements for any change that could plausibly affect them, at every tier.
5. Support PCCPs for foreseeable, bounded changes (retrieval and guideline updates, model
version updates within a de ned envelope, language additions, bounded prompt and
guardrail re nements, parameter ranges, site expansion, pre-speci ed ne-tuning), each with
pre-speci ed acceptance criteria and evidence.
6. Require FDA review before implementation for changes to intended use, population or
user group, increases in reachable activity level, agentic capabilities, removal of safety
controls, model changes outside the PCCP envelope, and changes that fail acceptance
criteria or cannot be bounded.
7. Compare against the original authorised baseline with a cumulative tolerance, and track
accumulated change to prevent benchmark creep and change-splitting.
8. Scale rigor with device tier and modi ers, and pair material changes with staged release,
shadow evaluation and tested rollback, as additions to pre-release evidence for higher tiers.
9. Treat changes to output presentation and tone as potentially behaviour-affecting.
10. Pilot the classi cation against historical change records before formalising it.

Question 23 - How might PCCP concepts or other change-control approaches be adapted for
GenAI-enabled devices when the nature or scope of future modifications cannot be fully prespecified?

1. Summary position

A conventional PCCP assumes the sponsor can describe future changes and their tests in advance.
For GenAI devices that is often only partly true: foundation model versions, prompts and retrieval
content evolve in ways that are foreseeable as categories but not as speci c modi cations. We
recommend shifting what is pre-speci ed from the change to the envelope and the acceptance
process. The sponsor pre-speci es (a) a bounded behavioural envelope the device must stay
within, (b) the evidence protocol and acceptance criteria any change must pass, (c) hard
exclusions that always require FDA review, and (d) rollout, monitoring and rollback rules. The
modi cation itself may be unspeci ed, but the test it must pass is not. I describe PCCP mechanics
only as the paper does, and I have not veri ed current PCCP guidance or authorities, which the
paper places out of scope.

2. Why full pre-speci cation fails for GenAI

• Upstream changes are not the sponsor’s to schedule (Question 24). The sponsor may not
know the content of a future model version.
Date 18/10/2026 107 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi fi
 • Behaviour is emergent. The effect of a change cannot be derived from its description, so
the plan must rest on testing, not on description (Question 22).
• The space of future prompts, content and con gurations is open-ended.
• Useful updates are frequent. Content currency and safety patches need to move faster than
a case-by-case review cycle.
• Bene t and risk can both come from the same change, so a blanket prohibition on
unspeci ed change would freeze devices on stale models, which is itself a risk.
3. Core adaptation: pre-specify the envelope and the test, not the change

Why it works
Element What is prespeci ed without knowing
the change
Any change is
Maximum activity level and consequence class, clinical
Behavioral acceptable only if
scope, prohibited actions, directiveness ceiling, escalation
envelope the device stays
rules (Question 5)
inside it
Versioned benchmark, sequestered set, trajectory and
The same test
Acceptance pressure tests, subgroup checks, any-run failure criteria,
applies to whatever
protocol non-inferiority margins against the original authorized
the change is
baseline (Question 22)
Not negotiable per
Gating oors Absolute thresholds on safety-critical elements
change
Sponsor commits to
Which categories are eligible (Question 22, Section 6)
Change classes the categories, not
and which are excluded
the instances
Limits exposure if
Shadow evaluation, canary or staged rollout, stopping
Release controls testing misses
rules, rollback
something
Keeps visibility
Reporting What FDA is told, when, with what data without per-change
review

This turns the PCCP from a list of planned modi cations into a change-acceptance protocol: a
contract about how any change will be judged.

4. Design options

4.1 Envelope-based PCCP. The plan de nes the envelope and the acceptance protocol. Changes
passing the protocol within the envelope proceed. Changes that exceed the envelope or fail criteria
go to FDA. This is the closest adaptation of the existing concept.

4.2 Tiered or layered plans. Pre-authorise low-impact categories fully (content refresh within
source criteria), pre-authorise medium-impact categories with stricter evidence and noti cation, and
exclude high-impact categories. This mirrors the A to D classes in Question 22.

4.3 Pre-authorised change protocols with noti cation. For eligible changes, the sponsor
completes the protocol and noti es FDA with results before or promptly after rollout, with a
de ned window in which FDA can object or request more. Noti cation before deployment suits
higher-tier devices, after deployment lower-tier. This adds visibility without a full review.

Date 18/10/2026 108 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
fi
fl
fi
fi
fi
 4.4 Rolling or periodic review. For devices that change frequently, a scheduled review (for
example, a periodic submission of cumulative change records, benchmark results, and monitoring
data) replaces per-change lings. It must be paired with a cumulative-change tracker against the
baseline so that incremental drift is visible.

4.5 Staged or conditional authorisation of the process. FDA could review and authorise the
sponsor’s change-management system (instruments, protocols, thresholds, rollback capability,
monitoring) as an object of review, then rely on it for conforming changes. Credit should depend on
demonstrated performance of that system, for example through audits or a track record, and could
be withdrawn.

4.6 Dynamic trust. Latitude could expand with a clean record of accurately classi ed changes and
detected problems, and contract after incidents. This rewards good practice but needs transparent
criteria to avoid arbitrary treatment, and I ag its governance as unresolved.

4.7 Model-family envelopes. Where the sponsor expects to adopt successive versions of a
foundation model, the plan could de ne the eligible family, the minimum documentation required
from the model developer (links to Foundation Model MAFs, Question 25), and the acceptance
protocol, while excluding architecture or modality changes (Question 17).

4.8 Interface-based decomposition. Where the device is modular, pre-specify component
contracts (what each component must do at its interface) so that a component can be swapped if it
meets the contract and system-level tests pass. System testing remains required because interactions
can break even when components pass.

5. Handling un-pre speci able and unannounced changes

Some changes cannot be planned, notably upstream model updates the sponsor did not initiate
(Question 24). Adaptations:

• Detection plans in place of change descriptions. Canary probes, version checks and
behaviour ngerprinting to detect that a change has occurred (Question 19).
• Default classi cation. Treat an unannounced behavioural change as Class C pending
testing, with a pre-speci ed response: re-benchmark, restrict if gating elements degrade, and
notify FDA per plan.
• Version pinning where possible. Contract for xed model versions with notice before
retirement, so that updates become planned changes within the PCCP.
• Fallback. A pre-speci ed degraded or paused mode if acceptance fails and no safe prior
version is available.
• Time-bounded responses. De ne how quickly the sponsor must test and decide after
detecting a change.
6. Guardrails that keep adaptation from becoming open license

Risk Safeguard
FDA reviews the envelope as part of authorization; envelope expressed
Envelope too loose in testable terms (directiveness distribution, reachable states, gating
thresholds), not aspirations
Acceptance criteria Criteria xed in the plan; any change to them is itself a change needing
loosened after the fact review

Date 18/10/2026 109 of 131 FDA-2026-N-7874

fi
fl
fi
fi
fi
fi
fi
fi
fi
fi
fi fi
 Benchmark over tting
during repeated Sequestered sets, limits on looks, refresh policy (Questions 10, 16)
change testing
Compare with the original baseline and a cumulative tolerance (Question
Benchmark creep
22)
Change-splitting Cumulative tracker; periodic full re-benchmark
Weak predictive
Concordance checks with real-world data; con rmation evidence for
validity of the
material changes (Question 10)
instrument
Hidden user-facing Include presentation, tone and reliance measures in protocol for changes
effects that affect them
Reduced regulatory
Noti cation, periodic reporting, FDA access to underlying data
visibility
Sponsor
Testing-based classi cation, ambiguity rule toward stricter class, audit
misclassi cation
Accountability Sponsor remains accountable for conforming and non-conforming
diffusion changes (Question 21)

7. Hard exclusions: what a plan should not cover

Consistent with Question 22, Section 7:

• change in intended use, population or user group
• increased reachable activity level or consequence class
• agentic tools or autonomous action
• different model family, architecture or modality outside the envelope
• weakening or removal of safety-critical controls
• changes that alter the validity of the baseline instrument
• changes after a serious safety signal, pending analysis
• anything failing the acceptance protocol
A plan that tried to pre-authorise these would not meet the idea of bounded change.

8. Evidence the plan itself should contain

1. Envelope de nition with measurable boundaries.
2. Change classes with eligibility and exclusion criteria.
3. Acceptance protocol for each class: instruments, versions, runs, thresholds, margins,
handling of variance, subgroup and trajectory requirements.
4. Rollout protocol: shadow, canary, expansion criteria, stopping rules.
5. Rollback demonstration: tested, with time to restore.
6. Monitoring linkage: which signals trigger reassessment (Question 19).
7. Upstream-change procedure: detection, classi cation, response times.
8. Governance: accountable roles, documentation, audit trail, independent review for material
changes (Question 16).
9. Reporting schedule to FDA and content of reports.
10. Plan-change rules: how the plan itself may be updated.
9. Scaling by tier

Tier or pro le Adaptation
Date 18/10/2026 110 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
fi
 Broader envelope-based latitude, post-implementation noti cation,
Lower tier
periodic review
Envelope plan with noti cation before deployment for material classes,
Middle tier
independent adjudication of regression results
Higher tier, time- Narrow, tightly speci ed plan; pre-implementation FDA noti cation or
critical, directive or review for most material changes; con rmation evidence for model
autonomous changes; staged exposure
Low detectability Stricter pre-release testing, since users cannot notice regression
Third-party-model
Version pinning and detection requirements as conditions of any latitude
dependent

10. Illustrative cases

Situation Adapted approach
Education tool adopting newer
Envelope plan, model-family eligibility, acceptance protocol,
versions of the same model
post-implementation noti cation
family quarterly
Pre-implementation noti cation with full results, gating elements
Triage device wanting to adopt
on sequestered set, trajectory tests, staged rollout; FDA review if
a new model
criteria not clearly met
Third-party provider silently Canary detects; default Class C; re-benchmark; rollback or
updates its model restriction; report per plan
Sponsor wants to add
Outside envelope; FDA review
medication dosing advice later
Frequent prompt tuning by a Bounded prompt re nements inside the envelope, cumulative
small developer tracker, periodic review

These are illustrative only and not a proposed classi cation.

11. Cautions

• Pre-specifying the test is not the same as pre-specifying the change. The rst can be
rigorous, but it depends on the instrument being predictive of real-world safety, which is
unestablished (Question 10).
• Do not let the plan become a loophole. An overly broad envelope with weak acceptance
criteria amounts to authorisation without review.
• Avoid an unusable plan. Excessive pre-speci cation of what cannot be known will lead
sponsors to write vague plans or avoid updating.
• Beware of reviewer capacity. Envelope-based and rolling review need reviewers with the
expertise to judge protocols, which I have not assessed.
• Do not reward change velocity. Speed of updating should not be treated as a virtue in
itself.
• Beware lock-in to a weak instrument. If the baseline benchmark is awed, every change is
judged against a awed standard.
12. Limitations and open questions

Date 18/10/2026 111 of 131 FDA-2026-N-7874

fi
fl
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fl
 • There is no empirical evidence that envelope-based change protocols keep GenAI devices
safe, and these are design proposals. Retrospective application to historical update records
would be informative.
• Whether an envelope can be speci ed precisely enough to be testable and enforceable,
without becoming brittle, is untested (Question 5).
• How to set margins and cumulative tolerances is unresolved (Question 22).
• Dynamic-trust and process-authorisation models raise governance and fairness questions I
do not resolve.
• The legal and procedural scope of what can be pre-authorised, and of noti cation or periodic
review mechanisms, is outside the paper’s stated scope and my own.
• Some changes may defeat any pre-speci ed protocol, and the right default for them is a
judgment I make cautiously (stricter class, FDA review).
13. Recommendations

1. Adapt the PCCP concept from pre-specifying changes to pre-specifying a behavioural
envelope, a change-acceptance protocol, hard exclusions, and rollout and rollback
rules.
2. Express the envelope in testable terms (reachable states, directiveness ceiling, gating
thresholds, scope) and have FDA review it as part of authorisation.
3. Fix acceptance criteria against the original authorised baseline, with cumulative
tolerance, sequestered sets and limits on looks, and treat any alteration of criteria as a plan
change.
4. Consider noti cation-based pathways (before deployment for higher tiers, after for lower
tiers) and periodic cumulative review for frequently changing devices.
5. Allow model-family and component-contract approaches where documentation and
interface tests support them, with system-level testing retained.
6. For unannounced upstream changes, require detection mechanisms, default Class C
treatment, version pinning where possible, and pre-speci ed response times and fallbacks.
7. Maintain hard exclusions for changes in intended use, activity level, agentic capability,
model family or modality outside the envelope, and weakened safety controls.
8. Scale latitude by tier and modi ers, with the narrowest plans for time-critical, directive or
low-detectability devices.
9. Require staged release, tested rollback and monitoring linkage as part of the plan, as
additions to, not substitutes for, pre-release evidence at higher tiers.
10. Keep sponsor accountability for all changes and FDA access to underlying data, and pilot
envelope-based plans on real change histories before formalising them.

Question 24 - For devices built on third-party foundation models, changes to the underlying
model may be initiated by the third-party model developer rather than the device
manufacturer. How can a manufacturer detect, evaluate, and respond to such changes in a
timely manner? What mechanisms—for example, contractual, technical, or through a PCCP
—could provide reasonable assurance that third-party developer-initiated changes do not
compromise the safety or effectiveness of the device?

1. Summary position

No single mechanism gives reasonable assurance. Contracts can promise notice, but providers may
not give it, may not describe changes accurately, and may not know the behavioural effects
themselves. Technical detection can catch behavioural change regardless of notice, but only for
Date 18/10/2026 112 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
 what it tests. We recommend a layered assurance model with four parts: (a) prevention through
version pinning and contractual notice, (b) detection that does not depend on the provider (canaries,
ngerprinting, version checks), (c) evaluation through a pre-speci ed re-benchmarking protocol on
the deployed system, and (d) response through tested rollback, restriction and reporting. The
manufacturer remains accountable for the device regardless of where the change originates
(Question 21). Where a manufacturer cannot get pinning, notice or an adequate fallback, the device
should receive less latitude (narrower PCCP, lower autonomy, or no reliance on post-market
substitution for premarket evidence, Question 18). I describe contractual, MAF and PCCP
mechanisms only as the paper does and have not veri ed current requirements.

2. Types of third-party change

Visibility to
Type Examples
manufacturer
Announced version release High New model version, with documentation
Announced deprecation or High, with a
Pinned version scheduled for shutdown
retirement deadline
Unannounced update to a Silent weight, safety-tuning or system-layer
Low
named version changes behind a stable model identi er
Alias or “latest” pointer
Medium Endpoint automatically re-pointed
movement
Altered refusal behavior, content moderation,
Policy or lter changes Low
output formatting
Quantization, hardware, decoding defaults,
Serving-stack changes Low
context handling
Tool, retrieval or feature
New default tools, altered function-calling
changes in the provider Medium
behavior
platform
Terms, data-use or availability
High Rate limits, regional availability, outages
changes

The unannounced types matter most, since a trigger the manufacturer cannot see will not re
(Question 19). I describe these categories from general understanding of how hosted models are
operated, not from any speci c provider’s practice.

3. Prevention: reducing unplanned change

Technical.

• Pin to explicit, immutable model versions and avoid aliases that move. Where a provider
offers only mutable endpoints, record that as a risk factor.
• Prefer deployment options that give control over change timing (dedicated or self-hosted
instances, snapshot access), where feasible, recognising cost and capability tradeoffs.
• Set decoding parameters explicitly (temperature, seeds where supported, token limits) so
defaults changing upstream do not alter behaviour.
• Keep a fallback model that has been validated, so a bad upstream change does not leave the
device with no safe option.
Contractual. Agreements with providers could seek:

Date 18/10/2026 113 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
 Term Purpose
Advance notice of changes (with minimum lead time scaled to
Allows testing before cutover
impact)

Avoids forced migration with
Notice of deprecation with de ned support windows
no test time

Change classi cation and release notes covering behavior,
Informs targeted re-testing
safety tuning, lters and serving changes

Version immutability commitments for pinned identi ers Prevents silent change

Incident noti cation for defects or safety-relevant behavior
Alerts downstream users
changes
Access for evaluation (sandbox access to candidate versions
Enables pre-release regression
before release)
Cooperation with investigation (logs, model documentation,
Supports attribution
root-cause information)
Documentation obligations (model or system cards, known Links to Foundation Model
limitations, evaluation results) MAFs (Question 25)
Audit or attestation rights Veri es compliance
Termination and transition assistance Supports migration

Realistically, bargaining power varies. Large providers often offer standard terms, and small
manufacturers may not obtain bespoke commitments. This matters for equity and competition and is
one reason a voluntary MAF with standardised content (Question 25) could help, though
participation is voluntary and incentives are uncertain. Contract terms also do not guarantee
behaviour. A contract that promises notice is evidence of intent, not detection.

4. Detection: nding changes the provider did not announce

4.1 Canary and sentinel probes. A xed set of prompts, including safety-critical scenarios, run
against the live endpoint at a frequency set by tier and exposure (Question 19). Outputs are scored
against pre-speci ed criteria or compared with stored reference behaviour. Strengths: cheap, fast,
provider-independent. Limits: narrow coverage, and non-determinism produces natural variation, so
thresholds must be set from repeat-run variance (Question 12).

4.2 Behavioural ngerprinting. Maintain a larger probe set and statistical summaries of responses
(distributions of refusal, directiveness, escalation, length, format, calibration statements) and test for
distributional shift. This can detect broad changes that single canaries miss. It detects change, not
harm.

4.3 Metadata and identi er checks. Log and verify model identi ers, version strings, response
headers and system ngerprints where the provider supplies them. Treat these as a weak signal,
since identi ers can stay constant while behaviour changes.

4.4 Production-traf c monitoring. Track output distributions, ag rates, user override and
complaint rates, and safety-boundary signals on live traf c, using change-point detection to identify
abrupt shifts that coincide with upstream change (Question 19).

Date 18/10/2026 114 of 131 FDA-2026-N-7874

fl
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi fi
fi
fi
fi
 4.5 Shadow comparison. Where the sponsor can hold a reference copy of a prior version, run both
on a sample of live inputs and compare. Where no prior version is available, compare against stored
outputs from earlier periods on xed inputs.

4.6 Monitoring external channels. Provider release notes, status pages, deprecation notices and
developer communications, plus public reports of behaviour changes. Useful but unreliable as the
only source.

4.7 Consortium or cross-sponsor signals. Multiple manufacturers using the same model could
share canary outcomes through an independent body, detecting changes faster and with more
statistical power (Question 21). This raises con dentiality, competition and governance questions I
ag but do not resolve.

4.8 Detection of format and interface changes. Parsing failures, schema changes in structured
outputs and tool-call behaviour often signal upstream change and can break downstream logic
silently. Include integration tests.

A design requirement. The sponsor should demonstrate, premarket, that its detection system
would have caught representative changes, by replaying known prior version differences or
deliberately perturbed con gurations, and report detection latency (Question 19, Section 7).

5. Evaluation: assessing impact once a change is detected or announced

5.1 Default classi cation. Treat an unannounced behavioural change as Class C (material) until
tested (Question 22), and an announced new version as Class C unless the sponsor has evidence
otherwise.

5.2 Re-benchmarking on the deployed system. Run the pre-speci ed acceptance protocol against
the changed system, not the model in isolation: gating elements rst (S.1 to S.3, safety-critical R.1),
then affected pro ciency elements, subgroup checks and trajectory and pressure-path tests where
reachable. Compare with the original authorised baseline and apply the cumulative tolerance
(Question 22).

5.3 Targeted testing guided by change information. Where the provider describes the change (for
example a safety-tuning update), prioritise related elements, but do not limit testing to the described
scope. Descriptions are not reliable predictors of effect.

5.4 Pre-release evaluation where access exists. If the provider offers early access to candidate
versions, run the full protocol before cutover so the sponsor controls the timing.

5.5 Time limits. Pre-specify how fast evaluation must occur, scaled by tier. For high-risk, timecritical devices, the interim posture (continue, restrict, switch to fallback) must be decided in hours
or days, not weeks.

5.6 Interim controls during evaluation. Options include temporarily raising human review rates,
restricting scope, disabling the highest-risk functions, or reverting to the fallback. These should be
pre-speci ed, with authority assigned.

5.7 Attribution. Log model, prompt, retrieval and con guration versions on every interaction so
that behaviour changes can be attributed to the upstream model and not to sponsor-side changes.

Date 18/10/2026 115 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
fi
fi
fl
 5.8 Evidence that does not depend on the provider’s disclosure. The device’s safety case should
rest on behaviour of the deployed system, which the manufacturer can measure, rather than on
model internals it cannot see (consistent with the paper’s focus on the nal user-facing device).

6. Response: acting on results

Result Suggested response

Acceptance criteria met, within Proceed under the PCCP or QMS, per classi cation; record
envelope and report per plan

Hold on the prior version if pinned; staged exposure;
Marginal or uncertain
enhanced monitoring; consider FDA noti cation

Gating element degraded or new Roll back or restrict; notify FDA per plan; root-cause
failure class analysis; correct or nd alternative

Prior version unavailable and Fallback model, degraded mode or pause; communicate to
new version unacceptable users

Provider unresponsive or non- Escalate contractually; consider replacing the provider;
cooperative document

Requirements that make response real:

• Tested rollback, with measured time to restore (Question 18).
• Fallback model validated against the baseline in advance, so that switching is a tested path,
not an improvisation.
• User communication plan for restrictions or changed behaviour, especially for patientfacing devices.
• Reporting to FDA of material changes and safety-relevant ndings, per plan and existing
obligations, which I have not veri ed.
• Feedback to the provider and, where a MAF exists, to its le, so that defects are shared.
7. How a PCCP and related mechanisms could contribute

• Model-family eligibility. The plan de nes which models or versions are eligible and the
documentation required (Question 23, Section 4.7).
• Acceptance protocol. A pre-speci ed re-benchmarking protocol with thresholds, against
which any version, announced or not, is judged.
• Detection and response plan as plan content. Canary schedule, drift thresholds, default
classi cation, response times, rollback and fallback procedures.
• Noti cation rules. Pre- or post-deployment noti cation to FDA depending on tier.
• Exclusions. Different model families, architectures or modalities, and any change that fails
acceptance, require FDA review.
• Conditions on latitude. Latitude conditioned on version pinning or equivalent control,
working detection and tested rollback. A manufacturer lacking these should not receive
broad pre-authorisation.

Date 18/10/2026 116 of 131 FDA-2026-N-7874

fi
fi fi fi fi fi fi fi fi fi fi fi
 For unannounced changes, a PCCP cannot pre-specify the change, but it can pre-specify the
detection, classi cation and response, which is the adaptation proposed in Question 23.

Foundation Model MAFs (Question 25). A MAF holding model documentation, changenoti cation commitments and audit-log availability could reduce the information gap. It could also
support FDA’s understanding of which devices share a model. Caveats: voluntary participation,
uncertain incentives, risk of becoming a checkbox, and a need for the le to be kept current. It
would not replace deployed-system testing, and as the paper states, would not authorise the model
for any use.

8. Scaling by tier and dependency

Pro le Suggested posture
Lower tier, non- Pinning preferred; periodic canaries; post-change re-benchmarking of affected
directive elements; more tolerance for provider-controlled updates
Pinning or detection with short latency; re-benchmarking before or promptly
Middle tier
after change; fallback available
Higher tier, time- Pinning or controlled deployment expected; pre-release evaluation access;
critical, directive, gating-element re-test before cutover; tested fallback; no reliance on unnoti ed
or autonomous provider updates; FDA noti cation or review for model changes
No pinning, no
Narrow latitude; not suitable for reduced premarket evidence or highnotice, no
consequence autonomous functions
fallback
Multi-provider Failover between models helps availability but adds variance; each model
architecture route needs validation

9. Illustrative cases

Situation Response
Provider announces a new version Request sandbox access, run full protocol, stage rollout; stay
in 90 days on pinned version until acceptance met
Canary pass rate for escalation
Default Class C; run gating tests; if S.1 degraded, restrict or
scenarios drops overnight with no
fall back; notify per plan; request provider information
notice
Migration plan with validated successor or fallback; if not
Provider retires a version with 30
achievable in time, restrict scope or pause higher-risk
days’ notice
functions
Test over-refusal (S.2), escalation completeness and user
Provider tightens content lters,
comprehension; decide whether to adjust prompts within the
causing more refusals
envelope
Small developer cannot negotiate Rely on technical detection, pinning if available, and a
terms narrower plan; consider alternative deployment options

These are illustrative only and not a proposed classi cation.

10. Cautions

Date 18/10/2026 117 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
fi
 • Detection is limited by what is probed. Canaries cover a small part of the behavior space,
so a quiet canary is not proof of unchanged safety. Periodic full re-benchmarking remains
necessary.
• Non-determinism creates false alarms and missed signals. Thresholds must re ect run-torun variance, and alert handling must be resourced.
• Notice from a provider is not assurance. Providers may not know the downstream effects,
and notices may omit relevant changes.
• Do not treat the provider’s evaluations as the device’s evidence. The device
con guration differs from the base model’s testing context.
• Contract terms may be unenforceable in practice, especially for small manufacturers.
• Concentration risk. Many devices on one model create correlated exposure to one
upstream change (Question 21).
• Cost. Continuous probing and frequent re-benchmarking cost money, and requirements
should scale by tier to avoid shutting out small developers (Question 16).
• Do not diffuse accountability. The manufacturer owns the effects of upstream change on its
device, whatever the contract says.
• Beware of dependence on the evaluator’s tooling. If detection or scoring uses a model
from the same provider, it may change simultaneously (Question 20).
11. Limitations and open questions

• I am not aware of empirical evidence on how often hosted models change behaviour without
notice, or how well canary-based detection performs in medical settings. Pilot studies
measuring detection latency against known changes would be informative.
• How many canaries or probes are enough for a given tier has no established answer.
• Whether providers will sign meaningful noti cation and access commitments, and whether a
voluntary MAF would change that, is uncertain.
• How to compare behaviour across versions when outputs are non-deterministic and the
baseline itself is no longer runnable is unresolved.
• The legal enforceability of downstream commitments and the allocation of responsibility
among providers, manufacturers and institutions are outside the paper’s scope and my own.
• Cross-sponsor sharing of detection signals raises governance questions I do not resolve.
12. Recommendations

1. Treat assurance as layered: prevention (pinning, contract), provider-independent detection,
pre-speci ed evaluation, and tested response. No single layer should be considered
suf cient.
2. Expect version pinning or equivalent change control for higher-tier devices, and
condition regulatory latitude on it.
3. Require provider-independent detection (canaries, behavioural ngerprinting, traf c
monitoring, integration tests) and evidence, premarket, that it would detect representative
changes, with detection latency reported.
4. Require per-interaction version logging (model, prompt, retrieval, con guration) to allow
attribution.
5. Classify unannounced or new-version changes as material by default, and require rebenchmarking of the deployed system against the original authorised baseline, gating
elements rst, with response times scaled to tier.
6. Require a tested rollback and a validated fallback model or degraded mode, with prespeci ed interim controls and authority to use them.
7. Encourage contractual terms (notice, immutability, deprecation windows, incident
noti cation, evaluation access, documentation, cooperation) while recognising unequal

Date 18/10/2026 118 of 131 FDA-2026-N-7874

fl fi
fi fi fi fi fi fi fi fi fi
 bargaining power, and consider a standardised Foundation Model MAF and a minimum
content set as an aid.
8. Specify detection, classi cation and response as PCCP content, with model-family
eligibility, acceptance protocol, noti cation rules and exclusions, and reduce latitude where
controls are missing.
9. Support cross-sponsor detection signals through independent or consortium arrangements,
with routing to manufacturers and FDA that carries response duties (Question 21).
10. Keep manufacturer accountability unchanged, scale requirements by tier to avoid
burdening low-risk and small developers, and pilot detection and response requirements
before formalising them.

Question 25 - Would voluntary Foundation Model MAFs be practical for foundation model
developers to provide and to keep current, and what content might they include? Given that
participation would be voluntary and that model developers may have limited incentive to
disclose safety-relevant information, what would make such a program sufficiently useful for
premarket review? Are there alternative mechanisms CDRH should consider for obtaining
information about underlying foundation models?

1. Summary position

A voluntary Foundation Model MAF is practical as a supplement and unlikely to be suf cient as a
foundation for premarket review. It can reduce duplicated effort, give reviewers consistent
background on a model, and create a channel for change noti cation. It cannot establish the safety
of any device, and the paper says as much. Its usefulness depends on three things: content that is
speci c, structured and veri able (not marketing-grade model cards), an incentive structure that
rewards participation, and a requirement that sponsors still test the deployed system, so the
MAF informs the review but never substitutes for device-level evidence. We recommend a staged
program (a minimum content set, a keep-current obligation, and veri cation elements) and that
CDRH consider complementary mechanisms for obtaining information where developers decline to
participate. I describe the MAF program only as the paper does and have not veri ed current Device
Master File procedures.

2. Practicality for developers

Reasons it may be practical:

• Developers already produce model or system cards, safety evaluations and usage policies, so
part of the content exists.
• A single le referenced by many sponsors reduces repeated disclosure requests.
• Con dential handling (as the paper describes for MAFs) addresses part of the concern about
revealing proprietary information.
• Health is a commercially attractive sector, and regulatory clarity may matter to developers
selling into it.
Reasons it may be hard:

• Keeping current is costly. Models, safety tuning and serving stacks change frequently
(Question 24). A static le goes stale quickly and can mislead.
• Proprietary and competitive sensitivity. Training data provenance and architecture are
often closely held.
Date 18/10/2026 119 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
fi
fi fi
fi
 • Dual-use and security concerns. Detailed failure modes or safety mechanisms can aid
misuse.
• Many developers have no healthcare focus, and may see small bene t against disclosure
and compliance burden.
• Liability exposure. Statements to a regulator about limitations or failure modes may carry
legal risk, which I do not assess.
• Heterogeneity. Open-weight, API-hosted and ne-tuned models differ in what the developer
can know and say. A developer of an open-weight model may not know how downstream
parties deploy it.
• Layered supply chains. Many devices use a platform provider on top of a base model
developer. Who les, and what each knows, needs to be de ned.
My overall view is that practicality is moderate and uneven: plausible for large providers actively
seeking healthcare customers, less so for smaller or open-weight developers.

3. Possible content

The paper’s footnote lists candidate content. We suggest organising it into a tiered set, separating
what is descriptive from what is evidential from what is commitment.

Category Content Value to reviewers

Model family, version identi ers, release Enables attribution and
Identi cation and
date, what “same version” guarantees, detection of change (Question
versioning
relationship to aliases and endpoints 24)

Intended and Supported use cases, stated exclusions,
Context for scope assessment
supported use healthcare-speci c policies
Data sources by category, cutoff dates, Limited by what developers
Training and data treatment of medical content, licensing will disclose, but informs
provenance and exclusion practices, handling of contamination assessment
patient data (Question 10)
Determines applicable
Architecture and Model class, modalities, context length,
evaluation elements (Question
modality tool-use capability
17)
Results on healthcare-relevant
benchmarks, with subgroup Weak evidence alone (Question
Evaluation results breakdowns, methods, dates, versions, 10), useful with methods
and whether test items could have been disclosed
in training
Known failure modes in health contexts:
Characterized
confabulation, calibration, refusal and
behavior and Guides targeted testing
over-refusal behavior, sensitivity to
limitations
prompts, multilingual weaknesses
Built-in refusal behavior, content
policies, guardrails, system-layer lters, Needed to understand who
Safety systems
what the developer controls versus what controls what
customers can con gure
Red teaming and Methods, coverage, ndings categories,
Informs S.2 and A.1 testing
adversarial testing residual risks

Date 18/10/2026 120 of 131 FDA-2026-N-7874

fi fi fi fi fi fi fi fi
fi fi
 Release cadence, noti cation
commitments and lead times,
Change management deprecation policy, version immutability Central to Question 24
commitments, how silent changes are
handled
Process for notifying downstream users
Incident handling Supports postmarket response
of defects or safety-relevant ndings
Availability of logs, access for
Audit and logging investigation, ngerprint or version data Supports attribution
in responses
Availability of sandbox or pre-release
Evaluation access Enables pre-cutover regression
access for downstream evaluation
Data retention, use of customer data for Relevant to patient data
Security and privacy
training, security controls handling
Contact and Named responsible parties and
Practical response
accountability escalation routes

Two design points:

• Distinguish claims from veri ed facts. A le that mixes developer assertions with
independently checked results is hard to weigh. Each element should state its basis (selfreported, internally tested, independently veri ed).
• Separate stable from volatile content. Architecture and policies change slowly, while
evaluation results and behaviour change often, so they need different update obligations.
4. What would make the program suf ciently useful

4.1 Keep it current, with a clear rule. Require update on de ned triggers (new version, safetyrelevant behaviour change, deprecation, incident) and a periodic con rmation of continued
accuracy, with a visible “last veri ed” date and version mapping. Stale les should be agged to
referencing sponsors.

4.2 Make content structured and comparable. A standardised schema (potentially developed
through a standards body, Question 21) allows reviewers to compare les and sponsors to reference
them consistently, and reduces the effort of preparing and reviewing them.

4.3 Include veri able elements, not only assertions. Examples: results reproducible by a third
party on a provided sandbox, independent evaluation of the model on a shared healthcare
benchmark, attestation by an accountable of cer, or audit by an independent assessor. Veri cation is
the main difference between documentation and assurance.

4.4 Make it relevant to the deployed device. Base-model behaviour is not device behaviour, since
prompts, retrieval and guardrails change it. The le should be written to help sponsors design
device-level tests (which failure modes to probe, what the model’s guardrails cover), not to imply
safety.

4.5 De ne reviewer use. Give reviewers a standard way to use the le, such as a checklist linking
le content to evaluation elements (S.1 to A.1) and a rule for what a sponsor must show when a le
is absent or thin. Without that, a le may be read inconsistently.

Date 18/10/2026 121 of 131 FDA-2026-N-7874

fi fi fi fi fi fi
fi fi fi fi fi fi fi fi fi fi fi fi fl fi fi
fi
 4.6 Provide a minimum content threshold. A le lacking change-noti cation terms, version
identi ers or known limitations should not count as meaningful. This stops a minimal le from
conferring appearance of rigor.

4.7 Keep the independence of the review. Submission of a le must not imply authorisation of the
model or any reduction in the sponsor’s evidence burden, as the paper states. We suggest making
the default that a MAF affects review ef ciency, not evidentiary requirements, unless a speci c,
veri ed element justi es a targeted reduction (for example, a veri ed change-noti cation
commitment supporting a particular PCCP provision).

4.8 Give feedback loops. If post market monitoring reveals model-level defects (Questions 19 to
24), mechanisms should route ndings to the le holder and update the le, so that the program
accumulates knowledge.

4.9 Show sponsors the bene t. Sponsors choosing models with complete, current les should
bene t in review (faster, more predictable), and CDRH should be able to say how.

5. Incentives given voluntary participation

The question of limited incentive to disclose safety-relevant information is central. A voluntary
program tends to attract participants with favourable information. Possible responses:

Mechanism How it helps Concerns

Review ef ciency Sponsors prefer models with les, Needs actual, demonstrated bene t to
for sponsors creating market pull sponsors

A le with veri ed noti cation terms
Predictability in Must be conditional on veri ed
could support broader PCCP latitude for
change control commitments
downstream sponsors (Question 23)

Procurement and
Health systems and payers favor devices
institutional Depends on market adoption
built on documented models
preference

Recognition or Public listing of les and their
Could mislead if read as endorsement
listing completeness

Reducing One ling replaces many bespoke
Strongest practical incentive, if
repeated sponsor-by-sponsor requests, which
developers perceive it that way
requests developers are already receiving

Developer-side Disclosure to a con dential channel Legal and policy questions outside
safe harbor without public exposure my scope

Date 18/10/2026 122 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
 Differentiated Could be seen as pressure on
Sponsors using models without les
treatment of sponsors rather than developers, and
carry the burden of compensating
undocumented might disadvantage open-weight
evidence
models models

Importantly, voluntary participation shapes interpretation of absence. The program should state
that absence of a le is not a negative nding, while ensuring sponsors using models without one
provide evidence through other routes (Section 6). Otherwise sponsors using documented models
may be at a regulatory advantage unrelated to safety.

6. Alternative or complementary mechanisms for obtaining information

These are suggestions, and several rest on authorities and practicalities I have not assessed.

• Sponsor-held disclosure requirements. Require sponsors to submit what they know about
the model, obtained by contract, including version, provider statements, known limitations
and change terms, with a stated basis. Burden on sponsors, but it works regardless of
provider participation.
• Deployed-system testing as the primary route. The paper already focuses on evaluating
the nal device. Behavioural evidence gathered by the sponsor or third parties does not
depend on provider disclosure, and is the only information that is unavoidably available.
• Independent third-party evaluation of foundation models on healthcare-relevant
benchmarks and red teaming, held by an independent body (Question 16), producing
assessments not dependent on developer assertions. Concerns: cost, concentration, rapid
obsolescence, and the limits of base-model evaluation as a predictor of device behaviour.
• Standardised, public disclosure formats. Encourage or recognise standards for model
documentation developed by consensus bodies, so sponsors can cite public documents.
Lower con dentiality, but also lower detail.
• Information-sharing consortia among sponsors, health systems and developers, with
con dentiality terms, for behavioural surveillance and failure sharing (Questions 21 and 24).
• Supplier quali cation by sponsors. Treat the model provider as a critical supplier under
the sponsor’s quality system: assess, audit, document and monitor, as manufacturers do for
other components. This places responsibility on the manufacturer, consistent with
accountability (Question 21). I have not veri ed current supplier-control expectations.
• Behavioural characterisation requirements. Require sponsors to characterise the model’s
behaviour in the device’s context (calibration, refusal, subgroup performance, drift) and
report it, which compensates for missing provider documentation.
• Direct engagement or voluntary dialogue. CDRH could convene developers on
healthcare-relevant disclosures, pre-submission style, with outputs informing the schema.
• Post-incident information requests. De ned routes for obtaining information from
developers after a safety signal, with cooperation expected through sponsors’ contracts,
though FDA’s reach over non-manufacturer developers is a legal question outside my scope.
• Open-weight and open-evaluation routes. For open-weight models, sponsors and third
parties can inspect and test directly, which changes what documentation is needed.
• International and cross-sector alignment. Where developers already produce
documentation for other regulators or sectors, accept equivalent material to reduce burden,
subject to relevance, whose availability I have not assessed.
7. Equity and competition considerations

Date 18/10/2026 123 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
fi fi
 • Large developers may nd it easier to participate, and the program could advantage them
if sponsors prefer documented models. The effect on smaller and open-weight developers
should be considered.
• Do not make participation a de facto barrier, which would con ict with least burdensome
principles.
• Avoid concentration: if a few developers dominate healthcare use, shared defects create
correlated risk, a reason for the monitoring features in Questions 21 and 24.
• Treat con dentiality carefully, so that sponsors can use the le without seeing contents
when the holder authorises reference, which the paper describes, while still being able to
design tests. This creates an information asymmetry, since sponsors may not know what the
le says. A sponsor-facing summary or letter of authorisation with de ned shareable
elements could help.
8. Illustrative cases

Situation Role of the MAF Other mechanisms
Triage device on a hosted model Ef ciency in review;
Sponsor still runs full
with a complete, current le supports a model-family
benchmarking, trajectory testing
including change-noti cation PCCP provision if
and canaries
commitments commitments are veri ed
Sponsor-held disclosures, supplier
quali cation, more behavioral
Device on a model with no le No negative inference
characterization, narrower PCCP
latitude
File of limited relevance;
Device on an open-weight model sponsor is effectively the Sponsor documents training data,
ne-tuned by the sponsor model developer for the tuning and evaluation directly
tuned model
File holder noti ed; le
Defect found in a shared model Consortium sharing, post-incident
updated; sponsors reafter deployment information routes
evaluate
Provider revises safety tuning Stale le agged; canary Sponsor re-benchmarks (Question
silently detection by sponsor 24)

These are illustrative only and not a proposed classi cation.

9. Cautions

• A MAF is not evidence of device safety. The risk is that a le becomes a proxy for
assurance in reviewers’ minds or in the market.
• Self-reported content can mislead. Without veri cation, favourable summaries may
overstate performance, and omit unfavourable results.
• Stale les are worse than none if they create false con dence.
• Selection effects. Participants may differ systematically from non-participants.
• Disclosure of base-model evaluations can be gamed if benchmarks were optimised for, or
contaminated (Question 10).
• Do not let sponsors outsource responsibility to the le or the provider (Question 21).
• Avoid excessive con dentiality that blocks review use. If reviewers cannot discuss or
challenge content, its value falls.
• Beware of administrative load for CDRH to maintain and review les.
10. Limitations and open questions
Date 18/10/2026 124 of 131 FDA-2026-N-7874

fi fi
fi
fi
fi fl
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fl
fi
fi
fi fi
fi
fi
fi fi
 • I am not aware of evidence on developer willingness to participate or on whether such les
change review quality, and the assessments above are expectations. A pilot with volunteer
developers and sample submissions would test both.
• What minimum content is achievable for developers who control little of the deployment
chain is unclear.
• Whether veri cation can be provided at reasonable cost, and by whom, is unresolved
(Question 16).
• The legal protections and obligations for developers and the scope of CDRH’s authority to
require information from non-manufacturers are outside the paper’s scope and my own.
• How to treat ne-tuned and derivative models, and which party les, needs de nition.
• How much the program would actually reduce sponsor burden is untested.
11. Recommendations

1. Pursue voluntary Foundation Model MAFs as a supplement that improves review ef ciency
and change visibility, and state that they do not replace device-level evidence or imply
authorisation.
2. De ne a structured, standardised schema with a minimum content set (versioning,
supported use, known limitations, change management, incident handling, evaluation access,
audit and logging).
3. Require each element to state its basis (self-reported, internally tested, independently
veri ed), and include veri able elements such as reproducible results, independent
evaluation or attestation.
4. Require keep-current obligations with de ned update triggers, visible veri cation dates
and agging of stale les to referencing sponsors.
5. Write les to support device-level test design, with a reviewer checklist mapping content
to evaluation elements.
6. Create demonstrated bene ts for participation (review ef ciency, predictability,
conditional support for model-family PCCP provisions where veri ed), and state that
absence of a le is not a negative nding.
7. Provide complementary routes for undocumented models: sponsor-held disclosures,
supplier quali cation, behavioural characterisation requirements, independent third-party
evaluation and consortium sharing.
8. De ne feedback loops from post market ndings to the le holder and to affected sponsors.
9. Address equity and competition, including treatment of open-weight and smaller
developers and of layered platform and base-model arrangements.
10. Pilot the program with volunteer developers and measure whether les change review
ef ciency or quality before formalising it.

Question 26 - Are there additional considerations that inform the premarket and post-market
evaluation of agentic GenAI-enabled devices, beyond those applicable to nonagentic GenAIenabled devices? How should the elevated risk associated with autonomous multi-step action,
tool use, and reduced opportunity for human review be reflected in acceptance criteria and
oversight?

1. Summary position

Yes. Agentic devices add risks that are not merely larger versions of conversational risks. Errors
compound across steps, act through tools with real-world side effects, and often occur between
points of human review. We recommend that CDRH (a) tier agentic devices by the permissions
Date 18/10/2026 125 of 131 FDA-2026-N-7874

fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi fi
fi
fi
fl
fi
fi
fi
fi
and irreversibility of the actions they can take (the reachable maximum, Question 5, applied to
actions and not only to speech), (b) evaluate the whole action trajectory and the tool
environment, not only nal outputs, (c) set acceptance criteria as per-action and per-trajectory
failure bounds that tighten with irreversibility, with absolute oors for high-consequence actions,
(d) require engineered controls outside the model (permissions, checkpoints, rate limits, kill
switches), and (e) treat oversight as something to be demonstrated effective, not assumed from the
presence of a human in the loop. Much of what follows is anticipatory, since clinical agentic
deployments are early, and I have not veri ed how any speci c system behaves.

2. What is distinct about agentic devices

Feature Why it raises risk beyond non-agentic devices
A small early error can propagate; success probability decays
Multi-step planning
across steps
Actions have effects (orders, messages, device control, record
Tool and API use
changes), not only text
Autonomy between Fewer opportunities for a human to catch errors, and review may
checkpoints be retrospective
Behavior depends on external systems, whose outputs may be
Environment interaction
wrong, stale or hostile
Untrusted inputs as Retrieved documents, messages and tool outputs can carry injected
instructions instructions
Goal misgeneralization and An agent may satisfy a stated goal by an unintended route, such as
unsafe shortcuts altering a record to meet a metric
Persistent state and memory Errors and manipulated context can persist across sessions
Evaluation space is larger, and drift within a long task is harder to
Long horizons
see
Agents delegating to agents can obscure responsibility and amplify
Multi-agent interaction
error
Some actions (a sent message, an administered dose, a deleted
Irreversibility
record) cannot be undone
Escalation of permissions Agents may acquire or request access beyond what the task needs
Intermediate reasoning may be unavailable or unfaithful, reducing
Opaque rationale
detectability (Question 1)

The paper notes that many agentic uses (documentation, scheduling, outreach) may not be device
functions at all. The comments below apply where an agent’s functions meet the device de nition,
for example where its actions control another medical device or direct clinical orders.

3. Premarket considerations beyond non-agentic devices

3.1 Characterise the action space. The intended use should list the tools, permissions, data access,
and action types, and state which are irreversible, which are patient-affecting, and which require
human approval. The reachable maximum is the most consequential action the agent can
foreseeably take, including through misuse of permitted tools.

3.2 Evaluate in realistic environments. Test the agent against simulated or sandboxed clinical
environments (mock EHR, order systems, device interfaces) that reproduce real constraints: API

Date 18/10/2026 126 of 131 FDA-2026-N-7874

fi
fl
fi
fi
fi
 errors, latency, partial data, con icting records, and unusual states. Where the environment is a
simulation, its delity becomes part of the evidence chain (Question 17).

3.3 Extend element A.1 with speci c competencies. The paper’s A.1 names planning, tool use,
human-oversight compliance, failure handling and injection resistance. We suggest also testing:

• Plan validity and sequencing: correct ordering, preconditions checked before acting.
• Task decomposition errors: omitted or duplicated steps.
• Recognition of erroneous tool output: does it notice implausible or contradictory results
rather than proceeding?
• Stopping and abstention: does it halt, ask, or escalate when uncertain or when a step is out
of scope?
• Recovery: behaviour after a failed step, including avoiding unsafe retries or partial
completion that leaves a patient in an inconsistent state.
• Permission discipline: not requesting, exploiting or inferring access beyond the task.
• Side-effect awareness: avoiding collateral changes (altering unrelated orders or records).
• Goal delity: achieving the clinical objective, not a proxy (satisfying a quality metric by
altering documentation).
• Honest reporting: accurately describing what it did and did not do, including failures.
• Memory integrity: resistance to poisoned or stale persistent context.
• Multi-agent behaviour: handoff correctness and no unauthorised delegation.
3.4 Adversarial and injection testing across all inputs. Prompt injection arrives through user text,
retrieved documents, tool outputs, messages and images. Testing should cover indirect injection
and tool-channel manipulation, and attempts to induce privilege escalation or data ex ltration
(Question 17, Section 3.4).

3.5 Trajectory-level metrics. Report success and failure by trajectory, not only per step, because
per-step accuracy overstates end-to-end reliability. As a simple illustration of compounding: if each
step is independently 99% reliable, a 50-step task succeeds about 60% of the time (0.99^50 ≈
0.605), though real errors are correlated and steps differ in consequence. Sponsors should report
failure by type and severity (harmless inef ciency, recoverable error, harmful action, irreversible
harm), not an aggregate success rate.

3.6 Variability and long-horizon behaviour. Non-determinism produces different plans on the
same task, so repeat runs matter, with any-run failure rates for safety-critical actions (Question 12).
Test long tasks and long context for degradation.

3.7 Test the controls, not only the model. Permissions, approval gates, rate limits and kill switches
are the main protective layer. Each should be tested for effectiveness, including under adversarial
pressure, and independent of the model’s cooperation.

3.8 Staged autonomy. Con rmation can follow a ladder: simulation, shadow mode (agent
proposes, humans act), supervised execution with approval of each action, supervised with sampled
review, then limited autonomy within a narrow envelope (Question 11). Each step has pre-speci ed
progression and stopping criteria, and autonomy for high-consequence actions may not be reachable
on available evidence.

3.9 Con rmation evidence. For autonomous or high-consequence action, the non-prospective
methods listed in the paper are insuf cient alone (Question 11), because agentic failure arises from
the interaction of agent, tools and work ow. Prospective evidence, or at minimum carefully staged
real-use evidence with enhanced oversight, is likely needed at higher tiers.

Date 18/10/2026 127 of 131 FDA-2026-N-7874

fi
fi
fi
fl
fi fi
fl
fi
fi
fi
fi
 4. Re ecting elevated risk in acceptance criteria

4.1 Tier by action, not by output. Placement on the activity axis (Question 1) should re ect the
most consequential, least reversible action available, with modi ers for detectability, time
pressure, and reversibility. Autonomous multi-step action with low reversibility sits at the highest
tier. Granting broad permissions “in case needed” raises the tier even if the agent seldom uses them.

4.2 Criteria by action class. Rather than one threshold, de ne criteria per class of action:

Action class Illustrative criterion type
Read-only, reversible, low Standard element thresholds; trajectory success and error
consequence categorization
Write actions, reversible,
Per-action error bound; veri ed detection and undo; sampled review
with veri cation

Patient-affecting, reversible
Stricter bound; mandatory approval or delay window; tested reversal
within a window

Irreversible or high- Absolute oor on failure with upper con dence bound; human
consequence (dosing, order approval before execution unless autonomy is separately and
sets, device control) rigorously justi ed; any-run criterion
Actions on other medical Evidence appropriate to the controlled device, plus interface-level
devices validation

The numeric values are placeholders for stakeholder and consensus work, and I propose none.

4.3 Per-action and per-trajectory bounds. Set acceptance on harmful-action rate per action and
per task, with upper con dence bounds. For rare severe events the sample-size problem is acute
(Question 12), which is one reason irreversible actions should rest on engineered controls and
approval gates rather than on bounding the agent’s own error rate.

4.4 Gating behaviours that must never fail. Pre-specify zero-tolerance categories (executing an
action outside the permission set, bypassing an approval checkpoint, acting on injected instructions,
falsely reporting completion) tested adversarially, with failure in any gating category blocking
authorisation at that autonomy level.

4.5 Abstention and escalation are performance. Credit appropriate stopping and handoff, and
measure over-stopping, which makes the agent useless and may push users toward workarounds
(Question 6 applies to the escalation decision: under-escalation versus over-escalation).

4.6 Compare against the realistic counterfactual (Question 15): the unaided clinician or humanstaffed work ow, including its own error rate, while keeping absolute oors for severe actions.

4.7 Accept reduced autonomy as a legitimate outcome. If evidence supports only supervised
operation, authorisation should be at that level. The envelope (Question 5) should state the
maximum autonomy level validated.

5. Oversight: reduced human review

5.1 Do not assume a human in the loop is protective. Oversight is effective only if the human can
detect errors in the time and form available. Approval fatigue, large action batches, opaque rationale
Date 18/10/2026 128 of 131 FDA-2026-N-7874

fl
fi
fl
fi
fi
fi
fi
fi
fl
fl
fi
fl
 and automation bias degrade it (Question 14). Effectiveness should be measured, for example by
seeding known-bad actions and measuring catch rates, before supervision is credited toward a lower
tier (Question 1).

5.2 Design oversight for real review. Present proposed actions with their rationale, evidence and
consequences in reviewable form, group them sensibly, and place approval gates before
irreversible and high-consequence steps, not only at the end. Avoid designs where the human
approves a long plan they cannot evaluate.

5.3 Engineered controls independent of the model.

• Least-privilege permissions, scoped per task, time-limited, with no standing broad access.
• Allow-lists of tools and parameters, and hard limits (dose ranges, order types) enforced
outside the model (Question 5).
• Approval gates for de ned action classes.
• Rate and volume limits to bound the effect of a runaway loop.
• Delay or undo windows for actions that can be reversed within a period.
• Kill switch and containment, tested, with de ned authority and time to stop.
• Sandboxing and segmentation between the agent and systems it need not touch.
• Treating all tool outputs and retrieved content as untrusted, with controls on instructionfollowing from those channels.
5.4 Audit and traceability. Complete, tamper-resistant logs of plans, tool calls, parameters,
outputs, approvals and state changes, suf cient to reconstruct any action. This also enables postmarket review and root-cause analysis. Reasoning traces may be informative but may not faithfully
re ect the basis for actions, so logs of actions and observations should be primary.

5.5 Accountability. The manufacturer remains accountable for the agent’s actions within authorised
scope (Question 21). Institutions control local permissions and integrations, and the deployment
agreement should state which permissions may be granted locally. Local expansion of permissions
should be treated as a change that can alter the reachable maximum (Question 22).

6. Post market evaluation beyond non-agentic devices

• Action-level monitoring, not only output review: rates of each action type, approval and
override rates, reversed actions, tool errors, and out-of-envelope attempts. Anomalous action
patterns are an early signal.
• Sample-based review of trajectories with enrichment for high-consequence actions and
unusual paths, plus seeded errors to measure reviewer detection (Question 19).
• Canary tasks in a sandbox mirrored to production, run continuously, to detect behaviour
change after model, tool or environment updates (Question 24).
• Environment and integration drift, since changes to connected systems (EHR updates,
API changes) can alter agent behaviour without any change to the agent. Treat connectedsystem changes as triggers (Question 19).
• Permission audit: periodic review that granted permissions still match the task, since
access tends to accumulate.
• Incident response with fast containment, and pre-speci ed thresholds for suspension of
autonomy, with graded reinstatement.
• Staged re-expansion of autonomy after any serious event.
• Multi-agent and cross-system effects, including interaction with other agents the sponsor
does not control.
• Machine-based supervision of agents carries the correlated-error risks in Question 20, and
is a triage layer only, with hard controls remaining model-independent.
Date 18/10/2026 129 of 131 FDA-2026-N-7874

fi
fi
fi
fl fi
 • Reduced reliance on post market substitution: for autonomous, irreversible or timecritical agentic functions, post-market monitoring should be additional and not a substitute
for premarket evidence (Question 18).
7. Change control for agents

Agentic systems change on more dimensions: model version, tools and tool de nitions,
permissions, orchestration logic, memory, and connected systems. Following Questions 22 to 24:

• Adding a tool, widening permissions or increasing autonomy is a change in reachable
maximum and requires FDA review, not a routine PCCP change.
• Model updates re-test trajectory behaviour and gating categories, since new versions may
change planning style, tool-use patterns or injection resistance even if single-turn behaviour
improves.
• Tool de nition or interface changes require integration and trajectory regression.
8. Illustrative cases

Agent function Principal risk Suggested emphasis
Agent drafts and Approval fatigue, Measure error catch with seeded errors; gates
proposes orders; clinician automation bias before orders; proposal quality and rationale
approves
Agent each infusion
adjusts Irreversible patient display
Hard limits outside the model, tested kill switch,
settings within a harm, device interface validation, staged autonomy, tight pervalidated range
Autonomous post- interface
Under-escalation, Paired bounds
action escalation reporting (Question 6), injection
discharge outreach with injection via patient tests, sampled review, escalation checkpoints
escalation
Agent messages
reconciles records Silent data Side-effect and permission testing, reversibleStroke systems
across corruption, side write controls, audit logs
work ow agent Time-critical, high- Highest tier; approval gate unless autonomy
initiating order set consequence rigorously justi ed; prospective evidence; narrow
Scheduling and Likely not a device envelope
Outside device oversight if it meets no device
documentation agent function de nition, per the paper
These are illustrative only and not a proposed classi cation.

9. Cautions

• Do not evaluate steps in isolation. Per-step accuracy understates trajectory failure.
• Do not rely on the agent’s own reports of what it did. Verify against logs and environment
state.
• A sandbox is not production. Real environments contain messiness the simulation may
lack.
• Do not let permissions creep. Broad access justi ed as exibility enlarges the reachable
maximum.
• Do not treat a human approval click as oversight. Effectiveness requires evidence.
• Avoid false assurance from model-side safety. Controls that depend on the model’s
compliance fail when it is manipulated.
• Beware of fast-moving capability. Elements tied to current techniques will date, so criteria
should be stated as behaviours and controls (Question 17).
• Avoid over-broad scope. Many agentic functions are not devices and should not be swept
in by default, consistent with the paper and least burdensome principles.
• Do not demand autonomy evidence that cannot be obtained. Where rare severe events
cannot be bounded, the answer is to restrict autonomy and preserve gates.
10. Limitations and open questions
Date 18/10/2026 130 of 131 FDA-2026-N-7874

fi
fl
fi
fi
fi
fl
fi
fi
 • Clinical agentic deployment is early and I am not aware of empirical evidence on failure
rates, oversight effectiveness or monitoring performance. The proposals above are design
hypotheses.
• Sandbox delity and how to validate simulated clinical environments is unresolved.
• No agreed way to set trajectory-level acceptance bounds or to aggregate heterogeneous
action consequences.
• How to evaluate multi-agent systems, in which behaviour depends on other agents, is not
well developed.
• The relationship between agent action control and existing requirements for connected
devices and cybersecurity, which I have not reviewed, needs clari cation.
• Where the line falls between a device function and an “other function” for agentic systems
that combine both is a scoping question the paper acknowledges, and I do not resolve it.
• Allocation of responsibility among manufacturer, institution and tool providers is outside the
paper’s scope and mine.
11. Recommendations

1. Tier agentic devices by the most consequential and least reversible action reachable,
including through permitted tools, and treat broad permissions as raising the tier.
2. Extend A.1 to cover plan validity, tool-output skepticism, stopping and abstention,
recovery, permission discipline, side effects, goal delity, honest reporting, memory
integrity and multi-agent handoffs.
3. Evaluate in realistic sandboxed environments, report trajectory-level outcomes by
severity, include any-run criteria, and require delity evidence for simulators.
4. Test indirect injection and privilege escalation across all input channels, and set zerotolerance gating categories (out-of-permission action, bypassed checkpoints, acting on
injected instructions, false completion reports).
5. Set acceptance criteria by action class, with per-action and per-trajectory bounds that
tighten with irreversibility, and absolute oors and approval gates for high-consequence
actions.
6. Require engineered controls independent of the model (least privilege, allow-lists,
approval gates, rate limits, delay and undo windows, tested kill switch, sandboxing), each
tested for effectiveness.
7. Credit human oversight only after demonstrating that reviewers catch seeded errors
under realistic conditions, and design approval points before irreversible steps.
8. Use staged autonomy with pre-speci ed progression, stopping and reinstatement criteria,
and accept supervised operation as a legitimate authorised level.
9. Require complete action audit logs and action-level post-market monitoring, including
permission audits, environment-drift triggers and trajectory review.
10. Treat tool additions, permission expansion and autonomy increases as changes in
reachable maximum requiring FDA review, and re-test trajectories after model or integration
changes.
11. Pilot these expectations on real agentic prototypes before formalising them.

Date 18/10/2026 131 of 131 FDA-2026-N-7874

fi
fi
fi
fl
fi
fi