Solutions by Jewel (Jewel Darlington)

Solutions by Jewel submits the attached comments on Questions 1 and 18–26. Five recommendations: (1) define a versioned device configuration record covering model version, prompts, retrieval sources, guardrails, orchestration, tools and integration pattern, and tie every benchmarking, confirmation and postmarket result to it; (2) treat foundation model changes made by the model developer as modifications, detected through version pinning, runtime identifier checks and sentinel re-benchmarking, with a prespecified hold or restricted mode and named authority; (3) prespecify reassessment triggers, including changes in downstream use, and condition reduced premarket evidence on a monitoring program operational and tested at launch; (4) govern supervisory agents as configured systems with their own validation, independence and change control; (5) for agentic devices, enforce an authorized action set outside the model, keep a per-execution action trace, and test stop and recovery capability. Full comments attached.

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

Submitted to: U.S. Food and Drug Administration, Center for Devices and Radiological Health,
Digital Health Center of Excellence
Submitted via: Regulations.gov, Docket No. FDA-2026-N-7874
Submitted by: Solutions by Jewel
Contact: Jewel Darlington, Chief AI Governance Officer & Founder
Email: governance@solutionsbyjewel.com
Website: solutionsbyjewel.com
Date: October 17, 2026

Respondent Context and Summary
Solutions by Jewel (SBJ) is an AI governance advisory firm. Its work concerns how organizations
establish, record and maintain authority, evidence and accountability for AI systems as those systems
and their operating conditions change. SBJ’s work centers on governance architecture and evidence
practice. These comments therefore address the governance questions in the discussion paper [1]:
change control for configured GenAI systems, changes initiated by third-party foundation model
developers, postmarket reassessment, machine-based supervisory agents and agentic devices. They
respond to Discussion Questions 1 and 18 through 26.
SBJ supports the paper’s total product life cycle orientation and its proposal that the premarket
competency-based assessment serve as the baseline for evaluating later modifications (Section VI.C).
That proposal depends on a precondition the paper raises and leaves open: the ability to identify exactly
which device configuration a benchmarking result, a clinical confirmation result or a postmarket
observation describes. SBJ’s five recommendations build on that precondition:
1. Define a versioned device configuration record and tie every item of evidence to it (Q19, Q21,
Q22, Q23).
2. Treat developer-initiated foundation model changes as modifications, detected through version
pinning, runtime identifier checks and sentinel re-benchmarking, with a prespecified hold or
restricted mode while evaluation is pending (Q24, Q25).
3. Prespecify reassessment triggers, including changes in how outputs are used downstream, and
condition reduced premarket evidence on a monitoring program that is operational and tested at
launch (Q18, Q19, Q21).
4. Govern machine-based supervisory agents as configured systems with their own validation,
independence and change control (Q20).
5. For agentic devices, define and enforce an authorized action set, keep an action trace for each
execution, and test the ability to stop execution and address actions already committed (Q1, Q26).

Page 1 of 8
1. SBJ-FDA-01: A Device Configuration Record as the Anchor for Change Control
Discussion paper reference: Sections II, V.B and VI.C; Questions 19, 21, 22 and 23.
The paper observes that GenAI-enabled devices can change through the underlying model, prompts,
retrieval strategies, guardrails, orchestration logic and user interface (Section II), and it proposes that
benchmarking evaluate the device in its deployed or representative configuration (Section V.B).
Re-benchmarking against a premarket baseline yields usable evidence when both the baseline
configuration and the modified configuration are identifiable.
Recommendation. CDRH should describe a device configuration record: a versioned identifier for
each deployable configuration of a GenAI-enabled device function, covering at minimum:
(a) foundation model provider, model name and version or dated snapshot identifier, and the means
of confirming it at runtime;
(b) fine-tuning or adapter version, where applicable;
(c) system prompts and prompt templates;
(d) retrieval sources and corpus version;
(e) guardrails, content filters and refusal policies, including those applied by the foundation model
provider;
(f) orchestration logic, tools and tool permissions;
(g) inference parameters that affect output variability;
(h) user interface elements that present outputs, uncertainty or escalation messages; and
(i) the intended integration pattern: how outputs reach users and downstream clinical systems.
Each benchmarking result, clinical confirmation result, postmarket sample and complaint record would
reference the configuration record in effect. A modification is then any change to a recorded element,
and its scope can be stated element by element.
Scaling evidence to the change (Q22). SBJ recommends that CDRH scale required evidence by the
elements affected and by the function’s position on the two-axis framework:
• Quality management system documentation: changes to elements assessed as having negligible
expected effect on safety-relevant behavior, supported by regression runs of the safety elements
S.1 through S.3 and R.1 against prespecified tolerances.
• PCCP coverage: prompt, retrieval-corpus and guardrail updates, and foundation model version
updates within the same provider and model family, each with a prespecified re-benchmarking
subset, acceptance criteria and rollback condition.
• FDA review before implementation: changes that move a function on either axis of the two-axis
framework, alter the intended use, add a tool or action capability, or produce a result outside
prespecified acceptance criteria on any safety element or on R.2 subgroup performance.
Unspecified future changes (Q23). A PCCP [2] can prespecify the change classes, the configuration
elements each class may touch, the re-benchmarking protocol and acceptance criteria for each class,
and the rollback procedure. That structure accommodates future modifications whose specific content
is unknown at authorization.
Changes in downstream use (Q21). A deploying site may route an informational output directly into
an order workflow or an automated patient message. That integration by itself moves the function
toward the action-directing or action-taking end of the activity axis. SBJ recommends that labeling and
deployment agreements require deployers to notify the manufacturer before using outputs in a
materially different way, and that the manufacturer record the notice against the configuration record

