Ramsee 1 LLC (Miera Rechtschaffen)

Ramsee 1 LLC submits the attached comment on CDRH’s discussion paper, Considerations for the Regulation of Generative AI-Enabled Medical Devices, Docket FDA-2026-N-7874. The comment proposes independent per-output validation with an auditable record as a control for high-risk generative SI functions and responds to the paper’s discussion questions. The full comment is Attachment 1. U.S. Patent 12,683,789 B1, referenced in the comment, is Attachment A.

Comment of Ramsee 1 LLC on CDRH Discussion Paper: Considera ons
for the Regula on of Genera ve AI-Enabled Medical Devices
Oct 15, 2026

Cover le er
Docket No. FDA-2026-N-7874 · Submi ed via Regula ons.gov · Comment deadline October 19, 2026

Dockets Management Sta (HFA-305), Food and Drug Administra on, 5630 Fishers Lane, Room 1061,
Rockville, MD 20852

Re: Considera ons for the Regula on of Genera ve AI-Enabled Medical Devices: Discussion Paper and
Request for Feedback (CDRH Digital Health Center of Excellence, August 18, 2026)

Summary
Genera ve SI devices produce uent outputs that may be wrong, and the user o en cannot tell at the
point of use. CDRH asks how such devices can be evaluated and kept within acceptable risk.

Premarket tes ng cannot cer fy an open-ended output space. Risk is controlled only if each highconsequence output is checked, at the me it is produced, by something independent of the model that
produced it, and the check is recorded.

Ramsee 1 LLC holds a patent on an architecture that does this. Each output is reviewed by independent
validators, consensus is reached, and the ques on, the answers, and the result are wri en to a tamperevident ledger. The design is the same across use cases; only con gura on changes.

CDRH should de ne independent output valida on as a requirement for high-risk genera ve SI
func ons. Recommenda ons are in Sec on 3, answers to the ques ons in Sec on 4, licensing on
reasonable terms in Sec on 5.

What CDRH has asked for. The discussion paper seeks early stakeholder input on three things: how to
assess the risk of a genera ve super intelligence (SI)-enabled device so ware func on; what valid
scien c evidence should establish, before and a er marke ng, that such a func on is safe and e ec ve;
and how to maintain that assurance when the device produces variable, open-ended outputs, evolves
a er deployment, and o en rests on a third-party founda on model the manufacturer does not control.
CDRH frames these as two regulatory challenges rst iden ed at the November 2024 Digital Health
Advisory Commi ee mee ng: (1) applying a risk-based approach to classifying and determining
regulatory requirements for these devices, and (2) determining the types of valid scien c evidence for
evalua ng their safety and e ec veness across the total product life cycle. CDRH asks for feedback that
is scien cally sound, least burdensome, and usable in future policy.

Who we are. Ramsee 1 LLC is a New York limited liability company and the assignee of U.S. Patent No.
12,683,789 B1, Decentralized Valida on of AI-Generated Responses via Blockchain-Based Consensus,
issued July 14, 2026 (applica on 19/266,838, led July 11, 2025). The patent claims a system and
method in which each answer produced by an SI system is checked, in real me, by a panel of
independent SI validators that commit sealed answers before any is revealed; the output is accepted
only when a prespeci ed consensus threshold is met; each validator is scored on measured accuracy;

Page 1 of 26

ff
ti
ti
fi
ti
tt
ti
ti
ft
ti
ti ti
ti
ti
ti
fi
fi
ti
ti
ti
ti
fi
ft
ti ti
ti
fi
ti
ti
ti
tt
ti
ti
ti
fl
ti
ti
ff
ti ti
ff
ti
ft
ti
fi
ti
tt
fi
ti
ti
tt
fi
ti
ti
ti
fi
ti
ti
ft ft
 and the full result is wri en to an append-only, tamper-evident record. The signatory is a physicianscien st and a named co-inventor.

What this comment does, and where to nd our answers to the discussion ques ons. Reviewers
working ques on by ques on will nd our direct answers in Sec on 4, organized by ques on number,
with in-depth answers to Q1, Q9, Q16, Q19, Q20, Q21, Q22, Q23, Q24, and Q25 and shorter views on
Q3, Q4, Q5, Q6, Q10, Q12, Q13, Q14, Q18, and Q26. Each answer in Sec on 4 cross-references the
recommenda on in Sec on 3 that supports it. The rest of the comment supplies the reasoning: Sec on 1
restates, in CDRH's own terms, what the discussion paper is asking for and where the hard problems lie.
Sec on 2 explains, in plain prose, how an independent per-output valida on architecture of the kind we
have patented answers each of those problems. Sec on 3 states nine recommenda ons in language
CDRH could carry into guidance. Sec on 5 states limita ons, our posi on on licensing, and what the
signatory can o er. Appendix A maps the issued claims to CDRH's ques ons, and a disclaimer closes the
comment.

A note on the examples. The worked examples in this comment, renal dose adjustment within a clinical
conversa on and measurement and signal-processing func ons, were chosen because the discussion
paper itself names them as areas needing a en on. They are responses to CDRH's examples, not the
limits of the approach. The valida on architecture described in Sec on 2 is independent of clinical
domain and output type; what varies between use cases is con gura on, which outputs trigger
valida on, what comparator is used, what threshold applies, and what the device does when valida on
fails. We expect that sponsors, standards bodies, and CDRH will adapt those parameters case by case
across the range of genera ve SI func ons the paper an cipates, and the recommenda ons in Sec on 3
are wri en func onally so that they can.

Disclosure of interest. Ramsee 1 LLC has a direct nancial interest in the subject of this comment. If
CDRH were to adopt, recommend, or recognize valida on requirements of the kind described here,
Ramsee 1 LLC could bene t through licensing or commercializa on of the patented system. The
signatory and her spouse are the named co-inventors and principals of Ramsee 1 LLC. As of the date of
this comment, Ramsee 1 LLC has no marketed device, no pending premarket submission, no working
commercial implementa on, and no contract with any device manufacturer or founda on model
developer. We received no third-party funding to prepare this comment. We ask CDRH to read
everything that follows with this interest in mind, and we have wri en the recommenda ons in Sec on
3 in func onal terms that any implementa on, including open-source and compe ng implementa ons,
could sa sfy.

A note on terminology. Consistent with Execu ve Order 14434 of September 29, 2026, Inaugura ng the
Era of Super Intelligence, which directs execu ve agencies to use "Super Intelligence" and "SI" in place of
"ar cial intelligence" and "AI" in non-statutory documents, this comment uses super intelligence and SI.
Where it quotes the discussion paper's tle, de ned terms, or discussion ques ons, it retains the paper's
wording so that CDRH sta can match this comment to the paper without transla on.

Sec on 1. What CDRH is asking for
The discussion paper is a request for help with one problem that appears in every sec on of it: a
genera ve SI-enabled device produces outputs that are uent, variable, open-ended, and some mes
wrong, and neither the user, the sponsor, nor the reviewer can tell from the output alone whether it was
right. Every ques on CDRH asks follows from that gap. Read closely, the paper is not asking for a be er

Page 2 of 26

ti
ti
ti
ti
ti
ti
ti
ti ti
ti
ti ti
ti tt
ti
ti
ti
ti
ti
ti
ti ti
ti
tt
ti ti
fi
ti
fl
ti
ti
ti
ti
fi
fi ti
ti
ti
tt
ti
fi
ti
ti
ti
fi
ti
ti
ff
fi ti
ti
ti
tt
ti
ti
ff
ti
ti
ti ti
ti
ti
tt
ti
ti
ti fi
ti ti ti
 way to trust the device; it is asking for a way to check the device, output by output, a er it is deployed,
by something other than the device itself. We restate the paper's structure below in its own terms, and
at each step we note the property any workable answer must have.

1.1 The two regulatory challenges
CDRH iden es two challenges carried forward from the November 2024 Digital Health Advisory
Commi ee mee ng. The rst is applying a risk-based approach to classifying and determining
regulatory requirements for genera ve SI-enabled devices. The second is determining the types of valid
scien c evidence for evalua ng their safety and e ec veness across the total product life cycle (TPLC).

The paper explains why both are hard for this technology. These devices accept open-ended inputs,
perform mul ple subtasks, and produce variable outputs to similar inputs. They can evolve through
changes to the underlying model, prompts, retrieval strategies, guardrails, orchestra on logic, or user
interface. Many are built on general-purpose founda on models developed by third par es, with limited
transparency into training data, architecture, and evalua on, which makes it di cult to a ribute speci c
behaviors and errors to the device or its model. Their characteris c risks are confabula ons that appear
authen c to users, uncertainty in the bounds of intended use, limited visibility into the underlying
model, and performance degrada on between test and real-world environments.

CDRH's stated conclusion is that it may be unreasonable to evaluate every conceivable input a device
might encounter, that new evalua on methodologies may be needed, and that premarket evidence will
need to be complemented by postmarket evidence from robust device performance monitoring. The
two challenges therefore reduce to one prac cal ques on: if the inputs cannot be enumerated in
advance, where does the assurance come from? The paper's own answer is that it must come, at least in
part, from the outputs themselves, a er deployment, as they are produced. That answer has a
consequence CDRH draws out in Sec on VI: whatever checks an output must leave a record a reviewer
can rely on later.

