Jaden Feddock

I am an active CTO building generative AI systems inside an AMC-backed metabolic and wellness health company where a licensed provider signs every prescription and treatment plan. These comments address questions 1, 6, 10, 16, 18 and 26, and make three asks. First, add a risk dimension for how tightly a model’s output is constrained and how deterministic the path is from that output to a clinical artifact, because the current two axes describe what a model says rather than what it is able to cause. Second, add a standardized benchmarking element for what a device asserts when a model call fails, since a reassuring default produces a false negative no benchmark can catch. Third, treat benchmarks as perishable, with expiration dates and a defined pathway to retire one that has stopped distinguishing good systems from bad, because a benchmark’s validity decays in proportion to how much it matters. I also argue that constraint should be a regulatory pathway rather than a ceiling, with protocol-backed deterministic decisions as the architecture worth building toward. Full comments attached.

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

Submitted by: Jaden Feddock

Submitted: October 19, 2026

I build generative AI systems inside an AMC-backed metabolic and preventive healthcare practice. We
prescribe and manage ongoing treatment, facilitate and run diagnostic testing, and connect patient
wearable and medical devices. A licensed provider reviews and signs every prescription and treatment
plan. The engineering problem in question, how you constrain a model enough to put it near patient
care, is central to how we do business.

I am commenting as the CTO of this company. These opinions are my own and do not represent my
company's public views. What follows are general design and technical concepts, not a description of
any product or company.

Three asks, in order of how much I think they matter:

1. Add a specific risk dimension for how tightly the model's output is constrained before it reaches
a patient or a chart.
2. Add a standardized benchmarking element for what the device says when the model fails.
3. Treat benchmarks as perishable and directional, with expiration dates, consistent reviews by a
group of professionals, and a pathway to retire one that has stopped providing meaningful
benefit (details below).
I am specifically answering questions 1, 6, 10, 16, 18 and 26.

1. The framework measures what the model says, not what it can cause
Neither axis describes the machinery that carries the output into the world, and in front of patients and
clinicians. Two systems can produce the same clinical claim with very different risk.

In the first, a model writes free text into a field that becomes part of a clinical order. It can produce
anything, so a wrong number, a wrong unit or a misplaced decimal all have the potential to reach the
patient.

In the second, the model picks one of three or four values from a fixed list. Ordinary code then maps
that choice onto options a qualified human wrote down in advance. The model never writes a number.
The worst thing it can do is pick the wrong item from a short list a clinician already approved. In many
failure cases of this sort, a non-parseable result or a non-decision routes to human review or a re-run.
A third shape works the same way. Instead of letting a model describe a product or a therapy in its own
words, it selects from a library of statements that a clinician and counsel already cleared. If the library is
empty, the device says nothing. The model chooses among approved claims and cannot author one.

Under the framework as drafted, all of these land in roughly the same cell. In practice you can
enumerate everything the second and third can do, and you cannot do that for the first. This is a major
risk and it should be named explicitly in any framework for GenAI-enabled devices.

So I would ask to add a dimension: is the model's output a bounded, enumerable set, and is the path
from that output to a clinical artifact deterministic and reviewable? How are inevitable failures tested
and scored for risk?

Question 1 already asks about reversibility, downstream safeguards and traceability, and I support
those. They describe the process built around the model. What I am describing is a property of the
machine itself, and it still holds on a path where nobody is watching and no safeguard fires. It is also the
cheapest item on that list for a reviewer to confirm, because you check it by reading the schema and the
mapping rather than by running a test and trusting the result.

Benchmark scores go stale as soon as people optimize against them, while a bounded output space
holds even when the model provider ships an update you did not ask for, and a sponsor cannot study for
it in advance.

2. Constraint should be a pathway, not a ceiling (questions 18 and 26)
Question 26 asks how the elevated risk of autonomous action should shape acceptance criteria. The risk
that matters is not whether a system acts on its own. It is whether the decision behind the action rests
on a language model's judgment. Those are separable, and separating them is the most useful thing a
framework can encourage.

Protocol-based medicine is well established and uncontroversial. Order sets, titration ladders, screening
algorithms and escalation criteria all encode clinical judgment once so it can be applied consistently, and
the evidence supports them: the 2025 Cochrane review covering 58 studies and 24,841 patients found
that stand-alone clinical pathways likely reduce in-hospital complications (10% versus 17%, OR 0.57) and
length of stay, both at moderate certainty, while effects on mortality and readmission remain uncertain
(Rotter et al., 2025). What has limited protocols is the input side. A protocol can only branch on what
the software is able to read, and until recently that meant structured fields plus whatever could be
matched by keyword. Keyword matching was possible and it was brittle. You could look for "worse" or
"worsening" and catch some cases, but the list never finishes, negation inverts it, and the phrasing that
matters most is often indirect. A patient writing "I've been pretty rough in the mornings but it's easing
up" is reporting a side effect that is improving, in a sentence containing no keyword for a side effect and
none for improvement. Building a protocol on inputs like that meant accepting that the gate would
misfire in ways nobody could enumerate in advance.