Page 2 of 8
and determine whether reassessment is required. The manufacturer remains accountable for that
determination, with deployer notices as one of its inputs.

2. SBJ-FDA-02: Foundation Model Changes Initiated by the Model Developer
Discussion paper reference: Sections VI.C and VII.A; Questions 24 and 25.
Detection. SBJ recommends four complementary mechanisms, each recorded in the device
configuration record:
1. Version pinning to a dated model snapshot where the provider offers one.
2. Runtime identifier capture: logging the model identifier returned with each provider response and
alerting on any mismatch with the configuration record.
3. Sentinel re-benchmarking: a fixed, sequestered subset of safety-critical test cases drawn from S.1,
S.2, S.3 and R.1, run on a defined cadence and after every provider notice, with prespecified
tolerances. Sentinel testing also detects behavior changes made under an existing model identifier,
such as provider-side filter or safety-tuning updates.
4. Contractual commitments: advance notice of behavior-affecting changes, published deprecation
schedules, retention of pinned versions for a minimum period, and access to provider records
relevant to complaint investigation.
Evaluation and response. A developer-initiated change is a modification and follows the classification
in SBJ-FDA-01. The PCCP or quality procedure should prespecify what the device does between
detection and completed evaluation: remain on the pinned version; or, where the pinned version is
unavailable, operate in a predefined restricted mode, such as routing outputs to clinician review,
disabling action-directing functions or suspending the function. The procedure should name the role
with authority to place the device in restricted mode and the role that authorizes return to full operation
once re-benchmarking meets acceptance criteria. Each placement into restricted mode and each return
to full operation is a material governance determination, recorded with the configuration, the trigger,
the evidence relied upon and the approving role [5], [11]. Return to full operation is authority newly
scoped to the evaluated configuration, which SBJ’s architecture calls Derived Authorization [3].
Version deprecation warrants specific treatment because it forces a change on the provider’s schedule;
a PCCP can prespecify the migration protocol in advance.
Foundation Model MAF content (Q25). Footnote 24 lists update notification commitments and audit
log availability. SBJ recommends three additions: (a) the provider’s version-identifier policy, including
whether the identifier changes for every behavior-affecting update, safety tuning and system-level
filters included; (b) the deprecation and retention schedule for dated versions; and (c) notification lead
time and channel. To keep files current, each MAF would carry an effective date, and the holder would
amend it whenever any of these commitments changes. A sponsor could then confirm the commitments
in force for the configuration it references. Standard disclosure through one confidential file may also
reduce the repeated individual requests model developers receive from sponsors, which gives
developers a practical reason to participate.

3. SBJ-FDA-03: Reassessment Triggers and Conditions for Reduced Premarket Evidence
Discussion paper reference: Sections VI.A and VI.B; Questions 18, 19 and 21.
Triggering events (Q19). SBJ recommends that CDRH describe a minimum set of events that start
reassessment, in addition to a fixed periodic cadence scaled to the function’s position on the two-axis
framework:
• any change to the device configuration record;

Page 3 of 8
 • a provider notice, a runtime identifier mismatch or a version deprecation;