1.2 The risk-based approach and the two-axis framework
CDRH proposes a two-axis framework as an organizing heuris c. The ac vity axis runs from nondirec ve informa on, through ac on-direc ng informa on, to ac on-taking func ons, and from
con nuous healthcare professional (HCP) supervision to full autonomy. The consequences axis captures
the severity of harm from relying on an incorrect output. Risk rises from the lower le to the upper right.

The paper then describes several considera ons that move a func on along those axes, and each one
turns on the same underlying fact: whether anyone can check the output before relying on it.

• Ac on-direc ng versus non-direc ve func ons. CDRH is considering trea ng ac on-direc ng
func ons as higher risk, recognizes that direc veness is a con nuum rather than a binary, and
notes that a "talk to your doctor" disclaimer may not make an output less direc ve. What raises
the risk is not the wording but reliance on an instruc on no one has veri ed. A disclaimer does
not verify it; only an independent check does.

• Measurement and signal-processing func ons. CDRH observes that these func ons may
migrate higher on the consequences axis even though they are non-direc ve, because the user
typically cannot independently evaluate the basis for the output. This is the paper's clearest
statement of a principle that governs everything else: an output that cannot be independently

Page 3 of 26

ti
tt
ti
ti
ft
ft
ti fi
ti
ti
ti
ffi
ti ti
fi
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ff
ti
ti
ti
ti
ti
ti
ti ft
ti
ti
ti
ti
ti
ti
fi
ti
ti
ti
ti
fi
ti
ti
fi tt
ti
ti
ti
ti
ti ti
 evaluated is a higher-risk output. CDRH es it to the independent-review criterion of the clinical
decision support exclusion under sec on 520(o)(1)(E), which already treats the availability of
independent review as the dividing line between regulated and unregulated func ons. The
converse follows naturally: restoring independent review to an output should move it back down
the axis.

• Pa ent-facing versus HCP-facing func ons. CDRH weighs the bene ts of pa ent empowerment
against the fact that pa ents lacking domain knowledge may not iden fy an incorrect output,
may rely on it, and may delay care or self-treat inappropriately. The paper asks what device
characteris cs, output features, or safeguards might mi gate that risk without underes ma ng
pa ent capability. The ques on answers itself once it is stated precisely: the pa ent cannot
supply the check, so the device must carry one.

• Generalist versus specialist HCP-facing func ons. The same ques on in a di erent popula on:
an HCP without specialty training may not be able to contextualize a specialist-level output. The
safeguard CDRH is reaching for is one that does not depend on the exper se of whoever
happens to be reading the screen.

• Mul -turn conversa ons. A device may begin as informa onal and migrate, over a conversa on,
to ac on-direc ng. CDRH wants risk assessed across realis c conversa onal trajectories, which
presupposes that each turn's output is captured and reviewable.

• Care escala on. Both under-escala on and over-escala on are harms, and CDRH wants both
direc ons of error measured. Measuring either direc on requires knowing, for each escala on
output, what the device said and what an independent reference would have said.

Read together, these considera ons describe a single gradient. At the low-risk end are outputs an HCP
can readily check against their own knowledge and other clinical informa on. At the high-risk end are
outputs that are direc ve, pa ent-facing or specialist-level, and that no one in the loop can
independently evaluate. The two-axis framework, in other words, is largely a map of where an
independent check is missing. CDRH's own framing implies that a safeguard which restores an
independent check at the high-risk end is a risk-modifying factor, and the paper asks in Ques on 1
whether addi onal dimensions, including traceability of the output, should be represented in the
framework. We think traceability is the right word, and that CDRH has de ned it too narrowly:
traceability to primary sources tells a user where an output came from; traceability of the output's
valida on tells the user, and the reviewer, whether anyone checked it.

1.3 The evidence problem: a competency-based approach
For premarket evalua on, CDRH proposes a competency-based approach modeled loosely on how
clinicians are creden aled: device benchmarking (structured, high-throughput, non-clinical tes ng of the
nal user-facing device as con gured for deployment) followed by clinical con rma on (evidence of
performance in real or clinically representa ve use, scaled to risk, not always requiring a prospec ve
study).

CDRH states general principles for benchmarking that any solu on must honor: test methods and
acceptance criteria prespeci ed before tes ng; scoring rubrics grounded in clinical guidelines or
validated by quali ed experts; and expert adjudicators that are structurally independent from the
device sponsor and, where the device incorporates a third-party model, from the developer of that

Page 4 of 26

fi fi ti
ti
ti ti
ff
ti ti
ti
ti
ti
ti
fi
ti
ti
ti
ti
ti ti
ti
ti
ti ti
ti
ti
ti
ti
ti
fi
ti
fi
ti
ti
ti
ti
ti
ti
fi
ti
ti
ti
ti
ti
ti
ti
ti
ti ti
ti
fi ti
ti ti ti
ti
 model. CDRH adds that these independence considera ons "would s ll be applicable when the expert
adjudicator is itself an LLM." That sentence is, in our reading, the paper's most important. CDRH already
an cipates machine adjudica on of genera ve SI outputs; already requires that the adjudica ng
machine be independent of the sponsor and of the founda on model developer; and already expects
the result to be prespeci ed and reproducible. What the paper does not yet say is what independence
means for a machine, how it would be engineered, or how a reviewer would verify it. Those three gaps
are, in our view, the gaps most worth closing in this docket, because once they are closed, the rest of the
competency-based approach has something to stand on a er deployment, not only before it.

CDRH also raises, and seeks input on, the standard against which performance should be measured (a
panel of quali ed clinicians, a median clinician, or a conven onal reference standard), how to measure
performance sta s cally for open-ended outputs, how to use synthe c data without reproducing the
gaps it is meant to detect, and what role independent third par es might play, through programs such as
ASCA and the Medical Device Development Tools (MDDT) program, in benchmarking, sequestered
datasets, and adjudica on. Each of these ques ons assumes a reference that is independent of the
device and a record of how the device compared to it. The paper asks who should hold that reference
and how it should be applied; it does not yet ask whether the comparison could be made on every
output rather than on a sample. We think it should, and that CDRH's own third-party roles —
sequestered datasets, independent adjudicators, quali ed tools — are the roles a per-output
adjudica on layer is built to ll.

1.4 The benchmarking elements, read as requirements
CDRH proposes four groups of benchmarking elements (Appendix A of the paper). We restate each as
the ques on CDRH is asking a sponsor to answer, because that is the form in which any solu on must
respond.

CDRH element What CDRH wants to know What that requires of a safeguard
Safety — S.1 safety- Does the device recognize A device cannot detect its own
cri cal recogni on and danger, stay within its intended confabula on; by construc on, a
escala on; S.2 scope use under adversarial and confabulated answer looks to the device
maintenance and mul -turn pressure, and exactly like a correct one. S.3 therefore
boundary adherence; represent its own con dence requires a second opinion the device did
S.3 calibra on, accurately rather than not generate, on each output, and a
uncertainty presen ng uncertain or prespeci ed behavior ( ag, withhold,
communica on, and outdated informa on with false defer) when that opinion is not obtained.
clinical deferral con dence?

Page 5 of 26

ti
ti
ti
ti
ti
ti ti
fi ti
ti
ti
ti
fi
ti
fi
fl
fi ti
ti
ti
ti
ti
fi
ti
ti
ti
fi ti
ti
ti
ti
fi ti
ti
ti ft
 CDRH element What CDRH wants to know What that requires of a safeguard
Clinical pro ciency — Does the device know current E.4 names the failure mode exactly: the
E.1 clinical knowledge medicine, reason through user accepts a uent wrong answer
and task delity; E.2 incomplete informa on, because of the device's authority. The
informa on gathering calculate correctly, and countermeasure CDRH is describing is a
and clinical analysis; E.3 communicate in a way that check that compares substance, not prose,
quan ta ve and avoids automa on bias from and a signal to the user that is
measurement analysis; uency or perceived authority? independent of the device's own
E.4 communica on con dence.
quality and user
comprehension
Generalizability — R.1 Do the safety and pro ciency A premarket sample cannot contain the
robustness, reliability, proper es hold across real-world distribu on; CDRH says so. R.1
and reproducibility; R.2 paraphrases, input order, long and R.2 can only be established a er
subgroup performance conversa ons, adversarial deployment, on the actual inputs, and only
inputs, repeated runs, and if each output and its check are recorded
clinically relevant subgroups? so that reproducibility and subgroup
performance can be computed from the
record.
Agen c SI capabili es Does an agen c device A checkpoint the agent runs on itself is not
— A.1 planning, tool recognize when a planned a checkpoint. A.1 presupposes a judge of
use, human-oversight ac on sequence exceeds its scope that is independent of the agent and
checkpoints, resistance safety envelope, and does it that sees the proposed ac on before it
to prompt injec on comply with human-oversight executes.
checkpoints before irreversible
ac ons?

Across all four groups, CDRH's principles require that acceptance criteria be prespeci ed, that
adjudicators be independent, and that the evalua on be reproducible. The common thread is that CDRH
wants evidence that does not depend on trus ng the device's own account of itself. Stated as a design
requirement rather than a test requirement: the device should carry, alongside each output, an
independent judgment it did not produce, obtained under prespeci ed criteria, and recorded so that a
reviewer can later verify both the output and the judgment. That is the shape of the thing CDRH is asking
for, whether or not the paper names it.