That input problem is what generative models solve. They turn narrative, free text and other qualitative
data into the structured inputs a protocol needs. The pathways can get more complex and more
clinically useful while the decision itself stays deterministic, versioned and auditable line by line.
The architecture that follows is a deterministic rules engine whose rules are refined over time, with
these models helping build them and doing the distillation at the input edge. A system built that way can
take real action for a provider without the action ever resting on a language model's judgment. It also
inherits every property in section 1, because the model's output space is bounded by construction. This
is the configuration I would most like to see a regulatory pathway for, and it is where I think the field
should be heading.

This also answers the most common objection to generative systems in clinical settings, which is that
you cannot inspect the model's reasoning and therefore cannot trust its contribution. Clinical
accountability has never rested on mechanistic inspection. It rests on a record: what information was
available, what determination was made, and what reasoning was given for it. When an outcome is
reviewed, what gets examined is the inputs, the output, and whether the determination was defensible
given what was known at the time.

A system built this way produces that record in full. Every input the model saw can be captured, every
structured determination stored with the rationale it gave, and the rules that acted on those inputs are
versioned, so a reviewer can reconstruct not only what was decided but which rule decided it and what
that rule said on that date. Requiring more than this, in the form of interpretability of model internals,
would hold these systems to a standard that no clinical decision-maker is held to.

At the conservative end of the same spectrum sits a configuration that deserves a lighter path today.
Consider a system where the model's only available action is to hand a case to a human, and it cannot
approve anything on its own. Work still moves forward without a person looking at it, which resembles
the autonomy the paper is worried about, but the authorization comes from somewhere else: a
clinician's earlier decision, plus ordinary deterministic checks. The model sits beside those checks and is
limited to pulling a case out of the automated path.

That arrangement changes the failure modes in ways that are easy to verify:

• Breaking it produces more human review. If the model is down, slow, or returns garbage, there
is no verdict, and no verdict sends the case to a person.
• Prompt injection gains an attacker nothing. The best outcome for someone manipulating the
input is that a clinician looks at the case.
• A confabulation cannot widen permission. The model can invent a worry that wastes a
clinician's time. It cannot invent approval.
I would ask CDRH to place a model configured that way lower on the activity axis than its words suggest.
Writing "a clinician should see this" carries different risk depending on whether the system could instead
have written an order.

So I would ask CDRH not to design a framework whose only comfortable configuration is a model that
cannot act. A fixed ceiling on autonomy would freeze the field at today's architecture and penalize the
sponsors doing the harder engineering. A better approach is a pathway where a sponsor earns a wider
action space by demonstrating two things: that the generative layer's contribution is bounded extraction
rather than clinical judgment, and that the deterministic layer making the decision has been validated
against accumulated real-world cases with clinician review. The decision record above makes that
demonstration possible, and it accumulates from a system's first day in deployment. How should a
sponsor demonstrate that transition, and what evidence would CDRH want to see before widening what
a system is permitted to do on its own?
The same structure answers question 18. When every failure mode ends in a human looking at the case,
the remaining uncertainty is how often people get pulled in unnecessarily, which is a cost question that
postmarket data answers. As the sponsor asks for a wider action space, the evidentiary bar rises with it,
measured against the accumulated record of what the system actually did.

3. What the device says when the model fails should be a standardized benchmarking
element
Appendix A covers what the device says when it is working. It does not cover what the device says when
the model call times out, errors, or returns something unparseable.

That gap is where I have seen the most dangerous behavior. A fallback that returns nothing is safe, while
one that returns a reassuring default has the potential to cause real harm. Reassuring defaults are easy
to write by accident, because the natural placeholder for a review step is a clean one. A device that tells
a clinician "reviewed, nothing flagged" when in fact nothing ran has produced a false negative that no
benchmark will catch, because the model was never called.

There is a related failure that postmarket monitoring should look for. A protection can exist in the code,
pass every review, and be switched off in production by a configuration flag. It will not show up in
benchmarking, because benchmarking runs the code. It shows up only if someone checks the running
configuration.

Two things would help, and both are cheap:

• Add a standardized element under Safety for failure-mode behavior: what the device asserts,
displays, or suppresses when a model call fails, with the explicit expectation that a failure never
produces an affirmative all-clear.
• Expect sponsors to report which safety behaviors are configuration-gated, and what the
production values are, rather than only what the code can do.
A workable disclosure would state the failure behavior for each model call on a clinical path, and would
treat a changed production flag on a safety behavior as a reportable modification rather than a
configuration detail.