• sentinel or periodic benchmarking results outside prespecified tolerance;
• a new deployment context, including a new site type, patient population, language or clinical
system integration;
• a material change in how outputs are used downstream (SBJ-FDA-01);
• complaint, adverse event or clinician-review findings meeting a prespecified threshold; and
• a change in a clinical guideline relied upon for element E.1.
Conditions for accepting greater premarket uncertainty (Q18). SBJ recommends that reduced
premarket evidence be conditioned on a monitoring program that, at the time of authorization:
(a) is operational, with triggers, thresholds and sampling prespecified;
(b) ties each monitoring result to a device configuration record;
(c) names the role with authority to restrict or suspend the device function and the role that
authorizes resumption;
(d) has demonstrated through a documented test that restriction or suspension can be executed within
a stated time; and
(e) preserves records of adverse findings, interventions and their disposition for FDA inspection.
Postmarket monitoring corrects course after a signal appears. Where a function is action-taking,
high-consequence and irreversible, the opportunity for correction is limited, and SBJ recommends that
CDRH apply full premarket evidence expectations to those functions.
Shared ecosystem roles (Q21). Clinicians, healthcare institutions and professional societies can
contribute signals and review samples. The manufacturer’s procedure should define how each external
signal is received, recorded against a configuration record and dispositioned, so that every contribution
enters one record under manufacturer accountability.

4. SBJ-FDA-04: Machine-Based Supervisory Agents
Discussion paper reference: Sections V.B.2 and VI.A; Question 20.
The paper already applies its independence expectations to expert adjudicators that are themselves
LLMs (Section V.B.2). SBJ recommends that CDRH extend those expectations to supervisory agents
used in postmarket monitoring, and that a supervisory agent:
(a) have its own configuration record and change control;
(b) be validated against a clinician-adjudicated sample before use and at defined intervals, with its
detection rate for safety-critical failures reported;
(c) be independent of the device’s foundation model provider where feasible, with a higher rate of
clinician review where independence is infeasible;
(d) be limited to detection, scoring and escalation, with any restriction of the device carried out by a
named human role or a prespecified rule; and
(e) have its own changes treated as triggers for revalidation, since a change to the supervisor changes
what the monitoring program can detect.

Page 4 of 8
5. SBJ-FDA-05: Authority, Traceability and Stop Capability for Agentic Devices
Discussion paper reference: Sections IV, VII.B and Appendix A (A.1); Questions 1 and 26.
Element A.1 evaluates whether an agentic device recognizes when a planned action sequence would
exceed its intended use or safety envelope and complies with human-oversight checkpoints. SBJ
recommends that CDRH pair that behavioral evaluation with four design and evidence expectations:
1. Authorized action set. The submission defines, for each agentic function, the permitted actions,
tools, target systems, data access, required human checkpoints and stop conditions. A permission
layer outside the model enforces the set, so the boundary holds when model behavior varies.
Benchmarking then tests both the model’s recognition of the boundary (A.1) and the permission
layer’s enforcement of it.
2. Downstream authorization. Where an agent writes to a clinical system or controls another medical
device, the receiving system applies its own authorization check to the action.
3. Action trace. Each execution produces a record of the execution instance, the configuration record
in effect, inputs, planned steps, tool calls and returned outputs, human checkpoint decisions with
the identity of the approver, and final actions with their downstream effects. The trace supports
clinician review, complaint investigation and the traceability dimension raised in Question 1. The
trace belongs in the device’s operational logging, and material determinations drawn from it, such
as suspension, restart or restoration of authority, belong in a governance decision record [5], [10].
4. Stop and recovery. A named role can halt execution independently of the agent’s own decision
process, and the capability is tested before deployment. Halting execution leaves in place actions
already committed to other systems, so the procedure also states how committed actions are
identified, reversed or contained.
Acceptance criteria and oversight (Q26). SBJ recommends a prespecified criterion of zero executed
actions outside the authorized set for irreversible or high-consequence actions in benchmarking, with
every attempted out-of-scope action reported and shown to have been blocked by the permission layer.
Postmarket, the action trace allows sample-based clinician review (Section VI.A) to cover complete
action sequences, and the SBJ Decision Record V2.0 [5] provides fields for the restart or resumption
decision that follows any stop.
Risk framework dimensions (Q1). SBJ supports adding reversibility and traceability to the two-axis
framework. An irreversible action raises the consequence of an incorrect output. An output traceable to
its source materials and to its device configuration gives users and reviewers a practical means to detect
and correct errors. SBJ also recommends that CDRH consider system reach for agentic functions: the
clinical systems, records and other devices an agent can affect. The SBJ Executive AI Governance
Decision Matrix [8] scales governance with a system’s autonomy, impact, authority and access, and its
four autonomy levels (assist, recommend, execute with approval, controlled autonomous action)
correspond closely to the paper’s activity axis.