1.5 Postmarket monitoring and change control
CDRH is considering whether to accept greater premarket uncertainty in exchange for greater reliance on
postmarket monitoring, and asks what characteris cs a monitoring program would need to jus fy that
trade. It lists three candidate approaches: periodic re-benchmarking against the prespeci ed premarket
thresholds; periodic sample-based clinician review of real-world inputs and outputs; and performance
degrada on monitoring for dri from changes in the input popula on, data environment, or model
components. All three are sampling strategies, and all three share a dependency the paper does not
state: each needs a complete, trustworthy record of real-world inputs and outputs to sample from, and
each gets be er the more of that record carries a judgment about whether the output was right. CDRH

Page 6 of 26

ft fi
ti
ti
ti
ti fi
ft
ti
fi
ti
ti
ti
ti
fl
ti ti
ti
tt
fi
ti
ti fi
ti
ti
ti
ti
ti
fi
ti ti
ti
fl fi
 then asks whether some of this can be done by machine-based supervisory agents, and, pointedly, how
the supervisory agent itself would be evaluated. That second ques on is the right one, and it has a
known answer in every other eld that relies on automated checking: use more than one checker, keep
them from seeing each other's work, score each against ground truth, and keep the score.

CDRH then iden es the hardest change-control problem in the paper. Changes to a device may be
sponsor-ini ated, may arise passively through model evolu on, or may be unplanned changes arising
from updates to an underlying third-party founda on model that the manufacturer did not ini ate and
may not be told about. CDRH asks how a manufacturer can detect, evaluate, and respond to such
changes in a mely manner, and whether contractual, technical, or Predetermined Change Control Plan
(PCCP) mechanisms could provide reasonable assurance. The ques on contains its own constraint: a
manufacturer that is not told about a change can only detect it by observing the device's behavior, which
means the detec on mechanism must already be watching every output before the change occurs.
CDRH proposes that the premarket competency assessment serve as the baseline against which postdeployment modi ca ons are re-evaluated, which, as the paper notes, underscores the need to design
that assessment carefully in the rst place. We read that as an invita on to design the premarket
assessment so that it can be re-run con nuously, not only on demand.

Finally, CDRH oats voluntary Founda on Model Device Master Files through which model developers
could submit model cards, evalua on results, safety constraints, update-no ca on commitments, and
audit log availability (footnote 24 of the paper), while acknowledging that developers may have limited
incen ve to disclose safety-relevant informa on and asking for alterna ve mechanisms. The
acknowledgment is the important part. CDRH is signaling that it does not expect to get what it needs
from the model developers, and is asking what the device manufacturer could supply instead. The
answer the paper is reaching for is evidence generated on the manufacturer's side of the boundary: a
record of how the model, inside the device, actually behaved under independent checking, for the
device's intended use.

1.6 What a solu on would have to look like
Taken together, the paper asks for something with the following proper es, each of which CDRH has
stated or implied in its own text. It must give the user, the sponsor, and the reviewer an independent
check on each clinically consequen al output (Sec ons IV and V.B of the paper), so that risk assessment
can credit the check and the user is not le with uency as the only signal. The check must be performed
by adjudicators whose independence from the sponsor and the founda on model developer can be
de ned and veri ed (Sec on V.B), including when the adjudicator is a machine. Its acceptance criteria
must be prespeci ed and propor onate to risk on the two-axis framework (Sec ons IV and V.B). It must
run on the real-world input distribu on a er deployment (Sec on VI.A) and produce a record from
which re-benchmarking, sample-based clinician review, and dri detec on can be performed without
addi onal instrumenta on (Sec on VI.A). It must detect behavioral change in a third-party founda on
model whether or not the developer announces it (Sec ons VI.C and VII.A). And it must do all of this
without di using manufacturer accountability (Sec on VI.B), within least-burdensome principles, and in
a form that FDA's exis ng record-keeping expecta ons, such as the audit-trail requirements of 21 CFR
Part 11 and the quality system regula on, can recognize. No single mechanism described in the paper
has all of these proper es together.

Sec on 2 describes an architecture built to those proper es.

Page 7 of 26

ti
ti
ti
fi
ti
ti ti
ti
ti
ti
ti
ti
ti
ft
ti
ti
ti
ti
ti
ti
ti
fl
ti
ft
ft
ti
ti ti
ti
ti
ti
ti
ti fi
fi
ti
ti
ti
ti
ti
fi
ti fi
fi
fi
ti
ti
fl
ti
ti
ff
ti
ti
ti
fi ti
 Sec on 2. Our response: independent per-output valida on
The proper es CDRH is asking for in Sec on 1.6 are, in our view, facets of one requirement: every
clinically consequen al output should receive an independent, prespeci ed, recorded check before or
alongside the moment a user relies on it. U.S. Patent No. 12,683,789 B1 describes an integrated
architecture built to that requirement. We describe it here in ordinary language and e each mechanism
to the need it answers. Bracketed numbers refer to the notes in Appendix B, which iden fy the speci c
claim or speci ca on passage, so that CDRH can check our characteriza on against the issued patent
rather than take it on trust.

2.1 How a single output moves through the architecture
1. The input and output are xed before anyone reviews them. When the device generates an
answer to a query, the exact query and the exact answer are encrypted and wri en to an
append-only, hash-chained record before any reviewer sees them. [1] No party, including the
sponsor, can alter what was asked or what was answered once a valida on result is known. This
is the per-output equivalent of the secure, computer-generated, me-stamped audit trail that 21
CFR Part 11 already expects of electronic records in regulated se ngs.

2. The same query goes to a panel of independent SI validators. The record is distributed to one
or more valida on nodes that may run in a federated arrangement on separate compu ng
infrastructure, using di erent model architectures and training data to reduce shared bias. [2]
Each validator receives the original query, not the device's answer, and generates its own
answer.

3. Each validator commits a sealed answer before any is revealed. Every valida on answer is
encrypted with a reveal me and decrypted only when that me expires. [3] No validator can
see the device's answer or any peer's answer before commi ng its own. This is the machine
equivalent of the blinded review CDRH describes in Sec on V.C of the paper.

4. A prespeci ed, risk-propor onate threshold decides whether the output is validated. The
answers are compared by a similarity metric, clustered into agreeing and disagreeing clusters,
and the output is validated only when the agreeing cluster sa s es a predetermined threshold.
[4] The threshold can be set by query type, category, di culty, validator count, or validator
history, so a sponsor can require a ghter consensus for ac on-direc ng or high-consequence
func ons than for non-direc ve ones. [5] If the threshold is not met, the device behaves as the
sponsor has prespeci ed: ag the output as unvalidated, withhold it, or defer to a human.

5. Every validator is scored on measured accuracy, and the score is recorded. Each validator
carries a performance score built from accuracy and speed with explicit weights, and an overall
panel score is computed. [6] Accuracy is established against adjudicated cases, so a validator that
is wrong in the same way as the device loses weight over me.

6. The full result is wri en to the record. The valida on record carries not just the verdict but the
vote: how many validators received the query, how many agreed, how many disagreed, which
ones, their historical accuracy, and a mestamp of valida on. [7] An inves gator six months later
can reconstruct what was asked, what was answered, who checked it, how they voted, and
when.

Page 8 of 26

ti fi
ti
tt
ti
ti
fi
ti
ti
ti
ti
ti
tti
fi
ti
tti ti
ti
ti
ti
ffi
ti
ti
ti
ti
ti
ti
ti
fl
fi
ti
ff
fi
tt ti
ti
ti
fi
ti
fi
ti
ti ti
 7. Each validated answer is compared with prior validated answers to similar queries, and the
di erences are stored. [8] A rising rate of divergence between new and previously validated
answers to seman cally similar queries is a direct measure of how much the device's behavior
has moved.

The speci ca on describes deployment in an isolated, standalone environment with a private ledger and
local or open-source validator models, with the reward mechanism simulated or internalized. [9] As we
read the claims, none requires a public blockchain, a cryptocurrency, or external validators; the
dependent claim specifying cryptocurrency (claim 13) is one embodiment, and in an enterprise or
regulated deployment the "reward" element is sa s ed by an internal reputa on score or rou ng
priority. [10] No token economics is proposed inside a regulated device.

2.2 How this relates to exis ng approaches, and four ques ons a reviewer will ask
We an cipate the ques ons CDRH's clinical, so ware, and policy reviewers will raise, and answer them
here rather than leave them to the a achment.

Is this di erent from an LLM-as-judge or an ensemble? The clinically relevant mechanism, several
models answering the same ques on and vo ng, is not new. Mul -model juries, self-consistency
sampling, and judge models with rubrics are in use today, and the literature on them is substan al
(Zheng et al., Judging LLM-as-a-Judge, NeurIPS 2023; Wang et al., Self-Consistency Improves Chain of
Thought Reasoning, ICLR 2023; Du et al., Improving Factuality and Reasoning through Mul agent
Debate, 2023). What those approaches lack, and what the patent adds, is the regulatory substance: the
input and output are xed before any judge sees them; judges commit sealed answers so none can
anchor on the device or on each other; each judge's reliability is measured against ground truth and
recorded; and the vote, the iden es, and the me are wri en to a record a reviewer can verify later. A
single judge model with a rubric, which is what most sponsors will propose, gives CDRH a verdict. It gives
no way to know whether the judge shares the device's blind spots, no way to audit the verdict a er the
fact, and no record from which dri can be computed. The vote is the familiar part; the record is the part
that makes the vote usable as evidence.