4. Make sponsors declare which direction their escalation design leans (question 6)
The two directions are not commensurable and I would not force them into one number. I would ask
that the sponsor state which way the design leans and defend it, the same way acceptance criteria are
prespecified.

Take escalation detection in a patient chat, where a cheap deterministic layer catches unambiguous
statements and a narrow classifier runs only when a watchlist term appears, answering one question.

Three decisions follow from taking the asymmetry seriously:
 • Ambiguous should escalate. Where the cost of over-escalating is a supportive message and a
phone number, both "yes" and "unclear" should escalate.
• A classifier outage should not escalate everything. A safety layer that fails into blocking every
conversation takes the product away from every patient using it, including the ones in trouble,
at the moment you know least.
• The cheap layer gates the expensive one. Most inputs never reach the classifier, so rules a
person can read govern most of the behavior.
The right trade varies by context, and a crisis line and a dermatology referral should not land in the same
place. What should hold across both is that the sponsor states the direction, states the reasoning, and
writes it down before testing, so that a reviewer can tell a deliberate clinical judgment from an accident
of implementation.

5. Benchmarks will stop working, and the better the framework the faster it happens
(question 10)
Question 10 names contamination, saturation and representativeness, which all read as matters of data
hygiene. The underlying problem is structural, and it gets worse the more the benchmark matters. The
general form of it was stated well before any of this: when a measure becomes a target, it ceases to be a
good measure (Strathern, 1997, p. 308).

The clinician analogy breaks at the point it is being used. Board exams work for people because a
person cannot absorb the whole domain, so performance on a sample tells you about something
general underneath. A student studying for boards is optimizing too, but human learning is bounded in
ways that force the optimization to generalize. Learning medicine is the cheapest way for a person to
pass.

A model has no such limit, because training optimizes against whatever you measure and fitting the
measured distribution is far cheaper than acquiring the ability the measurement stood for. There is no
separate competence the test samples, so the test substantially defines what gets built. The same score
means two different things depending on who took it.

Repeatability is a virtue in bench testing and a problem here. Section V.B.2 says test methods and
acceptance criteria should be prespecified, consistent with non-clinical bench testing. That is right for a
catheter, whose tensile strength does not change because the manufacturer knows the threshold. For a
model, a fixed and published test with a known acceptance criterion is exactly the thing that gets fit.
Prespecification stops a sponsor from moving the goalposts after seeing results. It does nothing about a
sponsor building toward goalposts published in advance.

FDA cannot run the usual fix. What preserves a benchmark is secrecy and rotation, and neither is
available here. Guidance and qualified tools are published by design. Sponsors have to know what they
are being measured against, and under this paper's approach they often build the benchmark
themselves. Every path leaks, and most of them leak for reasons nobody should want changed.
A benchmark nobody uses keeps working for years. One that becomes the standard gate, gets qualified
as a development tool, and has every sponsor in the category building toward it will saturate quickly, so
the more successful the framework is the faster its instruments decay.

A saturated benchmark is worse than no benchmark. It still produces a number, and reviewers and
clinicians will read that number as assurance it no longer provides. Visible uncertainty can be managed.
A number with a regulatory stamp that has quietly stopped measuring anything cannot, and it is hard to
undo once it is in the record. Every sponsor will also spend real money on whatever the gate measures,
and that money comes out of clinical confirmation, monitoring, and the architectural work that actually
bounds what a model can do.

The frontier AI labs ran this experiment in public over the last few years. Benchmarks that meant
something when introduced were saturated within a few release cycles of becoming the standard
scoreboard, and nobody in that field now treats headline scores as strong evidence about deployed
behavior. The contamination problem underneath it is documented well enough that researchers have
called for measuring it per benchmark rather than assuming it away (Sainz et al., 2023). All of that
happened with no regulator making any of them mandatory. The paper's own footnote on performance
assessment in healthcare language model applications (Garcia et al., 2026) points at the same difficulty.

Underlying models also change on a cadence the sponsor does not set, which bears on question 24,
because a benchmark result describes a model version rather than a device. Any qualified benchmark
should therefore carry an expectation of re-running on a model change, not only on a device change.

Contamination is also unfalsifiable for most sponsors. Most devices will be built on foundation models
the sponsor did not train and cannot inspect. Asked whether benchmark items were in the training data,
we cannot answer honestly either way. We have no access to the corpus. A clean-provenance
attestation from that kind of sponsor describes what the sponsor did, which is not the question. This is a
stronger argument for the Foundation Model Master File in question 25 than the ones the paper gives,
since training data provenance is something only the model developer can speak to.

So I would ask for four things:

• Make clinical confirmation the primary evidence rather than the confirmation step. Real-world
inputs cannot be optimized against in advance because they did not exist when the model was
built.
• Prefer consistency testing over accuracy on fixed items. Whether the device gives the same
safety-critical answer across rephrasings, reorderings and literacy levels is much harder to fit
than a score. Element R.1 already points here.
• Build benchmark items after the model's training cutoff, or regenerate them per submission,
rather than drawing from a standing bank.
• Put expiration dates on qualified benchmarks, with consistent review by a standing group of
qualified professionals, and a defined pathway to retire an instrument once it stops telling good
systems from bad ones. A benchmark that cannot be retired will eventually certify everything.
On that last point, who should sit on that review group, and how often should a qualified benchmark be
re-examined? I would rather see a short, scheduled review by practitioners who build and deploy these
systems than a longer one that happens only when something has already gone wrong.
6. Keep the cost of proving safety from becoming the barrier (question 16)
If sponsor-built benchmarks are suspect, the obvious move is to route evaluation through accredited
third parties. The question worth asking first is what that does to the shape of the field.

Accredited laboratories and purchased access to held-back datasets are a line item for a large
manufacturer and a build-or-not decision for a small one. Set the cost high enough and the
organizations able to put clinical AI in front of patients narrow to the largest device manufacturers and
the handful of companies that train frontier models. That is a poor outcome for patients regardless of
how well-run those organizations are, because it concentrates judgment about clinical AI design in a
small number of places and removes the people closest to specific clinical workflows from the field
entirely.

Independence has real value and cost alone is not a regulatory argument. Some functions warrant
independent adjudication, and I would not argue otherwise for autonomous diagnosis or anything
running without a clinician. A few choices would preserve both rigor and entry:

• Scale third-party involvement to the risk tier. A gating function whose only action is escalation
should not cost what an autonomous diagnostic costs to evaluate.
• Keep sponsor-built benchmarks admissible, with disclosure. A disclosed sponsor benchmark
with a written validity argument can be better evidence than an undisclosed third-party one.
• Fund held-back datasets as shared infrastructure. Paid access accelerates the saturation
problem and sorts sponsors by balance sheet.
• Watch who staffs the accreditation bodies. If they come from the largest manufacturers, the
standards will encode how those manufacturers already build, and that will not look like an
incumbency rule from the inside.
The constrained architectures in section 1 tend to come from teams that cannot afford to validate an
unconstrained system, which makes affordability of evaluation a safety variable rather than only an
economic one. The same dynamic governs who helps build the framework. Responding to a docket,
attending a workshop or sitting on a standards body is time that large manufacturers staff as a function
and small teams take directly out of engineering. The predictable result is that the agency hears most
from organizations whose core competency is navigating regulation, and least from the people making
the architectural decisions the regulation will govern. I would ask CDRH to build participation paths that
account for that: short structured feedback forms, office hours, or small technical sessions cost a
working engineer far less than a formal workshop, and they would surface design patterns this process
cannot currently see.

Closing
The competency direction is right, and my criticism in section 5 is about weighting rather than the whole
approach.
My main ask is the one in section 1. Make room in the risk framework for how tightly the model's output
is constrained and how direct the path is from that output to something clinical. That is the question a
reviewer can check easily and a manufacturer can build toward, and it is about what the model was able
to cause downstream of the language it generates.

I would like to stay involved as this develops. If CDRH convenes a workshop, a Digital Health Advisory
Committee session, or a technical working group on GenAI evaluation, I will do everything in my power
to make time for it. I am also glad to contribute worked examples of the patterns in sections 1 through
3, failure cases included, in whatever form is useful. Most of what I know about how these systems fail
came from building them and then watching them behave badly, and that evidence is difficult to obtain
from outside a deployment.

My contact information is in the submitter fields.

Jaden Feddock

Chief Technology Officer

Crimson Performance Health Inc.

Submitted in my individual capacity. These comments do not represent the views of my employer.

References
Garcia V, Sidulova M, Badano A. Performance Assessment Strategies for Language Model Applications in
Healthcare. Artificial Intelligence in the Life Sciences. 2026;9. doi:10.1016/j.ailsci.2026.100162

Rotter T, Kinsman L, Alsius A, et al. Clinical pathways for secondary care and the effects on professional
practice, patient outcomes, length of stay and hospital costs. Cochrane Database of Systematic Reviews.
2025. PMID: 40365866.

Sainz O, Campos J, García-Ferrero I, Etxaniz J, Lopez de Lacalle O, Agirre E. NLP Evaluation in Trouble: On
the Need to Measure LLM Data Contamination for each Benchmark. Findings of the Association for
Computational Linguistics: EMNLP 2023. 2023:10776-10787.

Strathern M. "Improving ratings": audit in the British University system. European Review.
1997;5(3):305-321.