6. SBJ Resources Referenced
These recommendations draw on the following SBJ resources, published at solutionsbyjewel.com and
verified against the live site on October 17, 2026:
• SBJ AI Governance Architecture V1.0 [3]: Execution Instance Identity and Continuous
Authorization (SBJ-FDA-01 to -03); Authority Envelope, Independent Downstream Authority,
Decision-to-Action Authority Traceability, Independent Termination Authority, Safe State and
Adverse Evidence Preservation (SBJ-FDA-02, -05); and interpretation ATC1-001, under which
material changes in how AI outputs are consumed, acted upon or embedded in downstream
workflows count as changes in consequence and exposure in their own right (SBJ-FDA-01, -03).

Page 5 of 8
• V1.0 validation evidence [3]: SBJ benchmarked V1.0 against six publicly documented real-world
AI cases (Replit, Anthropic, Microsoft, Salesforce, Waymo and Google DeepMind), producing
185 applicable determinations: 160 PASS, 24 PARTIAL, 0 FAIL, 1 INSUFFICIENT EVIDENCE
and 7 NOT APPLICABLE, reported as determination counts. Adversarial Testing Cycle 1 found
zero confirmed architectural gaps and one ambiguity, ATC1-001, resolved through existing
architecture. V1.0 carries the status Validated with Material Limitations within the tested scope.
Two of its stated limitations bear directly on Question 24: governance-grade execution identity and
version binding, addressed in V2.0 by AC-04, and shared-responsibility evidence allocation,
addressed in V2.0 by AC-07. SBJ conducted this evaluation independently from public
documentation; the referenced organizations appear solely as sources of public evidence.
• SBJ AI Governance Architecture V2.0 [4]: AC-01, Authorization Invalidation Trigger Semantics
(SBJ-FDA-02, -03); AC-03, Delegation and Branch-and-Merge Provenance, and AC-04,
Execution Identity and Material Version Binding (SBJ-FDA-01, -02, -05); AC-05, Evidence
Sufficiency as an Authorization Condition (SBJ-FDA-03, -04); the assurance-claim validity
requirement (SBJ-FDA-01, -03); AC-07, shared-responsibility deployment, governed through
implementation, contractual, procurement and evidence-access controls (SBJ-FDA-02); and the
principle that committed downstream effects require their own reversal or containment after
technical execution ends (SBJ-FDA-05).
• SBJ AI Governance Decision Record V2.0 [5]: records governance determinations through
LOCATE, ASSIGN, RECORD and SCALE. Its conditional fields support the records
recommended here: Material Version / Configuration Reference and Execution Instance Identity
Reference (configuration record); Trigger Source, Authorization State Change and Follow-up /
Reassessment Condition (reassessment); Evidence Sufficiency Determination and
Evidence-Sufficiency Authority (monitoring evidence); Permissions / Credentials / Tool-Authority
Reference, Downstream Acceptance / Execution Reference and Externally Committed
Consequence Reference (agentic actions); and Restart / Resumption Decision. Profile G,
Shared-Responsibility Deployment, applies to devices built on third-party foundation models. Its
public technical package [13] provides JSON Schema 2.0.0, validation rules, a field dictionary and
conformance fixtures, so records can be produced and checked in machine-readable form. The
package completed SBJ’s internal technical conformance suite with 18 of 18 expected fixture
outcomes, which SBJ classifies as internal technical conformance.
• Agent Governance [10]: SBJ’s agent governance guidance follows the execution chain: identity of
the acting instance; delegation across parent, child, spawned and chained execution; authority
determined separately from technical capability; environment changes as reassessment conditions;
evidence that supports reconstruction; and independent means to suspend, revoke, contain or
terminate authority. It assigns tool calls, traces and telemetry to operational systems and material
governance determinations to the Decision Record (SBJ-FDA-05).
• Authorization & Accountability [11]: frames the authorization question applied throughout these
comments: whether a system may perform an action, in a given environment, at a given time,
under a given authority, with sufficient evidence, and who remains accountable. It identifies
suspension, revocation, restart, resumption and restoration of authority as determinations for a
durable governance record (SBJ-FDA-02, -03).
• AI Decision Record Template [6]: a two-page practitioner form with fields for model/version,
environment, authorized and out-of-scope actions, required human approval, escalation condition,
authorization source, logs/audit trail, evidence location, reassessment trigger, material change and
continued authorization.