What is the regulatory status of the valida on layer itself? If the layer changes what the device
presents to the user ( ags, withholds, or defers an output), it is a device so ware func on under FDA's
Mul ple Func on Device Products policy and must be evaluated as such. We think that is the right
outcome. The layer should be described in the submission as a risk-control func on with its own
intended use, benchmarked under the element proposed in Recommenda on 3, and included in the
PCCP. A sponsor that cannot describe how its safeguard was evaluated has not described a safeguard.

What about latency and burden? Mul -validator consensus adds inference cost and me, and we
address clinical ming in Sec on 5.1. The burden argument, however, runs the other way on net. CDRH is
contempla ng accep ng greater premarket uncertainty in exchange for postmarket monitoring. Peroutput valida on is the postmarket monitoring. It supplies the re-benchmarking signal, the stra ed
sample for clinician review, and the dri sta s c from one mechanism, and it reduces the clinician
review burden by direc ng clinician me to the outputs the machines disagreed on. A sponsor adop ng
it should be able to jus fy a smaller premarket clinical con rma on and a lighter clinician-review
cadence than one relying on periodic sampling alone. Valida on can also be scoped to the highconsequence query categories where it is jus ed, with the toggle the speci ca on describes, rather
than applied to every output.

Page 9 of 26

fi
ft
ti
ti
ti
ti
ti ti
ti
ti
ti
fi
ft
ti
ti
ti
ti
ti
tt
fi
fi
ti
ti
fi
ti ft
ti
ti
ti
ti
ft
ti
ti tt
ft
ti
ti
ti
ti
ti
ti ti
ti
ti fl
fi
ti
ti
ti
ti
ti
ti
fi
ff
ti
ti
ff ti
 How much does correlated error defeat the mechanism? Honestly: some, and the amount must be
measured, not assumed. The speci ca on's illustra ve arithme c (25 validators at 85 percent accuracy
yielding an error rate near one in 100,000) assumes independent errors and should not be read as a
performance claim. A more useful way to think about it: with ve validators at 90 percent individual
accuracy and a four-of- ve threshold, the false-valida on rate from independent errors alone is roughly
0.05 percent; but if 30 percent of each validator's errors are errors every validator shares (a stale
guideline, a common training ar fact), the false-valida on oor rises to roughly 3 percent regardless of
panel size. That oor is exactly what blinded clinician adjudica on of a sample is there to measure, and
why Recommenda on 2 requires error correla on to be reported and adjudicator model families and
training provenance to be disclosed. The architecture does not eliminate shared error; it makes shared
error visible, measurable, and a ributable, which no single-judge approach does.

2.3 How the architecture answers each need in Sec on 1
Sec on 1 closed with a list of proper es that a safeguard for genera ve SI outputs would need, and
noted that no single mechanism in the discussion paper has all of them. Sec on 2.1 described a
mechanism that does: each output is checked by a panel of independent models that commit blinded
answers, the result is judged against a prespeci ed threshold, each checker's reliability is scored, and the
whole exchange is xed in a tamper-evident record. The table below takes the needs iden ed in Sec on
1, one by one, and shows which part of that mechanism answers each. The le column cites the
subsec on of Sec on 1 and the discussion ques on involved; the right column states the answer in
CDRH's own vocabulary.

Need iden ed in Sec on 1 How the architecture answers it
1.2 — Risk rises when the user cannot Every output carries a veri able record of an
independently evaluate the basis for an output; independent check. Traceability is de ned
traceability is a candidate risk dimension (Q1) concretely: what was asked, what was answered,
who reviewed it, how they voted, and when, xed in
tamper-evident form. The record gives the user, and
the reviewer, a basis for the output other than its
uency.
1.2 — Pa ent-facing and generalist-facing The independent check is performed regardless of
func ons are higher risk because the user the user's exper se. An output that fails consensus
cannot catch a wrong output (Q3, Q4) can be agged, withheld, or deferred before a
pa ent or generalist relies on it.
1.3 — Adjudicators must be structurally Independence is engineered, not asserted: separate
independent from the sponsor and the model infrastructure, blinded commit-reveal, di erent
developer, including when the adjudicator is an model families, measured error correla on, and
LLM scored reliability. Sec on 3 proposes a ve-part
de ni on of machine-adjudicator independence that
any implementa on can be tested against.

Page 10 of 26

fi ti
ti
fi
ti ti
ff
fi ti
ti
fi
ti
fi
tt ti
fi
fi
ti
ti
fi
ti
ti
ti
ti
fl
fi
ti
ti
fl
ti
ti
ti
ti
fi ti
ti
fl fl fi ti ti ti ti ft ti fi ti
ti
 Need iden ed in Sec on 1 How the architecture answers it
1.3 — Acceptance criteria must be prespeci ed The consensus threshold is a predetermined
parameter set per query category before
deployment, jus ed like any acceptance criterion,
and recorded with each result.
1.4 Safety (S.1–S.3) — catch the con dent A hallucina on is, by de ni on, an answer
wrong answer; defer when uncertain independent models do not reproduce.
Disagreement among blinded validators is a direct
signal of the confabula on CDRH names as the
characteris c risk, and the prespeci ed failure
behavior supplies the clinical deferral S.3 asks for.
1.4 Clinical pro ciency (E.1–E.4) — a check The check compares substance, not prose quality.
independent of uency, to counter automa on For numerical outputs (doses, unit conversions, E.3)
bias the comparator is structured and numerical. A visible
"validated" or "unvalidated" indica on gives the user
a signal other than the device's authority.
1.4 Generalizability (R.1–R.2) — proper es Valida on runs on every produc on output, so
must hold on the real-world distribu on and reproducibility, paraphrase sensi vity, and subgroup
across subgroups performance are measured on the actual input
distribu on and are available from the record
without addi onal instrumenta on.
1.4 Agen c (A.1) — human-oversight For agen c func ons, the same blinded panel can
checkpoints independent of the agent serve as an independent checkpoint on a proposed
ac on or plan before execu on; the agent is not the
sole judge of its own scope. We propose this only for
valida ng generated content and proposed ac ons,
not as a subs tute for human authoriza on of
irreversible ac ons.
1.5 — Periodic re-benchmarking The record iden es which real-world query
categories produce the lowest agreement, so rebenchmarking can be weighted toward them rather
than toward the original premarket set.
1.5 — Sample-based clinician review Sampling can be stra ed by valida on outcome:
disagreements rst, then a random slice of
agreements. Clinician me goes where the machines
were least sure. Clinician adjudica ons feed back
into validator accuracy scores.
1.5 — Performance degrada on monitoring A rolling agreement rate per query category is a dri
sta s c with a built-in denominator and mestamp;
the stored deltas between new and prior validated
answers are a second, complementary dri sta s c.

Page 11 of 26

ft
ti
ti
ti
fi
ti
ft
ti
ti
ti
ti
ti
fi fi
ti
ti
ti
ti
ti
ti
ti
ti
fi
ti
ti
ti
fi
ti
fi fi
fi ti ti
fl
ti
fi
ti
ti
ti
fi
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
 Need iden ed in Sec on 1 How the architecture answers it
1.5 — Machine-based supervisory agents, and The supervisor is plural, blinded, scored against
how to evaluate the supervisor itself clinician adjudica on, and logged per output. If a
supervisor later proves unreliable, every output it
in uenced can be iden ed and re-reviewed.
1.5 — Detec ng unplanned third-party Two behavioral signals that re on behavior rather
founda on model changes (Q24) than announcements: a step change in agreement
rate on a xed probe set, and a rise in stored deltas
for seman cally similar queries. Contractual
no ca on remains necessary; these signals make it
veri able.
1.5 — Re-evalua on baseline for post- The premarket benchmarking set becomes a xed
deployment modi ca ons (Q22, Q23) probe set re-run on a de ned cadence through the
same valida on layer, so the premarket assessment
is literally the baseline CDRH proposes.
1.5 — Founda on Model MAFs and audit-log A per-inference valida on log is evidence about the
availability (Q25) model in the device, for its intended use, which is
what CDRH says it wants to evaluate. It reduces,
without replacing, dependence on voluntary
developer disclosure.
1.6 — Manufacturer accountability must not be Other stakeholders may run validators and supply
di used (Q21) votes; the sponsor alone sets the threshold, de nes
the failure behavior, and owns the record. The
sponsor cannot point to a third-party validator as the
reason a bad output reached a pa ent.

2.4 What the architecture does not do
What the architecture does, then, is make each output checkable and make the check auditable: an
independent, blinded, scored, recorded determina on of whether the device's answer is one that other
models, working from the same ques on, would also give. It is important to be equally clear about what
that determina on is not. Consensus among validators is a measure of agreement, not of medical
correctness. A panel can detect that the device's output disagrees with what other models would say; it
cannot, on its own, detect that all the models share the same wrong belief. The architecture therefore
supplements, and does not replace, clinician adjudica on of a sample, and it is not a subs tute for
clinical con rma on. No compara ve outcome data yet show that it reduces clinically consequen al
error rela ve to other safeguards; Ramsee 1 LLC has no working implementa on to o er CDRH today.
We say this plainly so that CDRH weighs Sec on 3 for what it is: a set of structural requirements that can
be speci ed now, ahead of outcome evidence, and against which any implementa on, including ours,
should then be tested.

Page 12 of 26

ti
ti
ff
ti
ti
ti
ti
fi
fi
ti
ti
ti
ti
fi
fi
fi
ti
ti
ti
ti
fi
ti
ti
ti
ti
ti
ti ti
fi
fi
ti
ti
fi
ti
fi
ti
ti
fi fi
ff ti
fl
 2.5 A worked example: renal dose adjustment