Page 6 of 8
 • AI Agent Governance Checklist [7]: a pre-deployment and authorization review covering agent
identity with model and version, permissions, authorized actions, tools and integrations, human
oversight with override or shutdown capability, logging and evidence, monitoring, and
reassessment triggered by model, tool, permission or purpose changes (SBJ-FDA-02, -05).
• Executive AI Governance Decision Matrix [8]: classification by use case, impact and autonomy
level, with governance tiers that add reassessment triggers and documented approval to operate as
autonomy and impact rise (SBJ-FDA-03, -05).
• SBJ V2.0 Research Evidence Cohort [9]: verified external evidence retained in the V2.0 research
record, with source lineage published in the V2.0 External Evidence & Source Register [12].
Entries most relevant here include enterprise agent identity, permission and tool-authority
documentation (Microsoft / MCP); coding-agent verification and recoverability research (Verifier
Tax, EvoUndo and τ-bench); the NIST NVD AI-agent enrichment workflow, which moves from
evidence production through validation and human review to publication, withholding, correction
or revocation; and GovRAMP external authorization and continuous assurance, covering product
and provider responsibility and the evidence lifecycle. Consistent with the cohort’s attribution
boundary, the listed people and organizations appear solely as external sources of evidence.
SBJ offers these resources as illustrations of the records and controls recommended above. Their
application to medical device development, FDA premarket review and clinical settings would call for
domain-specific validation.

Closing
SBJ appreciates the opportunity to comment and supports CDRH’s collaborative approach to this topic.
A versioned configuration record, prespecified triggers, named intervention authority and per-execution
records would give CDRH, manufacturers and deployers a common basis for the re-benchmarking,
postmarket monitoring and agentic oversight the paper describes. SBJ would welcome further
engagement as CDRH develops its approach.

Respectfully submitted,
/s/ Jewel Darlington
Chief AI Governance Officer & Founder
Solutions by Jewel
governance@solutionsbyjewel.com

References
[1] U.S. Food and Drug Administration, Center for Devices and Radiological Health. Considerations for the
Regulation of Generative AI-Enabled Medical Devices: Discussion Paper and Request for Feedback. August
18, 2026. https://www.fda.gov/media/194242/download
[2] U.S. Food and Drug Administration. Marketing Submission Recommendations for a Predetermined Change
Control Plan for Artificial Intelligence-Enabled Device Software Functions. Final guidance, December
2024.
[3] Solutions by Jewel. SBJ AI Governance Architecture V1.0. 2026.
https://solutionsbyjewel.com/sbj-ai-governance-architecture-v1
[4] Solutions by Jewel. SBJ AI Governance Architecture V2.0. 2026.
https://solutionsbyjewel.com/ai-governance/architecture/
[5] Solutions by Jewel. SBJ AI Governance Decision Record V2.0. 2026.
https://solutionsbyjewel.com/ai-governance/decision-record/

Page 7 of 8
[6] Solutions by Jewel. AI Decision Record Template. 2026.
https://solutionsbyjewel.com/ai-decision-record-template
[7] Solutions by Jewel. AI Agent Governance Checklist. 2026.
https://solutionsbyjewel.com/sbj-ai-governance-architecture-v1/ai-agent-governance-checklist
[8] Solutions by Jewel. Executive AI Governance Decision Matrix. 2026.
https://solutionsbyjewel.com/sbj-ai-governance-architecture-v1/executive-ai-governance-decision-matrix
[9] Solutions by Jewel. SBJ AI Governance Architecture V2.0 Research Evidence Cohort. 2026.
https://solutionsbyjewel.com/ai-governance/research/sbj-v2-research-evidence-cohort.pdf
[10] Solutions by Jewel. AI Governance: Agents. 2026.
https://solutionsbyjewel.com/ai-governance/agent-governance/
[11] Solutions by Jewel. AI Governance: Authorization & Accountability. 2026.
https://solutionsbyjewel.com/ai-governance/authorization-accountability/
[12] Solutions by Jewel. SBJ AI Governance Architecture V2.0 External Evidence & Source Register. 2026. http
s://solutionsbyjewel.com/ai-governance/decision-record/sbj-ai-governance-architecture-v2-external-evidenc
e-source-register.pdf
[13] Solutions by Jewel. SBJ AI Governance Decision Record V2.0 Technical Package (JSON Schema 2.0.0).
GitHub, 2026. https://github.com/solutionsbyjewel/sbj-ai-governance-decision-record

Page 8 of 8