Consider an HCP-facing genera ve SI assistant used in the ordinary course of clinical conversa on. In the
middle of a discussion about an inpa ent with a presumed infec on, the clinician asks it for a
maintenance dose of a renally cleared an bio c given the pa ent's weight, age, crea nine, and
indica on. The device was not designed as a dosing tool, and a determinis c dose calculator remains the
be er instrument for the arithme c itself; the problem is that general-purpose genera ve devices get
asked such ques ons anyway, embedded in context, and answer them with the same uency whether
the number is right or wrong. On the two-axis framework this is an ac on-direc ng output with
moderate-to-severe consequences; CDRH's element E.3 names renal-func on-based dosing as a test
target. The ques on for CDRH is how to check an output of this kind when it arises inside a broader
exchange. All numbers below are illustra ve.

1. The clinician's query and the device's proposed dose are xed in a sealed record on the
hospital's private ledger. Protected health informa on does not leave the ledger's trust
boundary.

2. The query alone is distributed to, say, ve validator nodes operated by the hospital pharmacy,
running at least three model families. Each computes its own dose, seals it with a reveal me,
and commits.

3. A er reveal, the doses are compared numerically against a prespeci ed tolerance and dosing
interval, and checked against the product's prescribing informa on. The threshold for this highconsequence category is set high, for example four of ve.

4. If met, a valida on record is wri en with the vote, validator iden es, their accuracy history, and
the mestamp, and the dose is presented with a visible indica on that it was independently
validated.

5. If not met, the dose is presented agged as unvalidated or withheld and deferred to the
pharmacist, per the sponsor's prespeci ed behavior, and the disagreement is logged for clinician
review.

6. The validated dose is compared with prior validated doses for near-iden cal pa ent pro les; a
rising rate of di erences a er a founda on model update is the change signal.

What the record gives CDRH, the hospital, or an accreditor later: the exact query, the exact dose,
whether ve independent models agreed, which dissented, and when. What it does not give: assurance
that the ve models were not all trained on the same outdated dosing table. That is why a clinical
pharmacist adjudicates every agged disagreement, reviews a prespeci ed weekly sample of validated
doses, and signs o on the threshold, and why those adjudica ons are the ground truth the validators
are scored against.

Not every output is validated. A genera ve device in clinical conversa on produces many outputs, most
of which carry no clinical weight and need no independent check. Sending every sentence to a validator
panel would be slow, costly, and pointless. Valida on is therefore selec ve: the sponsor prespeci es
which categories of output trigger it, with ac on-direc ng outputs, numerical outputs such as doses and
conversions, diagnoses, and contraindica on statements at the top of the list, and conversa onal or
explanatory text generally outside it. A lightweight classi er in front of the valida on layer iden es an
output's category, and only outputs in triggering categories are sealed, distributed, and voted on. This

Page 13 of 26

fi
ti
ti
ti
ti
fi
ti
fl
ti fi
ti
ti
ti ti
fi ti
ti
ti
ti
fi
ti
ti
ti
ti
ti
ti
ti
fi
fi
ti
fi
ti
ti
ti
ti
ti ti
ti ti
ti
fi
fi
ti
ti
fl
tt
ti
fl
ft
ff
ti
ti
ff
ti
fi
fi
ti
ti
tt
ft ti
 keeps latency and cost propor onate to risk, and it es the valida on layer to the two-axis framework:
the more ac on-direc ng and consequen al the output category, the more likely it is to trigger
valida on and the higher its consensus threshold.

The patent an cipates this. Claims 5 and 7 provide that the consensus threshold may depend on the
query, the query type, the category, the di culty, and the validators' historical accuracy, so categorizing
outputs is part of the claimed design rather than an add-on. The further step of using those categories to
decide which outputs enter valida on at all is, in our reading, a deployment control within the
architecture rather than a claim element; we note the dis nc on so that CDRH is not misled about claim
scope.

The trigger set must itself be maintained. A prespeci ed list of triggering categories is only as good as
the day it was wri en. Clinical use will surface output types that should have been included and were
not, and others that prove low-risk in prac ce. The trigger set should therefore be treated as a controlled
parameter of the device, like the consensus threshold: documented in the monitoring plan, reviewed on
a de ned cadence against the clinician-adjudicated sample and against reported incidents, and
modi able under the PCCP's modi ca on protocol. Two signals in the valida on record point directly at
gaps. First, an output that clinicians ag or correct on sample review but that never entered valida on is
a candidate for a new triggering category. Second, a triggering category whose outputs pass consensus
at a very high rate over a long window may warrant a lower threshold or reclassi ca on. Both are
measurable from the record without addi onal instrumenta on.

The example is one instance of a general pa ern. Renal dosing was chosen because it is numerical,
high-consequence, and named by CDRH, not because the architecture is speci c to it. Nothing in the
mechanism depends on the clinical domain. The same sequence, seal the query and output, distribute
the query to blinded independent validators, compare their answers against a category-speci c
threshold, record the vote, applies wherever a genera ve SI func on produces an output on which
someone may act. A pa ent-facing symptom checker deciding whether to escalate, a discharge-summary
generator sta ng a medica on list, a radiology assistant dra ing an impression, a chatbot answering a
drug-interac on ques on, an agen c func on proposing an order set: each is a di erent output category
with its own comparator, threshold, and failure behavior, but the valida on layer, the record, and the
independence requirements are the same. What changes between use cases is the con gura on, which
is why Sec on 3 states the requirements func onally rather than by use case, and why the trigger set,
threshold, and comparator are the parameters a sponsor should jus fy for each func on in a device.
CDRH's two-axis framework is the natural place to set them: where a func on sits on the direc veness
and consequence axes should determine how aggressively its outputs are validated.

Measurement and signal-processing func ons. The discussion paper singles out genera ve SI-enabled
in vitro diagnos c, measurement, and signal-processing func ons as presen ng special considera ons
because their outputs are o en not directly accessible to the user: a clinician reading a reported value or
classi ca on cannot evaluate, by inspec on, the processing that produced it. This is the case in which
the architecture ma ers most, and it applies with three adapta ons. First, the sealed query is the raw
input, a waveform, image, spectrum, or sequencing read together with the request, rather than text, and
the validators are independent analyzers opera ng on that same raw input: di erent model families,
preferably di erent algorithmic approaches, and where one exists, a conven onal determinis c pipeline
or reference method as one member of the panel. Second, the comparator is numerical or categorical
with a prespeci ed analy cal tolerance, so that agreement is de ned as the independent analyzers

Page 14 of 26

ti
ti
ti
ti
fi
ti
fi
ti
ti
ff
fi
ff ti
ti
ti ti
ti
ti
ti
ti ti
fi
ti
ti ti
ft ti
ti
ti
fi
ti
ti
ti
tt
ti
ti
ti ti
ffi
ti
ti
ti
fl
ti
fi
ti
ti
ft
ti
ti
ti
ti
ti
tt
tt
ti
fi
ti
ff ti
ti
ti
ti
ti
ti
fi
fi
fi fi
 repor ng the same value within tolerance or the same classi ca on; this is a cleaner comparison than
any text-based one. Third, because the user cannot evaluate the output, the valida on record is the
user's only basis for it, and the visible validated-or-unvalidated indica on does the work that clinical
judgment does in the dosing example; a result on which the analyzers disagree is agged for referencemethod or human review before it is reported, which is the sample-based review CDRH describes,
targeted at the results that most need it. The general principle is the converse of the one CDRH states in
its risk discussion: where the user's ability to independently evaluate an output is lowest, the
independent check on that output should be strongest and its record most complete (Q1, Q3).

Sec on 3. Recommenda ons to CDRH
Each recommenda on is stated func onally, so that it can be sa s ed by any implementa on, including
open-source and compe ng implementa ons, and so that CDRH is not ed to any one vendor. Where we
suggest language, it is o ered as a star ng point for guidance text, not as a request that CDRH endorse a
product.

Recommenda on 1 — Recognize per-output valida on traceability as a risk-modifying factor on the
consequences axis (Q1). CDRH already treats a user's inability to independently evaluate an output as
raising risk. The converse should also hold: a func on whose outputs each carry a veri able record of an
independent check, demonstrated by evidence rather than asserted, may be credited on the
consequences axis in the same family as HCP review. Suggested language: "Traceability of an output
includes traceability of its valida on: the exact input and output, xed in tamper-evident form before
review; the iden ty of each adjudicator; each adjudicator's determina on and reliability record; the me
of valida on; and a means by which an auditor can verify that the record has not been altered."

Recommenda on 2 — De ne "structurally independent" for a machine adjudicator (Sec on V.B, Q16,
Q20). Without a de ni on, a sponsor can sa sfy the le er of the requirement by promp ng its own
founda on model to grade itself. We recommend ve criteria, each separately testable:

1. Structural independence. Adjudicators execute on compu ng infrastructure separate from the
device and from one another, so no single operator controls both the device and its reviewers.

2. Informa onal independence. No adjudicator sees the device's output, or any other adjudicator's
output, before commi ng its own. The query sent to adjudicators is the original query, not the
query plus the proposed answer, and the sponsor should demonstrate this.

3. Sta s cal independence. Adjudicator errors should not be correlated. Separate hardware and
blinding do not provide this; sponsors should measure error correla on among adjudicators
against clinician-adjudicated cases and report it, and should disclose adjudicator model families
and training provenance in the manner of a bill of materials.

4. Measured reliability. Each adjudicator's accuracy against adjudicated cases should be known,
recorded, and re ected in its weight.

5. Opera onal independence. Adjudicators should be operable by par es other than the sponsor,
such as a health system, a specialty society, or an ASCA-accredited laboratory.

Recommenda on 3 — Add a benchmarking element for independent veri ability and resistance to
correlated error (Q9). CDRH's Appendix A measures whether the device is safe and pro cient. We
recommend an element that measures whether the device's safety and pro ciency can be checked: the

Page 15 of 26

ti
ti
ti
fi
fi ti
fl
fi
fi
ti
ti
ti
ti
ti
fi
fi
ti
ti
fi
ti
tt
ti
fi
ti
ti
ti
ti
ti
ti
ti
fi
ti
ff
ti
tti
fi
ti
fl
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti ti
 rate at which outputs survive blinded independent adjudica on, the false-valida on rate (outputs that
passed adjudica on but were wrong on clinician review), the false-rejec on and absten on rates, and
the measured error correla on among adjudicators. For agen c devices (A.1), the element should also
test whether proposed ac on sequences are submi ed to a checkpoint independent of the agent.

Recommenda on 4 — Treat con nuous per-output valida on as a fourth postmarket approach that
strengthens the three CDRH lists (Q18, Q19, Q20). Periodic approaches sample the device at points in
me; con nuous valida on measures it on the actual input distribu on. Where a sponsor relies on it to
jus fy reduced premarket evidence, CDRH should expect: plural adjudicators mee ng Recommenda on
2; a prespeci ed and disclosed set of output categories that trigger valida on, with ac on-direc ng and
numerical outputs included, maintained as a controlled parameter under the monitoring plan and
reviewed against clinician sample review and reported incidents; behavior-based triggers prespeci ed on
the valida on sta s cs (agreement rate below a oor for a query category over a window; share of
outputs failing consensus above a ceiling; divergence from prior validated answers above baseline);
stra ed clinician review of disagreements rst and a random slice of agreements; and clinician
adjudica on as the ground truth against which adjudicators are scored. Agreement is not accuracy, and
the primary postmarket measures should remain clinically adjudicated error rate, false-valida on rate,
and correlated error.

Recommenda on 5 — For devices on third-party founda on models, expect a xed probe set and
behavioral change detec on in the PCCP (Q22, Q23, Q24). Contractual no ca on is necessary but not
su cient; developers do not always know which changes ma er clinically, and some changes (silent
rou ng, safety-layer updates, retrieval changes) are not versioned. The premarket benchmarking set
should serve as a xed probe set re-run on a de ned cadence, with the valida on record and the stored
deltas for that set serving as the change-detec on baseline. A step change in agreement on the probe
set, with query mix and adjudicators held constant, is a trigger for inves ga on under the PCCP's
modi ca on protocol.

Recommenda on 6 — Make the accountability boundary a deployment requirement (Q21). Other
stakeholders may run adjudicators and supply votes. The sponsor must retain sole control of the
consensus threshold, of the device's behavior when valida on fails, and of the record, and the
monitoring plan must document how that control is enforced through administra ve privileges, ledger
governance, and adjudicator admission. The monitoring plan should also describe the clinical review
role, including reviewer quali ca ons and expected review volume, so that human oversight is designed
in rather than assumed.

Recommenda on 7 — Make per-inference audit-log availability a core, not op onal, element of any
Founda on Model MAF, and accept device-level valida on logs as an alterna ve mechanism (Q25). A
per-output valida on log for a given model version, in the device's intended-use context, is evidence
about the model in the device. It reduces dependence on voluntary developer disclosure without
replacing it.

Recommenda on 8 — Anchor these requirements in FDA's exis ng record-keeping framework. The
record described in Recommenda on 1 is a secure, computer-generated, me-stamped audit trail of the
kind 21 CFR Part 11 already expects, applied at the granularity of a single inference. Framing it that way
lets CDRH extend expecta ons reviewers already apply rather than introduce a new category of
evidence.

Page 16 of 26

ti ti ti
fi
ti
ti
ti
ti
ti
fi
ti
ti ti
ti ti
ti
ti
ti
ti
tt
ti
ti
ti
ti
ti
tt
fl
fi
ti
fi
ti
ti ti
fi
ti
ti
ti
ti
ti
ti
ti fi
ti
ti
ti
ti
ti
ti
ti
fi
ti
ti
ti
ti
ti
fi
fi
ti
ti
ti ti
ffi
ti ti fi ti
ti
 Recommenda on 9 — Generate the evidence: a CDRH-facilitated, prespeci ed compara ve
assessment of independent per-output valida on against the alterna ves (Q11, Q16, Q19). CDRH has
said it is commi ed to working collabora vely with stakeholders across government, industry, and
academia to iden fy e cient, scien cally sound approaches, and the paper invokes ASCA, MDDT, and
third-party roles as vehicles. We recommend that CDRH, through its regulatory science program, a
Collabora ve Community, or a DHCoE-sponsored challenge, facilitate or observe a prespeci ed
compara ve assessment of per-output valida on against the approaches sponsors will otherwise
propose: a single judge model with a rubric, periodic sample-based clinician review alone, and no
valida on layer. The assessment should be run in one narrowly de ned, high-consequence use case such
as renal dose adjustment (element E.3), on a benchmarking set of CDRH's choosing, with an
independent party verifying results. We suggest four phases:

1. Laboratory validity. Benchmark validated outputs against clinician-adjudicated ground truth;
report sensi vity, speci city, false-valida on, false-rejec on, and absten on rates, and latency,
for each arm.

2. Independence and security. Stress-test correlated error, collusion, validator compromise,
premature reveal, log tampering, and model-family overlap; report measured error correla on.

3. Clinical u lity. In shadow deployment, measure whether valida on changes clinician workload,
me to decision, and the rate of unsafe recommenda ons reaching the user, against the
comparator arms.

4. Interoperability. Publish a record schema and audit-access criteria that patented, licensed, opensource, and other equivalent implementa ons can all sa sfy.

Ramsee 1 LLC does not have the capacity to conduct such an assessment itself and does not propose to
lead it. We suggest it because the evidence it would generate is what CDRH needs to calibrate
Recommenda ons 1 through 8, and because the comparator arms are the approaches sponsors will
otherwise propose without evidence. An assessment of this kind would be appropriately run by an
academic medical center, a Collabora ve Community, or CDRH's regulatory science program, and should
be open to any implementa on, patented or not. The requirements in Recommenda ons 1 through 8
can be speci ed now; the assessment is how CDRH could obtain outcome evidence to re ne them over
me.

One speci c request. Ramsee 1 LLC asks that CDRH consider the architecture described in Sec on 2 as
one illustra ve example when it de nes independent valida on of genera ve SI outputs in future
guidance, or when it refers the subject to a recognized standards body. We ask for considera on as an
example, not for endorsement, exclusivity, or a presump on of clinical e ec veness.

Sec on 4. Answers to the discussion ques ons
We answer in depth the ques ons on which the architecture o ers a concrete contribu on (Q1, Q9,
Q16, Q19, Q20, Q21, Q22–Q25) and give brief views on a few others. We do not answer every ques on;
CDRH will hear from par es with deeper exper se on the rest.

Q1 — Does the two-axis framework capture the relevant dimensions? Should addi onal dimensions
such as traceability be represented? Yes, and traceability should be a formal risk-modifying dimension,
de ned as traceability of the valida on of each output, not only traceability to primary source materials.

Page 17 of 26

ti ti ti
ti
fi
ff ti
ti ti
ti
ti
ti
ti
ti fi
ti
ti
ti
ti
ti
fi
ti
ti
fi
ti
ti
ti
fi
ffi
ti
tt
ti ti
fi
ti
ti
fi
ti
ti
ti
ti
ti ti
fi
ti
ti ti
ti ti fi ti ti fi ti ti ti
ff
 The argument is the one CDRH already makes for measurement and signal-processing func ons: when
the user cannot independently evaluate the basis for an output, risk rises. A valida on record gives the
user a basis. The appropriate credit on the consequences axis is for CDRH to set and for evidence to
jus fy; a record of how an incorrect recommenda on was validated makes the error ndable and
correctable, and makes the next one less likely, but does not make the harm from that error less severe.
See Recommenda on 1 for the content and ming of the record. Of the other dimensions CDRH names,
reversibility and downstream safeguards are both strengthened by a per-output record, because the
record is what lets a downstream safeguard know what to reverse.

Q3 and Q4 — Pa ent-facing and generalist-facing func ons. These are the popula ons for whom an
independent check ma ers most, because the user cannot supply one. A validated/unvalidated
indica on, plain-language uncertainty signals, and a visible escala on path are the safeguards; the
primary safeguard remains escala on design. A panel of machine adjudicators does not subs tute for
specialist acceptance criteria where an output requires specialist exper se; professional socie es can
curate adjudicator models and reference sets for their specialty (see Q21).

Q5 — Mul -turn trajectories. Test sequences, not isolated replies. Per-output valida on addresses each
reply on its own; trajectory-level evalua on requires separate methods that this comment does not
address.

Q6 — Under- and over-escala on. Measure both failure modes separately, against adjudicated cases, by
clinical context and subgroup, and report absten on and false reassurance as dis nct outcomes.

Q9 — Is the benchmarking structure adequate? Are elements missing? Add an element for
independent veri ability and resistance to correlated error, as set out in Recommenda on 3. The exis ng
elements measure whether the device is right; none measures whether its being right can be checked by
something other than the device. Externally developed standards that could be leveraged include 21 CFR
Part 11 audit-trail concepts and the SBOM concept from FDA's premarket cybersecurity guidance,
adapted to adjudicator model provenance.

Q10 — Contaminated benchmarks and sponsor-developed benchmarks. Blinded, independent
adjudica on reduces imita on among reviewers but does not solve training-set contamina on;
sequestered cases, refreshed test banks, and hidden challenge sets remain necessary. Sponsordeveloped benchmarks should be accepted only with independent adjudica on and disclosure of
adjudicator provenance.

Q12 and Q13 — Sta s cal measurement and synthe c data. Prespecify denominators and report
device error, adjudicator miss rate, false rejec on, absten on, latency, subgroup error, and correlated
failure as separate quan es. Track model-family overlap between any synthe c-case generator and any
adjudicator; a generator from the same family as the adjudicators will reproduce the gaps the evalua on
is meant to detect.

Q14 — Comparators for open-ended outputs. Accept clinically equivalent language rather than string
iden ty. Seman c similarity and clustered agreement are informa ve signals, but quali ed clinicians or
outcome-linked references must decide medical correctness.

Q16 — Should independent third par es be involved, and what independence criteria should apply?
Yes. CDRH's observa on that independence requirements would s ll apply when the adjudicator is an
LLM is the sentence this comment is built around. We recommend the ve-part de ni on in

Page 18 of 26

ti
ti
ti ti
ti
fi
ti ti
fi
ti
fi
ti
ti
ti
ti
ti
fi
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
tt
ti
ti
ti
fi ti
ti
ti
ti
ti
ti
ti
ti ti
 Recommenda on 2. On roles: machine adjudica on ts the roles of independent expert adjudica on
and of an FDA-quali ed tool under MDDT; it does not t the role of issuing a competency cer cate on
its own, because consensus among machines is not a clinical standard of care. The right pairing is
machine adjudica on at scale with clinician panels adjudica ng the disagreements and a sample of the
agreements. On compe on: the independence standard should be stated func onally so that mul ple
vendors and open-source implementa ons can sa sfy it. Ramsee 1 LLC's posi on on its own intellectual
property is in Sec on 5.

Q18 — Accep ng greater premarket uncertainty in exchange for postmarket monitoring. Only for
bounded risks, with clinically validated surveillance, prompt incident detec on, prespeci ed interven on
triggers, and a credible response plan. Logging alone is never assurance of safety. Where a sponsor relies
on con nuous per-output valida on to jus fy reduced premarket evidence, the condi ons in
Recommenda on 4 should apply.

Q19 — Postmarket approaches, cadence, and triggers. Add con nuous per-output valida on as a fourth
approach that strengthens the three CDRH lists: it weights re-benchmarking toward low-agreement
query types, stra es clinician review toward disagreements, and supplies a dri sta s c with a built-in
denominator. Triggers should be de ned on the valida on sta s cs rather than on the calendar, and
prespeci ed per query category, ghter for ac on-direc ng or high-consequence func ons, which es
the monitoring plan to the two-axis framework.

Q20 — Machine-based supervisory agents. Acceptable if, and only if, they are plural, blinded, scored,
and logged (Recommenda on 2 and 4). A single supervisor with the same blind spots as the device adds
no safety. The supervisor should be held to the same standard as the device, which is made tractable by
using several supervisors, measuring them against each other, and measuring all of them against
clinician adjudica on. On Sybil-style failure, where a manufacturer oods the panel with copies of a
favorable model: weigh ng by historical accuracy means new or low-reputa on adjudicators contribute
less, and CDRH could addi onally require that adjudicator iden es and operators be disclosed in the
monitoring plan. The limita on to state plainly: a panel can detect that the device disagrees with other
models; it cannot on its own detect that all the models share a wrong belief.

Q21 — Roles for other stakeholders without di using accountability. Other stakeholders may run
checks; the manufacturer remains responsible for what the device does with the result
(Recommenda on 6). Healthcare ins tu ons can operate adjudicator nodes on their own infrastructure
against their own pa ent mix. Professional socie es can curate adjudicator models and reference answer
sets for their specialty and adjudicate recorded disagreement clusters, which answers Q4 without
requiring a specialist on every output. Standards-se ng bodies can de ne the record schema and
independence criteria so that records from di erent vendors are comparable. ASCA-accredited
laboratories can operate sequestered adjudicator pools. This arrangement keeps quali ed clinicians in a
de ned, accountable role with a record a ached to it rather than removing them from the loop.

Q22 and Q23 — Scaling re-benchmarking to the modi ca on; PCCPs when modi ca ons cannot be
fully prespeci ed. Bind valida on records to model and policy versions, preserve baselines, and retest in
propor on to the scope of change. Where speci c updates cannot be prespeci ed, prespecify behaviorbased triggers instead (Recommenda on 5), with transparent excep on repor ng and renewed tes ng
when the device's behavioral boundaries move. Categories of change that leave agreement on the xed
probe set within its prespeci ed band are candidates for management within the sponsor's quality

Page 19 of 26

fi
ti
ti
ti
ti
fi
ti
ti
fi
ti
fi
ti
ti
ti
ti
fi
ft ti ti
ti
ti
ti
ti
fi
ti
fl
ti
ti
ti
ti
ti
ti
ti
ti
fi
ti
fi
fi
tti
ti
fi ti
ti
ff
ff ti
ti
tt
ti
ti
ti
ti
fi
ti
ti
ti
fi
ti
ti
ti
ti
ti
ti
ti
fi
fi
ti
ti ti
ti
ti
fi
ti
ti
ti
fi
ti
ti
fi fi
 management system; a step change outside the band is a candidate for PCCP-governed re-evalua on or
a new submission, depending on the func on's posi on on the two-axis framework.

Q24 — Detec ng third-party developer-ini ated model changes. Contractual no ca on is necessary
but not su cient. The manufacturer needs a technical signal that res on behavior, not on
announcements. Two such signals are a step change in agreement rate on a xed probe set with query
mix and adjudicators held constant, and a rise in stored di erences between new and previously
validated answers to seman cally similar queries. Both are triggers for inves ga on, not proof of a
speci c cause: a shi can also come from pa ent mix, case complexity, promp ng, retrieval content, or
the adjudicators themselves, and a model update can in principle occur without a detectable aggregate
shi .

Q25 — Founda on Model MAFs. They will be most useful if they include a commitment to per-inference
audit-log availability (already listed in footnote 24) and if CDRH accepts device-level valida on logs as an
alterna ve mechanism where a developer will not disclose. A valida on log for a given model version in
the device's intended-use context is evidence about the model in the device, which is what CDRH says it
wants to evaluate, and it reduces dependence on voluntary disclosure without replacing it.

Q26 — Agen c func ons. Dis nguish valida ng a generated recommenda on or proposed plan from
authorizing a device ac on. An independent blinded panel can serve as the checkpoint on a proposed
ac on sequence before execu on; it should not be the sole gate on irreversible or high-consequence
ac ons, which require human authoriza on, operator override, and accountable logs.

Sec on 5. Limita ons, licensing, and availability

5.1 Limita ons
We state these so that CDRH can weigh our answers appropriately.

• What valida on measures. By design, the architecture measures whether an output agrees with
what independent models would produce under blinded condi ons. That is a strong signal
against the confabula ons and idiosyncra c errors that are the most common failure mode of
genera ve models. It is not a subs tute for clinical con rma on; a "validated" marker means the
prespeci ed valida on procedure passed. Clinician adjudica on of a sample remains the
reference for medical correctness.

• No implementa on or outcome data. Ramsee 1 LLC does not have a working implementa on
and has no compara ve outcome data. The recommenda ons in Sec on 3 are structural
requirements that can be speci ed now; whether this architecture, or any other, meets them in
prac ce is a ma er for prespeci ed evalua on against alterna ves.

• Correlated error. Validators trained on overlapping data can agree on the same wrong answer.
No architecture guarantees sta s cal independence by design, which is why Recommenda on 2
requires that error correla on be measured and reported rather than assumed. The
speci ca on's illustra ve error-rate arithme c assumes independent validators and should not
be read as a performance claim.

• Clinical ming. Mul -validator consensus takes me. The validator count, model size, and reveal
window must be engineered to each func on's clinical meline. For the most me-cri cal

Page 20 of 26

ti
ti
ti
ti ti
fi
ti
ti
ti
ti
ti
fi
ti
ti
ti ti
ti
ti
ti
ti
ff
ti
ti
fi
ti
ti
ti
ti
ti
ti
ti
ti
ti ti
ti
ti
ti
fi
ti fi
ti
ti
ti
ti
ti
ti
ti
ti
ti ti
ti
ft
ti
tt ti
ti
ti ti
ti
ti
ffi
ti
fi
ti
ti ti
fi
fi
ti
ti
ft
ti
ti fi
 func ons, valida on can run alongside presenta on of the output rather than ahead of it, with
the result available for review and the output marked accordingly.

• Threshold jus ca on. The consensus threshold is a safety parameter. A sponsor should jus fy
it per query category with the same rigor as any acceptance criterion, and CDRH may wish to see
the sensi vity of valida on outcomes to the threshold.

• Protected health informa on. The record should carry hashes and metadata rather than clinical
text wherever possible, with restricted access and governed reten on. The private-ledger
embodiment keeps the record inside the ins tu on's trust boundary; any shared deployment
should have explicit PHI controls in its monitoring plan.

• Veri ca on arrangements. Tamper evidence is strongest when the record is anchored outside
the sponsor's sole control and when a regulator or auditor has a de ned way to verify it. CDRH
should expect sponsors to describe who can write to the record, who can verify it, and how.

• Scope. This comment addresses the reliability of discrete outputs. Direc veness, escala on,
mul -turn dri , subgroup performance, and agen c ac on sequences are addressed only brie y
and do not rest on the patent.

5.2 Licensing
Ramsee 1 LLC wants the requirements in Sec on 3 adopted broadly, and recognizes that a safeguard
improves pa ent safety only if sponsors can use it. The recommenda ons are dra ed in func onal terms
that open-source and compe ng implementa ons can sa sfy. Should any requirement CDRH adopts, or
any consensus standard that follows from it, read on our patent, Ramsee 1 LLC's inten on is to make
licenses available to all implementers, including open-source projects and compe tors, on fair,
reasonable, and non-discriminatory (FRAND) terms, with speci c terms to be agreed with each
implementer, and to make the formal FRAND declara on any standards body requires at the me it is
requested. It is our inten on that intellectual property not stand in the way of adop on. We raise the
subject so that CDRH has it on the record.

5.3 Availability
Ramsee 1 LLC is a small en ty without development sta . We o er this comment as a contribu on to the
record, not as the beginning of a program. Two things the signatory could o er in her individual capacity
as a physician-scien st, subject to her other obliga ons and en rely at her discre on. First, she could
prepare a prespeci ed compara ve protocol for the assessment outlined in Recommenda on 9, in a
single use case such as renal dose adjustment, and make it available to CDRH, a Collabora ve
Community, or an academic group willing to run it. Second, she would consider par cipa on in any
standards-development or Collabora ve Community e ort that takes up adjudicator independence or
valida on records for genera ve SI-enabled devices. Neither statement is an undertaking to any
par cular meline or body, and each remains subject to her agreement at the me. The signatory is
available to the Digital Health Center of Excellence and to any sponsor or ins tu on interested in these
ideas at the contact details below.

Page 21 of 26

fl
ti
ti
ti
ti ti
ti
ti
ti
ti ti
ti ft
ti
ti
ti
ti
ff
ti
ti
fi
ti
ff
ti
fi
ti
ff
ff ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
fi
ti
ti
fi
ft
ti
ti
ti
ti
ti
ti
ti
fi ti
ti ti
 Respec ully submi ed,

Miera Rechtscha en, MD, PhD

Co-inventor, U.S. Patent 12,683,789 B1

On behalf of Ramsee 1 LLC, New York, NY

Email: ramsee1llcusa@gmail.com

Phone: 917-280-6000

A achment A: U.S. Patent 12,683,789 B1. Sources: CDRH discussion paper, h ps://www.fda.gov/media/
194242/download; docket FDA-2026-N-7874 on Regula ons.gov; Execu ve Order 14434 (Sept. 29,
2026); patent text, h ps://patents.google.com/patent/US12683789B1/en.

Page 22 of 26

tt
ti
ti
tt
tt
ff
tf
tt
 Appendix A. Claim elements of U.S. Patent 12,683,789 B1 and the ques ons they
speak to
Claims 1, 15, and 16 are the independent claims (system, method, and storage medium). Claims 2–14
depend from claim 1. The table uses the patent's own claim language in the rst column and the
discussion paper's vocabulary in the others.

Claim element What it does, in CDRH's terms Discussion-paper
ques on
Claim 1: encrypt the query and the answer; record Fixes the exact input and Q1 traceability;
them on the blockchain of a truth token before output in tamper-evident form Q25 audit log
valida on before any adjudicator sees
them
Claim 1: distribute the truth token to one or more Sends the iden cal query to an Q16
AI valida on nodes independent adjudicator panel independent
adjudica on
Claim 1: each node generates an individual Commit-reveal blinding: no Q16
valida on answer encrypted with a reveal me; adjudicator sees another's informa onal
decrypt when the reveal me expires answer before commi ng its independence;
own Q20 supervisor
reliability
Claim 1: the answer is validated when a consensus Prespeci ed acceptance Q19, Q20
parameter based on validator agreement sa s es criterion applied per output postmarket
a predetermined threshold monitoring
Claim 1: generate a new block indica ng the Immutable per-output Q1, Q25
answer is validated valida on record
Claim 1: determine a performance score for each Adjudicators are themselves Q20 reliability of
node and an overall score; distribute a reward in measured and ranked the supervisory
propor on agent
Claim 2: valida on nodes form a federated Structural and opera onal Q16
environment, each on separate compu ng independence; adjudicators independence;
infrastructure can be run by di erent Q21 shared
ins tu ons ecosystem
Claims 3–5: similarity metric between each Seman c rather than exact- Q14
valida on answer and the answer; threshold match comparison; threshold comparators;
based on the query or the node tunable by query type Q19 triggers
Claims 6–7: cluster valida on answers into Majority-cluster test with a Q8, Q19
agreeing and disagreeing clusters; threshold may risk-propor onate threshold
depend on validator count, query type, category,
di culty, or historical accuracy

Page 23 of 26

fi ti tti ti
ff
ti ti
ti ti
ti
ti
ti
ti
ti ti
ti
ti
ti
ti
ti
ti ti ti ti fi fi
ffi ti
ti
 Claim element What it does, in CDRH's terms Discussion-paper
ques on
Claims 8–9: details of valida on recorded on The record carries the full vote, Q1, Q21, Q24,
chain, including nodes sent to, number agreeing, not just the verdict Q25
number disagreeing, iden ty of nodes, historical
accuracy
Claim 10: mestamp of valida on recorded on Enables me-series analysis of Q19, Q24 dri
chain agreement detec on
Claims 11–12: performance score based on speed Supervisor reliability is Q20
and accuracy, each weighted quan ed with explicit weights
Claim 13: reward comprises cryptocurrency One embodiment; not —
proposed for regulated
deployments
Claim 14 (and claims 15–16): compare each Deltas between answers to Q22–Q24
validated answer to previously stored validated similar queries over me are change
answers; store a pointer and the di erences when captured explicitly detec on
similar

Page 24 of 26

ti
ft
ti
ti
fi
ti
ti
ti ti ti ti ti ff
 Appendix B. Notes
All references are to the claims of U.S. Patent 12,683,789 B1 unless a speci ca on passage is given.

1. Claim 1 (and claims 15–16): the query and the answer are encrypted and recorded on a
blockchain before valida on; claim 15 adds that they are independently hashed or compressed.

2. Claim 2 (federated environment, separate compu ng infrastructure); speci ca on, descrip on of
FIG. 3 (di erent model architectures or training data sets to reduce systemic bias).

3. Claim 1: each valida on answer is encrypted with a reveal me and decrypted only when the
reveal me expires.

4. Claim 1 (consensus parameter and predetermined threshold); claims 3 and 6 (similarity metric;
agreeing and disagreeing clusters).

5. Claims 5 and 7: the threshold may depend on the query or node, and on validator count, query
type, category, di culty, or historical accuracy.

6. Claim 1 (performance score per node and overall score); claims 11 and 12 (speed and accuracy,
each weighted).

7. Claims 8, 9, and 10: details of valida on and mestamp recorded on chain.

8. Claim 14 (and claims 15–16): similarity to previously stored validated answers; pointer and
di erences stored when similar.

9. Speci ca on, paragraph beginning "In some example embodiments, the valida on system may
be con gured to operate in an isolated, standalone environment": private or local ledger, opensource models, reward simulated or internalized.

10. Claims 1, 11, 12, and 13. That a reputa on score or rou ng priority sa s es the reward element
of claim 1 is the authors' reading of the claim language; nothing in this comment's
recommenda ons depends on it.

Disclaimer
This comment is public commentary in response to CDRH's request for feedback and re ects the views of
the signatory and of Ramsee 1 LLC as of the date of submission. It is not legal, regulatory, medical, or
engineering advice. The architecture it describes has not been evaluated by FDA, and no FDA review,
clearance, approval, or endorsement is claimed or implied. Descrip ons of how it might func on in a
clinical se ng are illustra ve, and performance in any deployment would depend on implementa on,
valida on, and clinical oversight that this comment does not supply.

Statements about U.S. Patent 12,683,789 B1 are the authors' own characteriza on, o ered to help CDRH
understand the architecture, and are not a legal opinion on claim scope, validity, or infringement.
Descrip ons of what the claims do or do not require, and of which features are deployment controls
rather than claim elements, are not intended as, and should not be read as, a disavowal, limita on, or
construc on of any claim. Nothing here grants or implies a license or waives any right. The signatory
submits in a personal and corporate capacity only, not on behalf of any hospital, university, employer, or

Page 25 of 26

ti
ti
ti
fl
ff
ti
ti
ti
ti
fi
fi
fi
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ffi
ti
tti
ti
ti ff
ti
fi
ti
ti
fi
ff ti
professional society, and Ramsee 1 LLC, its members, and the signatory disclaim liability for any reliance
on this comment to the extent permi ed by law.

Page 26 of 26

tt