Ziqqur (Lambert Ninteman, Shelly LaPointe)

See attached file(s)

Ziqqur hello@ziqqur.ai
ziqqur.ai
Answers you can prove.

Agentic Data Systems (d/b/a Ziqqur)
Ziqqur.ai

October 19, 2026

Submitted electronically via Regulations.gov

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

Dear Dr. Tarver and Dr. Abramson,

On behalf of Ziqqur, we appreciate the opportunity to respond to Docket No. FDA-2026-N-7874,
Considerations for the Regulation of Generative AI-Enabled Medical Devices: Discussion Paper and
Request for Feedback [1]. We thank FDA’s Center for Devices and Radiological Health and Digital
Health Center of Excellence for engaging stakeholders as the Agency considers approaches to
evaluating these technologies throughout the total product life cycle.

Ziqqur supports innovation that advances patient care while preserving safety, effectiveness, and
accountability. Our central position is that generative and agentic AI used in medical devices
should operate within independently enforced, verifiable controls proportionate to the risks of the
intended use. We also believe that each use of a generative component should be justified by its
benefit to patients, weighed against its risks. Where a deterministic approach can perform a
function, it should be used; where a manufacturer chooses a generative approach instead, the
reason should be documented in the design files. We offer recommendations to help FDA translate
that principle into practical design, evaluation, and oversight expectations.

About Ziqqur

Ziqqur is a technology company guided by ethical AI, quality by design, accuracy, determinism,
trust, and traceability from a team with deep experience in healthcare product development and
manufacturing. We build trustworthy AI for high-consequence work: deterministic where it must
be, traceable by design, and accurate by proof. We believe AI used in patient care must be
approached from both perspectives at once: the quality and governance discipline of regulated
industry, and a working understanding of how the underlying technology actually behaves.

Too often, generative AI is applied as a black box, without regard for its fundamental properties.
Our guiding principle is that generative models should do only what only generative models can do;
everything else should be deterministic. Five commitments follow from that principle:

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 1
 Ziqqur

• Quality by design. Quality, safety, and security are built into requirements and architecture
from the start, not tested in at the end or added after release. Planning, requirements, and
risk analysis come before building; work proceeds in small, clearly defined units traced to
approved requirements; and work does not begin until roles, responsibilities, and
acceptance criteria are established.
• Accuracy. Claimed performance and benefits are hypotheses until they are measured. Our
review practice is grounded in falsifiability: checks are designed to find what is wrong rather
than to confirm what is hoped, and nothing proceeds that has been shown to be false.
Limitations are stated as plainly as capabilities.
• Determinism. Planning, sequencing, state, permissions, and acceptance decisions belong
in deterministic, version-controlled processes, not in a model’s context or memory. Where
generative output is used, it is kept apart from authoritative records until deterministic
checks and authorized review have accepted it, and the same verified inputs should
produce the same verified result.
• Trust. No one checks their own work. Just as the person who builds a part on a
manufacturing line does not sign off on it, every output is reviewed by an independent AI
Auditor or “checker”, human or AI. AI checkers are drawn from different model families or
vendors, so that AI developer models or “maker” and checker do not share the same blind
spots. Humans and AI agents work within one organizational structure, each with defined
independence, roles, qualifications, and permissions, and no one operates outside their
role. Judgment and consequential decisions remain with people.
• Traceability. Every output, decision, and change should be traceable to its sources, its
requirements, the configuration that produced it, and the evidence that it was verified, so
that results can be reconstructed, reviewed, and corrected.

We also believe trustworthy AI should be efficient AI. Using generative computation only where it
adds unique value reduces risk in ways that can be documented and demonstrated, and it also
reduces the cost, energy, and other resource demands of AI workloads.

Many functions now performed with generative AI can be performed deterministically instead. We
call this approach clockwork AI: post-generative deterministic AI that reverse-engineers many of
the capabilities of generative AI using purely deterministic methods. Like the gears of a clock, each
part has one defined function, and together the parts reproduce much of what a generative system
does. A generative model maps one input to many possible outputs; a clockwork system, given the
same input and configuration, gives the same output every time. Each function moved to
clockwork AI reduces the perceived need for generative AI. For that function, it reduces by design
risk that may come from generative output, such as fabricated content and results that cannot be
reproduced. Clockwork AI replaces a generative function with a deterministic one, bringing the
design closer to an inherently safe design. The deterministic controls recommended in the rest of
this response are different: they bound a generative function that the device retains.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 2
 Ziqqur

We adopted these commitments because we saw how often AI was being deployed without them,
and we wanted to build differently. Agentic Data Systems, Inc. (d/b/a Ziqqur) was formed as a
limited liability company in late 2024 to explore the development of AI technologies. We spent our
first year evaluating business opportunities that aligned with our mission and principles (quality by
design, accuracy, determinism, trust, and traceability) before committing to a technical direction.
In December 2025, the company converted to a Delaware C corporation, and development of our
initial technology began in January 2026. That deliberate start reflects how we work: define the
problem and the requirements before building.

Why Ziqqur Is Responding

Ziqqur recognizes both the potential benefits and the distinct risks of generative and agentic AI in
medical devices. Generative models produce outputs probabilistically: the same input can yield
different outputs, errors can be fluent and persuasive, and behavior can change with model
updates, prompt or retrieval changes, or adversarial input that the manufacturer did not anticipate.
Agentic systems add further risk because they can select tools, retrieve and write data, and take
actions with reduced opportunity for human review. When multiple agents interact, unchecked
errors can compound as each builds on the others’ output. A model also cannot reliably verify its
own work: a checker that shares the maker’s architecture, training data, or vendor is likely to share
its failure modes. Traditional verification approaches that assume fixed, repeatable software
behavior do not, by themselves, provide adequate assurance for these systems.

We do believe, however, these risks can be appropriately mitigated. In our experience, the most
reliable risk controls for generative and agentic AI are deterministic controls: rule-based
mechanisms that are architecturally independent of the generative model, that the model cannot
modify or bypass, and whose behavior can be specified and verified in the same way as
conventional device software. Examples include intended-use and scope boundaries; input and
output validation; hard limits on clinically consequential values; verification that outputs are
supported by authoritative sources; quarantine of generative output until it has been checked and
accepted; least-privilege authorization checks before any agentic action; human approval gates for
consequential or irreversible actions; version-locked configurations; tamper-evident audit records;
and tested fail-safe and rollback states. Deterministic controls do not make a generative model
deterministic. They make the device’s safety-relevant behavior bounded and verifiable even when
the model’s output is not.

Deterministic controls bound what a device can do; they do not address what routine reliance on
the device can do to the people who use it. Continuous exposure to a well-functioning automated
system, deterministic or generative, can erode a user’s own diagnostic or procedural skill over
time, reducing the very capability the system depends on for the cases it cannot catch. This effect,
sometimes described as deskilling [18], [19], is distinct from automation bias and is not addressed
by any control described above. We recommend that FDA encourage manufacturers to support
continued user competency through measures such as structured training on the device’s known

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 3
 Ziqqur

failure modes, medical device manufacturer (MDM) offered health care practitioner (HCP) and
health delivery organization (HDO) certification and offering features within devices that are
unassisted by AI to allow HCP training, as a complement to the deterministic controls described in
Appendix C. Ultimately, post market real world performance monitoring will be critical for MDMs,
but data is not always readily shared between HDOs and MDMs, even with Business Associate
Agreements (BAAs) in place. Ziqqur encourages FDA to partner with other HHS agencies to help
reduce the barriers for data sharing to ensure that products are safe and effective throughout the
product’s lifecycle. This could potentially allow MDMs to monitor for a decline in AI assisted and
unassisted performance and help quickly mitigate potential patient harm before it happens.

It is our position that deterministic controls should, in the future, be an expected and required
element of GenAI-enabled medical devices, proportionate to device risk. FDA’s experience with
cybersecurity offers a useful precedent. Cybersecurity was once treated largely as a matter of
manufacturer discretion but it is now an explicit premarket expectation for cyber devices under
section 524B of the Federal Food, Drug, and Cosmetic Act [17] and FDA’s associated guidance,
integrated into design controls, risk management, and the premarket submission. We believe
deterministic controls for generative and agentic AI warrant a similar path: a clear expectation that
they are designed in, documented, and verified for safety and effectiveness, rather than an optional
practice.

Consistent with these views, Ziqqur recommends that FDA:

• Establish an expectation for deterministic controls. Signal in future guidance that GenAIenabled devices should include independently enforced deterministic controls
commensurate with device risk and identify the information sponsors should provide about
them in premarket submissions.
• Limit generative functions to what requires them and what brings true clinical benefit.
Expect sponsors to justify the use of a generative component for each device function, and
to implement with non-AI or conventional, deterministic software any function that does
not require generation, such as calculations, thresholds, sequencing, and record-keeping.
• Require independence from the generative model. Expect that safety-relevant controls,
along with the reference data and acceptance criteria used to evaluate the device, are
protected from modification by the model or agent they constrain.
• Prohibit self-verification. Expect that generative outputs are not verified solely by the
same model or model family that produced them, and that sponsors use deterministic
checks, heterogeneous models, or qualified human reviewers, with an assessment of
common-mode failures between “maker” and “checker” models.
• Credit effectiveness, not presence. Treat deterministic controls as risk control measures
under existing risk management practice, with verification that each control performs as
intended in the actual deployment context, including under adversarial and multi-turn
conditions.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 4
 Ziqqur

• Bound agentic actions. Expect agents to operate under defined roles and least-privilege
permissions, as personnel do, with deterministic authorization before tool use or action,
human approval for consequential or irreversible actions, and defined safe states.
• Require end-to-end traceability. Expect sponsors to identify the full released
configuration (model, prompts, retrieval sources, tools, and controls), maintain device
state and decision records outside the model’s context, trace outputs to their supporting
sources, and keep records sufficient to reconstruct and investigate device behavior.
• Build on existing frameworks. Integrate these expectations into the Quality Management
System Regulation, design controls, ISO 14971 [14] and ISO/TS 24971-2 [15] risk
management, IEC 62304 [16] software life cycle processes, and existing cybersecurity
requirements, rather than creating a parallel regime, and support development of
consensus standards for deterministic controls.

To respond to FDA’s discussion questions, we will provide our technical position and guidance
traceable to applicable discussion question numbers within the appendix below. Ziqqur welcomes
continued collaboration with FDA and other stakeholders to develop practical, scientifically
grounded approaches that enable beneficial innovation while protecting patients.

Lambert Ninteman Shelly LaPointe
Chief Executive Officer, Ziqqur VP, AI Quality Innovation, Ziqqur
Ziqqur.ai Ziqqur.ai
lambert@ziqqur.ai shelly@ziqqur.ai

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 5
 Ziqqur

Appendix A
Characterizing the AI enabled system

A1) Evaluate the complete device function

Ziqqur agrees with FDA’s approach that evaluation begins with the intended device function, users,
clinical context, and consequences of failure. A model name or architecture does not establish the
device’s clinical role, autonomy, or risk. The same model can produce a draft that a clinician
reviews, deliver a recommendation directly to a patient, or propose an action to a connected
device. Each arrangement requires a different assessment of authority, oversight, and possible
harm.

Ziqqur recommends that manufacturers should identify the model and the surrounding system
together: data sources, prompts, retrieval mechanisms, persistent memory, tools, permissions,
interfaces, controls, human responsibilities, and update behavior per its intended use, indications
for use and clinical workflow. Our recommendations focus on AI enabled – device software
functions (AI-DSF) [2] that are software in a medical device (SiMD) or software as a medical device
(SaMD) where AI used within the manufacturer’s Quality Management System (QMS) is outside the
scope of this response. However, AI enablement in the QMS is equally important and critical,
especially for the development, deployment, maintenance & monitoring, decommissioning of AIDSF products and ensuring continues safety and effectiveness.

A2) Six complementary descriptive layers

To make that system-level description consistent and comparable across devices, we propose
describing an AI-enabled device software function along six complementary layers: model
architecture, training and adaptation, generative modality, augmented system, agentic pattern,
and interface. Each layer answers a different question a reviewer needs answered: what the model
is, how it was built or modified, what it produces, what it connects to, what it can decide or do, and
where and under whose control it runs. Each also points to different hazards and evidence needs.
Together, the layers give manufacturers and FDA a common vocabulary for the system inventory
recommended in A1. They also serve as the frame for the risk discussion in Appendix B and the
controls in Appendices C and D.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 6
 Ziqqur

The six layers below are classification dimensions. They are not a mandatory processing sequence, and their categories are not mutually
exclusive. A deployed system can have several descriptors within a layer.

Layer What it describes Why the distinction matters
Helps identify computational behavior
How computation is organized, such as transformer,
and component-specific evaluation
1. Model architecture recurrent or state-space, convolutional, dense, or mixtureneeds; does not confer clinical
of-experts designs
competence or action authority
How capabilities were learned or modified through Identifies provenance, specialization,
2. Training and
pretraining, instruction tuning, domain or task adaptation, regression risks, and the configuration
adaptation
distillation, compression, or subsequent updates that must be evaluated
Determines what correctness and
What is produced, such as text, images, speech, video,
3. Generative modality harmful error mean for the intended
physiological sequences, structured data, or code
output
Identifies application interfaces and
How models interact with retrieval, context, memory,
4. Augmented system dependencies through which errors or
calculations, schemas, routers, and tools
unauthorized influence can propagate
Identifies the action trajectory, scope of
How goals are decomposed, plans selected, tasks
5. Agentic pattern delegated authority, and opportunities
delegated, tools used, and results checked
for intervention
Identifies supplier dependencies, data
Where and under whose control the system runs, and how handling, availability, configuration
6. Interface users and connected systems reach it, including externally visibility, and change-control
hosted, self-hosted, edge, and version-pinned arrangements responsibilities and how outputs reach
users

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 7
 Ziqqur

Figure 1 shows how the six layers relate within a single device function. Model architecture (layer 1) and
training and adaptation (layer 2) together describe the model itself, and its output takes one or more of
the forms listed under generative modality (layer 3). The augmented system (layer 4) surrounds the
model and its output with retrieval, context, persistent memory, calculations, schemas, routers, tools,
and permissions. The agentic pattern (layer 5) adds goals, plans, delegation, actions, and checks, which
define the scope of delegated authority and the points where a human can intervene. The interface
(layer 6) sets where the system runs and who controls it. The whole function sits within its intended use
and clinical context: the users, indications, clinical workflow, human responsibilities, and consequences
of failure that decide which errors matter. Each outer layer widens what the model’s output can reach
and affect. This is why the model cannot be assessed apart from the system around it, and why risk can
enter or spread through layers that contain no generative component.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 8
 Ziqqur

Figure 1. Generalization of the six complementary descriptive layers of an AI-enabled device
software function, shown within its intended use and clinical context. The layers are classification
dimensions, not a processing sequence, and a single system can carry several descriptors within
each layer.

These descriptors can overlap. For example, a fine-tuned, quantized vision-language model can be
self-hosted, use retrieval, and operate within a supervised agent workflow. An embedding or
classification model may support that workflow without generating free-form content. Likewise, a
mixture-of-experts subnetwork is not necessarily an autonomous agent, and an open-weight
model is not necessarily an entirely open-source system.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 9
 Ziqqur

A3) Distinguish capability from authority

The model layer determines what the component can compute. The system architecture
determines what its outputs can affect. A model that can formulate an instruction should not
thereby acquire permission to execute it. Manufacturers should make the boundary between
generated proposals and authorized outputs or actions explicit.

For example, a model might draft an imaging report using acquired images and patient information.
Retrieval supplies relevant records; a workflow routes the draft, and the deployment arrangement
determines how model updates are controlled. Separately, release controls determine whether the
draft can enter the clinical record, and execution controls determine whether any associated
action can occur. The complete function, including these boundaries, is the unit of evaluation.

A4) A common way to describe architecture and risk

The six layers are Ziqqur’s proposal and not from an established standard. Industry would benefit if
FDA offered guidance, or supported a consensus standard, on how manufacturers should describe
the architecture of a GenAI-enabled device and identify where its risks are most likely to arise. A
shared approach would help in several ways:

• Consistent submissions. Sponsors would describe their systems the same way, so
reviewers could find the model, its surrounding components, and its authority boundaries
without having to interpret a different structure in each submission.
• Earlier attention to the right risks. A common map of where risks concentrate, such as
retrieved inputs, tool permissions, unpinned hosted models, and the boundary between a
draft and an action, would help manufacturers address those points during design rather
than after testing.
• Comparability across devices. Similar architectures would be described alike, which
would help FDA, health care organizations, and clinicians compare devices and recognize
when a new design raises a new question.
• Clearer change control. A layer-by-layer description would make it easier to tell which
layer a model update, prompt change, or supplier change affects, and so what revalidation
or Predetermined Change Control Plan (PCCP) coverage it needs.
• Better supplier information. Foundation model suppliers and system integrators would
know what information device manufacturers need from them.
• Support for smaller manufacturers. Companies without large regulatory teams would
have a clear starting point rather than having to build their own framework.

Ziqqur offers the six layers as one possible starting point and would welcome the chance to refine
them with FDA and other stakeholders. Appendix B applies them to the question such guidance
would most need to answer: how model families and levels of autonomy relate to clinical risk.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 10
 Ziqqur

Appendix B
Model families autonomy and clinical risk

Appendix A argued that a model’s name or architecture does not by itself establish a device’s
clinical role or risk. Model family still matters, for a different reason. Each family tends to fail in its
own way. A language model can state an unsupported fact fluently. An image generator can add or
remove a finding while producing a picture that looks plausible. A time-series model can drift out of
step with the signal it is forecasting. These differences shape what “correct” means for an output,
which errors are hard for a user to catch, and which tests and evidence are needed to show the
device performs as intended.

FDA’s discussion paper asks whether a competency-based approach could apply across model
architectures such as multimodal vision-language models and generative or predictive world
models (Question 17). Answering that requires knowing which families are likely to appear in
devices and how their characteristic failures differ. B1 surveys those families and the assurance
priorities each one raises. B2 and B3 then place the family alongside the factors that decide clinical
risk: how much autonomy the deployed function has, and the intended use and clinical context it
operates in.

B1) Families relevant to medical device functions

The model families below are a non-exhaustive set of candidates for device functions and for the
activities that support device development and evaluation. Listing a family is not a claim that it is
authorized by FDA, widely deployed in clinical care, or suitable for any particular intended use. The
list shows the roles these models can play within a device and makes clear that a single device
may use more than one generative model at once, as the example in Appendix D does. Newer
approaches need evidence suited to their maturity and the application proposed for them.

Agentic workflows are not listed as a model family because they are a system pattern, not a type of
model. An agentic workflow can combine any of the families below with retrieval, tools, memory,
planning, and other agents. For that reason, its evaluation should cover the complete sequence of
actions and how an error at one step affects the steps that follow.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 11
 Ziqqur

Model families, illustrative applications, potential clinical risk, and assurance priorities

Family or pattern Illustrative application Potential clinical risk Priority for assurance

Incorrect facts, missing contraindications, Source fidelity, critical omissions, subgroup
Drafting or explaining a device
Language generation and adaptation unsupported conclusions, variable performance, and pre-use review where
result
responses claimed

Input alignment, modality-specific
Combining images, text, and Patient or encounter mismatch, crossMultimodal models accuracy, missing-input behavior, and
audio for interpretation support modal contradiction, fabricated findings
clinical reference comparison

Introduction or removal of findings, Fidelity to acquired data, diagnostic
Reconstruction, enhancement,
Image generation and transformation distorted anatomy, misleading performance, rare-pathology coverage, and
or image synthesis
measurements preservation of originals

Transcription or spoken device Changed negation, dosage or speaker Critical-content error rates, noise and
Speech recognition and synthesis
information identity; incorrect spoken instructions accent testing, readback, and escalation

Sampling and timing checks, horizonPhysiological forecasting or Temporal misalignment, missed
Time-series and sequence models specific performance, missing signals, and
signal interpretation deterioration, error accumulation
alarm behavior

Evidence-supported Stale or incorrect sources, injected
Provenance, access controls, semantic
Retrieval and structured workflows interpretation or structured instructions, syntactically valid but wrong
evaluation, and end-to-end workflow tests
report preparation data

Bounded clinical workflow or Unauthorized actions, cascading errors, Action authority, complete trajectory
Tool-using and multi-agent systems
connected-device coordination duplicated actions, failed interruption testing, cumulative limits, and recovery

Independent safety envelope, sensor
Embodied or vision-language-action Research or proposed physical Physical injury, unsafe motion, delayed
checks, interlocks, timing, and protective
systems device control intervention
stops

Retrieval, automated review, Qualification for the supporting purpose,
Supporting models and development Missed errors, circular evaluation, deficient
synthetic test data, or software independent references, controlled
generators coverage, or faulty generated code
development datasets, and code verification

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 12
 Ziqqur

Autonomy is described separately, by deployed function and operating mode, in section B2 below.
Read together, this table and that scale relate model choice, intended use, autonomy, and clinical
risk. A more detailed taxonomy of these families, by descriptive layer, is in Appendix F.

B2) Describe autonomy by deployed function and operating mode

B1 describes how each model family tends to fail. Autonomy determines how far such a failure can
travel before someone is able to stop it. The same incorrect output carries very different risk if it
waits in a draft for clinician review than if it triggers an order or changes a device setting on its own.
FDA’s proposed framework reflects this on its activity axis, which runs from non-directive
information to fully autonomous action. Autonomy, however, is often described loosely, as a
property of the model (“an autonomous agent”) rather than of what the deployed system is actually
allowed to do.

We recommend describing autonomy through the decisions and actions the system is permitted to
perform, the supervision available, and the time available for intervention. Autonomy should be
assessed separately for clinical activity, tool execution, and adaptation. A workflow can automate
many administrative steps while retaining clinician approval for every clinical action; a fixed model
can perform highly autonomous clinical actions without learning in the field.

The following working scale aligns with FDA recommended consensus standards; however, ISO/TS
24971-2:2026 [15] excludes devices employing LLMs or generative AI from its scope; this table
does not claim conformity with that specification. Level 5 identifies adaptation authority as an
additional concern, rather than implying that every adaptive system is more clinically autonomous
than every fixed system.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 13
 Ziqqur

Working level Operational meaning Recommended control placement

Supplies data or component results; the user makes Data inputs, component outputs, and downstream
0 Manual support
the decision interfaces

Proposes content or recommendations for review
1 Assistive Between the draft and its release or clinical use
before consequential use

Executes permitted tasks with active supervision and
2 Supervised automation Before tool execution and at workflow transitions
timely intervention

Performs predefined tasks without approval of every Around the task envelope, cumulative actions, and
3 Bounded autonomous tasks
step exception paths

Performs authorized tasks without immediate human At execution boundaries and through continuous automatic
4 Independent execution
approval protection

Changes behavior or parameters without separate Around learning, evaluation, deployment, monitoring, and
5 Adaptive operations
preapproval of each change recovery

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 14
 Ziqqur

These labels are descriptors, not risk scores. Manufacturers should identify the most
consequential reachable behavior within the intended operating modes and foreseeable misuse,
rather than assigning autonomy from the model’s default behavior or averaging across
components. Human oversight should receive risk-control credit only when users can recognize
the relevant error and intervene before harm.

B3) Characterize risk before crediting controls

Human oversight is only one of the factors that decide whether an error reaches the patient. B1
shows how a function can fail and B2 shows how far that failure can travel, but neither one
measures clinical risk. Clinical risk depends on what would happen to the patient if the error were
not caught. That depends on the intended use, the clinical context, and the people involved, and it
should be understood before any safeguard is credited with reducing it.

We recommend assessing severity and likelihood of harm together with reversibility, time to harm,
detectability, user expertise, patient vulnerability, exposure frequency, dependencies, and
available safeguards. An assistive image-reconstruction function can present substantial risk if a
clinician cannot recognize an invented finding. A more automated read-only workflow may have
lower clinical consequences if it cannot alter care or authoritative records.

Manufacturers should first identify hazards and hazardous sequences, then demonstrate the
effectiveness of controls before claiming reduced residual risk. Neither a model’s architectural
label nor a generic low-medium-high rating establishes the risk of a device’s function. Risk
classifications and evidence expectations should remain tied to intended use and the evaluated
system.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 15
 Ziqqur

Appendix C
Deterministic controls and supporting evidence

Once the risk of a function is understood, the question becomes how to reduce it, and how to show
that the reduction is real. Appendices A and B describe what a GenAI-enabled device is made of,
how its models can fail, how much authority it holds, and what is at stake for the patient. This
appendix turns to the controls that bound that authority, and to the evidence needed before those
controls can be credited with lowering residual risk. Our central recommendation is that safetyrelevant boundaries be enforced by deterministic controls: mechanisms that operate
independently of the generative model and can be specified and verified like conventional device
software. C1 sets out what that separation means. C2 through C5 cover where controls belong,
how traceability supports them, how to evaluate them, and how to maintain assurance after
deployment.

C1) Separate probabilistic judgment from enforceable authority

Ziqqur recommends reserving generative methods for functions that require their capabilities and
using specified, testable mechanisms to enforce safety-relevant boundaries wherever feasible. A
deterministic control applies defined rules to defined inputs and states. The model or agent being
constrained should not be able to modify those rules, grant itself permissions, change acceptance
criteria, or bypass the enforcement path.

Determinism is not the same as correctness, clinical validity, or robustness. Repeatable inference
can produce a repeatable error. A schema can enforce valid formatting while accepting an
incorrect diagnosis. A citation can identify a real source that does not support the generated claim.
Accordingly, deterministic enforcement should be combined with validated clinical logic where
applicable and evidence about the complete device’s performance is required.

AI judge models, semantic guard models, and multi-agent critique can provide additional detection
or review. They should not be described as deterministic safety controls merely because they
return structured results or use fixed sampling settings. Where a learned detector supplies the
signal for a deterministic gate, its detection failures and the gate’s enforcement failures should be
evaluated separately.

These controls should not be confused with the expert systems and rule-based clinical decision
support of earlier decades. Those systems tried to encode clinical judgment itself as hand-written
rules, and their reach was limited by what a team of people could write and maintain. The
deterministic controls described here have a different purpose. They do not replace a model’s
capabilities. They bound its authority, inputs, outputs, and actions, and they are verified in the
same way as conventional device software (see C2 and C4).

Deterministic methods have also advanced. Today’s deterministic systems draw on longestablished mathematics and more than six decades of AI and machine learning research, to the

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 16
 Ziqqur

point where they can behave like generative models in many cases. They can interpret naturallanguage questions, retrieve and assemble information from multiple sources, and return results
with their sources attached, all without generating content. The difference lies in how they produce
an output. A generative model samples each output from a probability distribution over an
effectively unbounded space, so one input can produce many outputs. A deterministic system
maps each input to exactly one output, which can be reproduced exactly, given the same
configuration, as often as needed. As stated before, where a deterministic system can perform a
function, it removes the risks that come from generation. Where generation is still needed, pairing
the generative model with independently enforced controls allows its benefits to be used while the
device’s safety-relevant behavior remains bounded and verifiable.

Table C-1 shows how these deterministic controls differ from the machine learning used in medical
devices before generative AI. Pre-generative models make the clinical inference; the controls
described here bound the authority of a generative model and are not themselves the decisionmaker.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 17
 Ziqqur
Ziqqur

Table C-1. Pre-generative machine learning compared with deterministic controls around
generative AI
Pre-generative machine learning (the Deterministic controls around
Characteristic
model) generative AI (the controls)

Do not make the clinical inference; they
Makes the clinical inference (classify, bound the authority, inputs, outputs and
Role
score, detect) actions of the generative component that
does

Probabilistic inference, fixed once Specified rules: the same input, state and
Behavior
released (a locked model) configuration give the same decision

Narrow and structured (a label, a score, a A defined decision: allow, block, hold for
Output
mask) review, or fall back to a safe state

A rule that is wrong or incomplete, a
detector that misses what it screens for, a
Misclassification, drift and subgroup bias,
Failure modes misconfigured or bypassed enforcement
measurable against a reference standard
path, and failures shared with the
component it guards

Verification of each rule as device
software (IEC 62304 [16] covers the
Statistical performance against a
software life cycle), evidence that each
Evidence reference standard (for example,
control is effective in the integrated
sensitivity and specificity)
device, and system-level and clinical
validation of the whole device

The probability that a generative error
reaches the patient can be estimated
The probability that an incorrect output where evidence supports the
reaches the patient can be estimated effectiveness of each control,
Risk estimation
from test data and the conditions of use, dependence and common causes
within the limits of the test set between controls have been analyzed,
and uncertainty is stated (Appendix D,
Shift 2)

In the layers around the model (retrieval,
Where it sits Is the device function
orchestration, interface)

C2) Place controls at the boundaries where consequences arise

Table in C1 ends with where each approach sits. A pre-generative model is the device function,
while deterministic controls sit in the layers around a generative model. That makes placement a
design decision in its own right. A control works only if it sits at a point the generative output must
pass through before it can cause harm. If it is placed elsewhere, the output can reach the record,

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 18
 Ziqqur

the user, or a connected device without being checked, however well the control itself is built. C1
defines what a deterministic control is. This section addresses where controls belong.

The following control layers are architectural safeguards, distinct from Appendix A’s descriptive
layers. They need not reside in a single service or form a linear pipeline. Controls should be placed
wherever content acquires authority, information crosses a trust boundary, a tool acts, or
configuration changes

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 19
 Ziqqur

Control layer Recommended mechanisms Evidence of effectiveness

Patient and encounter binding, units and range checks,
Wrong-patient, malformed, stale, missing,
Input and source integrity timestamp and freshness rules, approved source versions,
conflicting, and injected-input tests
separation of source content from executable instructions

Approved model and prompt versions, controlled retrieval Baseline readback, mismatch detection,
Configuration and operating
and memory, defined workflows, externally enforced scope unauthorized-change tests, and reachable-state
scope
and permission settings review

Validated calculations where applicable, critical-value
Clinical and output Boundary and omission tests, reference comparison,
checks, preservation of source measurements, required
boundaries unsafe-output challenges, and usability evidence
fields, clearly separated drafts, risk-based clinical review

Least privilege, allowlisted operations, argument and
Prohibited-action, permission-escalation, replay,
Tool and action authorization destination validation, separate read/write access,
duplicate-action, and changed-plan tests
cumulative limits, transaction-specific approval

Interlocks, watchdogs, timeout rules, bounded retries, Fault injection, timing tests, interruption at
Independent safety and
protective stops, permission revocation, and validated intermediate steps, and safe-recovery
recovery
degraded modes demonstrations

Protected audit records linking configuration, source
Trace reconstruction, integrity checks, access tests,
Evidence and accountability inputs, outputs, actions, control decisions, and human
and retention verification
approval

Approved update pathways, protected evaluation assets,
Update and rollback tests, supplier-change
Monitoring and change drift and failure triggers, impact assessment, revalidation,
exercises, regression coverage, and monitoringadmission controlled deployment, and safe recovery to an appropriate
trigger tests
configuration

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 20
 Ziqqur

A rejection or timeout should lead to a defined clinically appropriate response. Simply stopping is
not necessarily safe for a device supporting continuous or life-sustaining care. The response may
require continued conventional control, handoff, alarms, degraded operation, or another validated
alternative.

Taken together, the control layers in the table give a manufacturer a way to confirm that every path
from generative output to clinical consequence passes through at least one verified control. The
layers are not meant as a checklist to apply in full to every device. The right set depends on the
device’s intended use, its autonomy, and the risks identified under B3, and each control should be
traced to the hazard it addresses. Appendix D shows what this looks like in a single device, with
controls placed at each of its six descriptive layers. One layer, evidence and accountability, also
supports every other layer, because a control’s decisions can be reviewed and investigated only if
they are recorded. C3 addresses what those records should contain.

C3) Distinguish information provenance from clinical verification

A record of where information came from is not the same as evidence that the information is
correct. Provenance shows which sources, configuration, and controls produced an output.
Clinical verification shows that the output is accurate and supported by those sources. A
generated statement can cite a real source that does not support it, and an image can trace back to
acquired data yet still misrepresent it. Traceability needs to support both, and should not let the
first stand in for the second.

Traceability should allow reviewers to identify what information was used, what configuration
processed it, what the system produced or did, and which controls and people authorized
consequential use. It does not require recording unverifiable model-generated reasoning as though
it were a faithful explanation of internal computation.

For factual text, manufacturers should evaluate whether cited evidence actually supports the
claim. For measurements and reconstructed images, traceability should preserve the relevant
acquired data, transformations, processing settings, and linkage to the displayed result. For
agentic actions, it should include the plan or proposed action, tool arguments, permission
decision, returned result, subsequent state, and confirmation of completion or partial failure.

Records should be sufficient for investigation and reassessment while respecting data
minimization and appropriate protection of patient information. Where exact replay is technically
unavailable, manufacturers should state that limitation and retain enough evidence to reconstruct
the clinically relevant sequence. A hash establishes integrity only when linked to retained,
accessible content and a trustworthy record of its identity.

C4) Evaluate the controls as well as the model

Evaluation of AI-enabled devices has largely focused on the model: how accurate it is, how well it
generalizes, and how it performs across subgroups. For a GenAI-enabled device, that evidence is

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 21
 Ziqqur

necessary but no longer enough. If the device’s safety depends on deterministic controls, those
controls are part of what must be shown to work. A model can perform well on a benchmark while
a missing or bypassable control still allows its errors to reach the patient. Evaluation therefore
needs to cover the model, the controls, and the device they form together, and to show how each
piece of evidence relates to the hazard it addresses.

We recommend a hazard-linked evidence chain: intended use → hazardous sequence → safety
requirement → control implementation → verification method → result → residual-risk assessment.
Controls should be tested individually and in the complete deployment, including combinations of
faults and attempts to bypass them. A passing model benchmark should not compensate for a
failed mandatory authorization or safety control.

Prespecified acceptance criteria should address clinically consequential failures, repeated-run
variability, subgroup performance, source fidelity, action limits, and safe interruption. Synthetic
and real-world evidence should be reported separately unless comparability supports combining
them. Synthetic scenarios can extend rare-case and fault coverage but should not substitute for
appropriate clinical confirmation. Human-AI workflows should be evaluated with the intended
users and review conditions, including workload, automation bias, and time pressure [6], [9].

Comparators should represent the intended clinical workflow, using an appropriate clinical
reference and, where relevant, human-alone, device-alone, and human-AI performance. Claims of
benefit relative to care without the device should use a justified comparator. Evidence that a
control blocks an unsafe action should be distinguished from evidence that the device improves
clinical outcomes.

Model diversity or maker-checker arrangements may add scrutiny, but agreement is not proof of
correctness. Evaluation assets and reference criteria should remain protected from the system
under evaluation. Review and release authority should be assigned explicitly, and an agent’s
favorable verdict should not itself grant approval.

Premarket evaluation establishes that the controls work in the configuration tested. C5 addresses
how that assurance is maintained once the device, its models, and its suppliers begin to change.

A GenAI-enabled device does not stay in the configuration that was evaluated. Models are updated,
suppliers change their hosted versions, retrieval sources grow, and clinical workflows change
around the device. Each of these can change behavior without any change to the manufacturer’s
own code. Premarket evidence shows that the controls worked when tested. Postmarket
assurance must show that they continue to work, and must detect quickly when they do not.

Monitoring should examine clinically relevant errors, control activations, missed or unnecessary
escalations, unauthorized-action attempts, workflow failures, subgroup differences, and incidents
[10]. A supervisory agent should itself be evaluated and should not have unrestricted authority to
alter the device or its evaluation criteria. Monitoring cannot be credited as protection against a
harm that occurs before detection and intervention.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 22
 Ziqqur

For third-party foundation models, we recommend obtaining documented architecture and training
data provenance, supported uses, known limitations, relevant evaluation results, subgroup
coverage, update commitments, and audit capabilities. A voluntary foundation model master file
[1] could supplement this information but should not replace the manufacturer’s intended-usespecific evidence or responsibility for the device.

Change assessment should cover model updates, prompts, retrieved content, memory behavior,
tools, permissions, orchestration, interfaces, control logic, and deployment infrastructure.
Managing supplier changes requires a way to detect version or behavior changes, notification
arrangements where available, and a defined response when configuration identity or continued
performance cannot be established. Recovery should consider changed patient state and actions
already taken; reverting software does not undo a clinical action.

Appendix C summary

Ziqqur recommends that deterministic controls become a required element of GenAI-enabled
device assurance through appropriate regulatory mechanisms. FDA should identify the safety
outcomes and evidence expected, proportionate to intended use and risk, while permitting
different implementations to demonstrate equivalent protection. We recommend integrating this
evidence into existing quality, software, cybersecurity, clinical-evaluation, and risk-management
processes. Appendix D illustrates these recommendations in a hypothetical device and shows how
deterministic controls change its risk.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 23
 Ziqqur

Appendix D
Hypothetical Use Case: Display of Deterministic Controls Reducing Risk

The preceding appendices make recommendations in general terms. This appendix applies these
recommendations into a single hypothetical device, so that FDA and other readers can see how we
believe they work together in practice. The device is a radiology decision-support system for MRI. It
was chosen because it combines several features that raise the questions in FDA’s discussion
paper: more than one generative model, retrieval from clinical records, an agentic workflow, a chat
interface for physicians, and outputs that can reach the patient record. The example is a composite
drawn from capabilities found in current products. It does not describe any specific product or
claim that any such device has been authorized.

The appendix proceeds in four steps. First, it maps the device onto the six descriptive layers from
Appendix A (Figure 2). Second, it applies deterministic controls at each layer, as recommended in
Appendix C (Figure 3). Third, it shows how those controls shift the device’s risk, using both FDA’s
proposed two-axis framework and the risk management process of ISO 14971 (Figures 4 through
6). Finally, it recommends three refinements to FDA’s proposed framework based on what the
example shows.

D1) Describe the example device by its six layers

A radiology decision-support device connects to a hospital’s picture archiving and communication
system (PACS). When an MRI study is acquired, the device retrieves the series, identifies the
sequences present (for example, T1-weighted, T2-weighted, FLAIR, diffusion-weighted, and
contrast-enhanced), and uses image models to detect and mark candidate findings. A visionlanguage model drafts structured findings, which are written back to PACS as Digital Imaging and
Communications in Medicine (DICOM) annotation objects for radiologist review. Radiologists and
referring physicians can ask questions about the study through a chat interface. The chat is limited
to the current study, its prior studies, and approved clinical references, and it can offer diagnostic
considerations to physicians. The radiologist remains responsible for the final interpretation and
report.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 24
 Ziqqur

The table below maps this device onto the six descriptive layers from Appendix A and identifies where generative AI is used in each.

Layer In this System Where Generative AI is Used What is Not Generative
Four models, each with a Vision-language transformer: reads the MR
The detection and segmentation model
different role: one images, measurements and prior reports and
(convolutional network or vision
detection and writes draft findings in natural language and
transformer) classifies and outlines
1. Model segmentation model, one structured form.
regions but does not generate content.
architecture vision-language model, one Language model: generates the chat
The embedding model turns text and
language model, and one answers to radiologist and physician
images into numbers for search and
multi-modal embedding questions, including diagnostic
produces no readable output.
model considerations.
Pretrained foundation models: the visionPretrained models adapted language model and the language model
Adapting the detection model to MR
to MR images across start from large general-purpose generative
2. Training sequences is conventional supervised
sequences, field strengths models, so their behavior depends partly on
and training. Quantization and PCCPand scanner vendors; training data the manufacturer didn’t control.
adaptation managed updates apply to all models
quantized to run on site; Instruction tuning: teaches the generative
but are not generative steps.
updated under a PCCP models reporting style and how to answer
within the chat scope.
Structured findings (DICOM Structured
Report): written by the vision-language Finding marks (DICOM SEG and
model. presentation states): come from the
Four kinds of output:
Draft impression: free text written by the detection model. They are outlines of
3. Generative finding marks, structured
vision-language model for radiologist review. what the model found, not generated
modality findings, a draft
Chat answers: written by the language content. Even though this layer is called
impression, chat answers
model. All three are new content the device “generative modality,” not every device
generates, so all three can contain fluent but output is generative.
incorrect statements.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 25
 Ziqqur

Layer In this System Where Generative AI is Used What is Not Generative
Standard DICOM web
connection to PACS, All components are conventional
None directly. Generative models depend
DICOM header parsing, software. Measurements are
on this layer: what they retrieve here (prior
prior-study retrieval, calculated, not generated. The query
4. Augmented reports, guideline text, patient context)
patient context from the router is rule-based in this example; if it
system becomes the input they write from, so errors
Electronic Health Record used a language model to classify
or tampering here reach the generated
(EHR), a clinical guideline questions, it would become a
output.
library, a query router, a generative component.
measurement engine
Study orchestrator: a language model
A study orchestrator runs
planner that decides which steps to run and
each study in order: select
in what order for each study.
series by sequence, detect, Series selection uses DICOM header
Compare with priors: the vision-language
compare with priors, draft data. Detection uses the non5. Agentic model describes changes from earlier
findings, check generative model. The consistency
pattern studies.
consistency, queue for check and the review queue are
Draft findings: the vision-language model
review. A separate chat conventional software in this example.
writes the findings.
agent answers questions
Chat agent: a language model that decides
about the study.
what to retrieve and how to answer.
None directly. Deployment determines who
On the hospital’s own
controls the generative models and their
servers next to PACS, or in
versions. A model hosted by an outside Hosting, networking, and the dea vendor-hosted cloud with
6. Interface supplier can change behavior without the identification steps are conventional
de-identification at the
manufacturer releasing a new version unless infrastructure.
hospital boundary; model
versions are pinned by contract and checked
versions pinned
technically.

The table also shows how unevenly generation is spread. Only two of the four models generate content. Three of the six layers contain no
generative component at all, yet each of those three shapes what the generative models receive or controls which version of them runs.
Figure 2 shows the same mapping as a single picture, using the nested layout of Figure 1, so the generative components can be seen in
the context of the whole system. .

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 26
 Ziqqur

Figure 2. Example mapping of the six descriptive layers for a hypothetical MRI decision-support device integrated with PACS. Highlighted
tags identify generative AI components; outlined tags identify non-generative models and conventional software.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 27
 Ziqqur

Figure 2 applies the six descriptive layers from Figure 1 to a hypothetical MRI decision-support
device. The device retrieves MRI studies from the PACS, detects and marks candidate findings,
drafts findings for radiologist review, and offers a bounded chat that provides diagnostic
considerations to radiologists and referring physicians. The radiologist reviews, edits, and signs the
final report.

The layers are nested to show that the model must be evaluated together with the system around it.
At the center, the model layer contains four models with different roles. A detection and
segmentation model outlines candidate findings and is not generative. A vision-language
transformer drafts findings, and a language model answers chat questions; both are generative. An
embedding model supports retrieval. The training and adaptation layer shows that the generative
models begin as pretrained foundation models and are instruction-tuned for reporting style, while
all models are adapted to MR sequences, field strengths, and scanner vendors and updated under
a PCCP [3], [7]. The generative modality layer shows the device’s four outputs. Structured findings,
the draft impression, and chat answers are generated content. Finding marks come from the nongenerative detection model, which illustrates that not every output of a generative AI-enabled
device is itself generative.

The augmented system layer connects the models to PACS, prior studies, patient context from the
EHR, a clinical guideline library, a query router, and a measurement engine. None of these
components is generative, but what they retrieve becomes the input the generative models write
from. The agentic pattern layer shows a study orchestrator, itself a language-model planner, that
runs each study through a sequence of steps. Two of those steps, comparing with priors and
drafting findings, use generative models. A separate chat agent handles questions. The interface
layer shows the device running on site next to PACS or in a vendor-hosted cloud with deidentification, with model versions pinned.

Outside the device boundary, the radiologist and referring physician interact with the device in both
directions, PACS is both the source and destination of studies, and the EHR provides read-only
patient context. Generation is concentrated in a few components, but risk from those components
can travel through layers that contain no generative models. The table below identifies, layer by
layer, the risks the device carries before any deterministic controls are applied, how an error could
reach the patient, and the potential harm. The hazardous situations H1–H6 are assessed in D3.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 28
 Ziqqur

Risks in the example device before deterministic controls

Hazardous
How an error could reach the
Layer Risk without deterministic controls Potential harm situation
patient
(see D3)

Content generated by the visionA generated finding appears as
language or language model can be Unsupported finding
a mark or measurement that
1. Model presented as if it came from the relied on, leading to
the radiologist trusts as a H1
architecture detection model. Nothing defines unnecessary workup or
detection result rather than a
which model may produce which incorrect treatment
draft
output.

Foundation-model behavior depends
partly on training data the
A finding the device previously
manufacturer did not control.
2. Training and caught is missed after an Missed or delayed
Retuning, quantization, or an update H2, H6
adaptation update, and nothing flags the diagnosis
can change behavior, including on
change
rare or subtle findings, without
detection.

Structured findings, the draft
Under workload and time
impression, and chat answers can be
pressure, the radiologist Wrong-side or wrong-size
3. Generative fluent but incorrect, unsupported, or
accepts a plausible draft finding in the report; H1, H2
modality inconsistent with each other (for
(automation bias), or does not missed finding
example, wrong laterality or size).
notice a finding that is absent
Findings can also be omitted.

Retrieval can return another patient’s A comparison with the wrong
prior study, outdated guideline text, prior or an incorrect Incorrect assessment of
4. Augmented
or content containing embedded measurement becomes the progression; H3
system
instructions. Measurements may be basis for an assessment of inappropriate treatment
generated rather than calculated. change or progression

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 29
 Ziqqur

Hazardous
How an error could reach the
Layer Risk without deterministic controls Potential harm situation
patient
(see D3)

The orchestrator can skip required
Unreviewed findings enter the
steps, such as the consistency Care based on
record and are acted on by a
check, write findings directly to unreviewed or incorrect
5. Agentic pattern referring physician; a non- H4, H5
PACS, or loop. The chat agent can information;
specialist follows a treatment
answer outside its scope, including inappropriate treatment
instruction from the chat
with specific treatment instructions.

A model hosted by an outside
Performance changes go
supplier can change without a Errors across many
undetected in clinical use, and
validated release. An unvalidated patients before detection;
6. Interface affected studies cannot be H6
version can run, and outputs carry no inability to find and
identified or investigated
record of the configuration that correct affected reports
afterward
produced them.

D2 applies deterministic controls to the same device and addresses each of these risks at the layer where it arises.

D2) Apply deterministic controls at each layer

D1 identified, layer by layer, the risks the example device carries before any controls are applied. This section applies deterministic
controls to the same device. The device, its models, and its intended use are unchanged. The difference is that each generative
component, along with the inputs it depends on and the outputs it produces, is now bounded by rule-based mechanisms that operate
outside the generative models and cannot be modified or bypassed by them.

These controls do not make the generative models deterministic. The vision-language model may still describe the same study in
different words, and the language model may still phrase an answer differently each time it is asked. What the controls make
deterministic is the device’s safety-relevant behavior: which steps run, which data the models can see, which outputs may be stored,
who must approve them, and what happens when a check fails. Each control has a defined pass or fail outcome that can be verified in

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 30
 Ziqqur

the same way as conventional device software, which allows a manufacturer to show that a control is effective rather than merely
present.

The table below lists the controls for each layer, the risk from D1 that each addresses, and the test that shows it works.

Generative Risk Addressed
Layer Deterministic Controls Verification of Effectiveness
(from Figure 2)
Model inventory: each model is registered with Attempt to submit each
Generated content from the the outputs it may produce; any other output type unregistered output type from
1. Model vision-language or language is rejected. each model and confirm
architecture model could be presented Finding marks only from the detection model: rejection; confirm that every
as if it were a detection the generative models cannot create or alter stored mark traces to a detection
marks. model run
Locked versions (checksum): released models
Foundation-model behavior cannot be changed in place.
partly depends on training Fixed benchmark gate before release: any Benchmark and regression
2. Training
data the manufacturer didn’t change must meet acceptance criteria set in results recorded for each release;
and
control; retuning or advance in the PCCP. a modified model file fails
adaptation
quantization can change Regression set of known hard cases: subtle checksum verification
behavior findings and conflicting priors must produce the
same accepted results after every update.
Schema check against the DICOM SR template:
nonconforming findings cannot be stored.
Findings cite series and location: unsupported
Structured findings, draft findings are blocked. Test sets with seeded
impressions, and chat Impression matches findings: the draft unsupported, malformed, and
3. Generative
answers can be fluent but impression cannot state a finding absent from the contradictory outputs; confirm
modality
incorrect, unsupported, or structured findings, and laterality, size, and each is blocked and that nothing
inconsistent with each other sequence must agree. reaches PACS before sign-off
Quarantine until checked and signed:
generated output is held apart from PACS until it
passes these checks and radiologist review.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 31
 Ziqqur

Generative Risk Addressed
Layer Deterministic Controls Verification of Effectiveness
(from Figure 2)
Patient and study identity matched on DICOM
identifiers before any prior study or EHR data is
Mismatched-identity test cases
Retrieved content becomes used.
are rejected; measurements
4. the generative models’ Measurements computed, not generated: sizes
match reference values; requests
Augmented input, so errors or tampering and volumes come from the measurement
for unapproved sources fail;
system here reach the generated engine.
injection test content is detected
output Approved, versioned guideline sources only.
and removed
Retrieved text screened for embedded
instructions before it reaches a model.
Fixed set of allowed steps; required steps
cannot be skipped. Read-only agents; PACS
The planner and chat agent Adversarial tests that attempt to
write only after sign-off. Step and time budget
decide what to do and skip steps, write to PACS, exceed
per study: when exceeded, the study goes to
5. Agentic retrieve, so they could skip budgets, or ask out-of-scope
manual review.
pattern steps, act beyond their role, questions; audit log
Chat scope gate: out-of-scope questions are
loop, or answer outside completeness and integrity
refused and escalated.
scope checks
Tamper-evident audit log of every plan, tool call,
retrieval, and output.
Model checksum verified on every call: an
unvalidated model version will not run.
Substitute an unvalidated model
Configuration fingerprint on each output:
A hosted or updated model and confirm refusal; confirm
records model, prompt, and guideline library
6. Interface could change behavior every output carries a complete
versions.
without a validated release fingerprint; scheduled fallback
Tested no-AI fallback: if any check fails, the
drills
study reverts to the standard workflow and is
flagged.

Read across a row, the table shows one layer at a time. It does not show how the controls sit in relation to each other or to the generative
components they constrain. Figure 3 adds the controls to the nested view used in Figure 2. In that view, the controls surround every
generative component, and several of them sit in layers that contain no generative model at all.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 32
 Ziqqur

Figure 3. The device in Figure 2 with deterministic controls applied at each layer. Dark tags are deterministic controls enforced
independently of the generative models; crimson tags are generative AI components; outlined tags are other components.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 33
 Ziqqur

Figure 3 builds on Figure 2 by adding deterministic controls to each of the six descriptive layers of
the hypothetical MRI decision-support device. Deterministic controls are rule-based mechanisms
that operate outside the generative models, cannot be modified or bypassed by them, and produce
the same result for the same input. Each control in the figure is placed at the layer where it acts and
is aimed at a specific generative component or at the inputs and outputs those components
depend on.

Each control in the figure is placed at the layer where it acts and is aimed at a specific generative
component or at the inputs and outputs those components depend on. The controls in the
augmented system and interface layers deserve particular attention. Neither layer contains a
generative model. Even so, identity matching, computed measurements, and source restrictions
protect what the generative models receive, and version verification controls which model runs.
This reflects the point made in D1: risk from generative components can travel through the whole
system, so controls must be applied across the system rather than to the models alone.

Together, the controls show that the generative components can be bounded by mechanisms that
are specified, verifiable, and independent of the models themselves. The controls can be tested in
the same way as conventional device software, even though the output of the generative models
cannot. D3 shows how this changes the device’s risk.

D3) Show how the controls shift risk

To show how deterministic controls change risk, we apply two lenses to the hypothetical MRI
decision-support device: FDA’s proposed two-axis framework (discussion paper, Section IV, Figure
1) [1] and the risk management process of ISO 14971:2019 [14]. For the second lens, we draw on
the machine-learning guidance in ISO/TS 24971-2:2026 [15]. That Technical Specification explicitly
excludes devices using large language models or generative AI from its scope, so we apply its
guidance here only by analogy. In our view, the absence of equivalent guidance for generative AI is
itself a gap that FDA and the standards community should address.

The two lenses reveal two different kinds of shift. Deterministic controls can change what a
function is able to do, which moves it along FDA’s activity axis. They can also change how likely an
incorrect output is to cause harm, which ISO 14971 captures as probability of occurrence of harm.
In general, they do not change the severity of the harm that would result if an error did reach the
patient. FDA’s two-axis framework captures the first kind of shift but not the second. This is one
reason we recommend that the framework include formal modifiers for the presence and
demonstrated effectiveness of downstream safeguards.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 34
 Ziqqur

Shift 1: Position on FDA’s Two-Axis Framework

Figure 4. Before and after positions of four functions of the example device on FDA’s proposed two-axis risk framework. Dashed crimson markers show
each function without deterministic controls; solid markers show the same function with them. Grid adapted from FDA’s discussion paper, Figure 1;
positions are illustrative.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 35
 Ziqqur

Figure description: Three of the four functions move on the grid. The orchestrator moves from fully
autonomous to HCP-supervised action-taking once PACS writes require radiologist sign-off; the chat
function moves toward less directive, lower-consequence information once a scope gate refuses
treatment instructions; and lesion measurement leaves the generative function entirely once
measurements are computed by conventional software. Draft findings for radiologist review do not
move, because the controls applied to them reduce the probability of harm rather than changing the
function’s activity or consequences.

Without deterministic controls, the study orchestrator can write generated structured findings
directly to PACS. In practice, that makes it an action-taking function operating without supervision
(function 1). Its position in the far right column reflects that capability, even though the device was
intended to assist radiologists. Making PACS writes conditional on radiologist sign-off moves the
function to HCP-supervised action-taking. This corresponds to the level of autonomy in which the
device proposes an option but does not proceed until the user approves it (ISO/TS 24971-2, Annex
D, applied by analogy).

The chat function (function 2) starts out as action-directing information for a referring physician
who may not have specialist expertise. FDA identifies this situation as one that can shift a function
higher on the consequences axis. Over a multi-turn exchange, the chat could also drift toward
specific treatment instructions. A deterministic scope gate classifies each question before it
reaches the language model and refuses and escalates treatment instructions and other out-ofscope requests. The gate removes the most directive and highest-consequence content from what
the function can produce, which moves it left and down. This shift should be credited only when
adversarial, multi-turn testing shows the gate holds.

Lesion measurements (function 3) are a measurement function. FDA notes that measurement
functions can sit higher on the consequences axis because users cannot easily check the basis for
the output. When measurements are computed by conventional software and the generative
model may only cite them, measurement leaves the generative function entirely. It becomes
conventional device software, verified in the usual way.

Draft findings for radiologist review (function 4) do not move on the grid. The function remains
action-directing information for a specialist, and an incorrect finding still carries severe potential
consequences. Grounding checks, consistency checks and quarantine leave its position
unchanged but substantially reduce the probability that an error reaches the patient. That
reduction is the second kind of shift.

Shift 2: Probability of Harm under ISO 14971

ISO 14971 [14] defines risk as the combination of the probability of occurrence of harm and its
severity. For machine-learning risks where the probability of harm cannot be estimated, ISO/TS
24971-2 (5.5 a) advises estimating risk from severity alone. Many generative AI hazards are in this

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 36
 Ziqqur

position today. The rate at which a generative model produces an unsupported or incorrect
statement varies with input, phrasing and context, and cannot be bounded with confidence from
testing alone. If risk is judged on severity alone, any hazardous situation with serious or worse
severity is effectively evaluated at its worst case.

Deterministic controls can change this. Each control is conventional software with specified
behavior, so its implementation and effectiveness can be verified and tested, respectively, (ISO
14971:2019, 7.2) and its failure modes can be characterized. A hazardous situation then requires a
sequence of failures: the generative model must make an error, and every deterministic barrier and
the human reviewer must also fail to stop it. The probability of the hazardous situation can then be
estimated, but only for a defined endpoint and exposure, with evidence that each detector is
effective, an analysis of common causes and dependence between barriers, and a statement of
the uncertainty in the estimate.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 37
 Ziqqur

Figure 5. Barriers between a generative error and patient harm for one hazardous situation in the example device: an unsupported finding in a draft
report that is relied upon. Before controls, a single human review stands in the path, and generated findings can bypass it by being written directly to
PACS. After controls, the error must pass four deterministic barriers and radiologist sign-off, and blocked outputs are flagged for manual review rather
than discarded silently.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 38
 Ziqqur

Figure description: Before controls, harm depends on whether one radiologist catches the error,
and a direct write path to PACS can bypass even that check. After controls, harm requires the
generative error and the failure of every barrier in sequence. Because the deterministic barriers are
verified like conventional software and their effectiveness is tested, their failure rates can be
characterized together with an analysis of dependence between barriers, this makes the probability
of harm estimable. Routing blocked outputs to manual review also converts silent failures into visible
ones.

Figure 5 also addresses silent failure. ISO/TS 24971-2 (8.1 b) asks manufacturers to account for
situations in which a device fails without informing the user. Because every deterministic barrier
routes blocked outputs to a manual review queue, a failure is flagged rather than silent. Similarly,
the tested no-AI fallback and locked model versions put into practice the TS guidance on returning
to a previous version.

Figure 5 follows one hazardous situation through its barriers. The same reasoning applies to six
hazardous situations identified for the example device, labeled H1 through H6:

• H1. An unsupported generated finding is relied on.

• H2. A finding is omitted from the draft findings.

• H3. Findings are compared with the wrong patient’s prior study.

• H4. An unreviewed finding is written to PACS and acted on.

• H5. The chat gives a treatment instruction to a non-specialist.

• H6. An unvalidated model version runs in clinical use.

Figure 6 places all six on a conventional risk chart, before and after controls. Before controls, none
can be placed on the probability axis, so each is judged on severity alone. After controls, and given
evidence that the controls are effective and independent, each can be placed at an estimated
probability. The severity of each stays where it was.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 39
 Ziqqur

Figure 6. Before and after risk estimation for six hazardous situations in the example device. Before controls, probability cannot be estimated and risk is
judged on severity alone. After controls, each hazardous situation can be placed on the probability axis. Severity is unchanged in every case. Scales and
acceptability criteria are illustrative; each manufacturer defines its own in its risk management plan.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 40
 Ziqqur

Figure description: Every arrow in the chart is vertical: deterministic controls do not reduce the
severity of harm, but, where their effectiveness and independence are supported by evidence, they
can make its probability estimable and, in most cases, low. Five of the six hazardous situations move
into the acceptable region. The omitted-finding situation (H2) moves less, because deterministic
checks are weaker against errors of omission, and it remains in the region requiring further risk
reduction and benefit-risk review.

The table below gives the detail behind each arrow in Figure 6. Each row is one of the six
hazardous situations. Severity is the seriousness of the harm if the situation occurs;
controls do not change it. Before controls records that, without controls, the probability
cannot be estimated, so the situation is judged on severity alone, as ISO/TS 24971-2
advises for such cases. Deterministic controls lists the controls from D2 that act on that
situation. ISO 14971 risk control option places each control in the standard’s priority order:
inherently safe design, then protective measures, then information for safety. After controls
gives the estimated probability once the controls are in place and shown to be effective.
These estimates are illustrative, since each manufacturer sets its own scales and
acceptability criteria. The risk control option column shows that every control used is a
design or protective measure. That is the basis for the first of the observations that follow.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 41
 Ziqqur

Hazardous Severity Before ISO 14971 risk control After controls
Deterministic controls
situation (unchanged) controls option (7.1) (illustrative)

Grounding check;
H1. Unsupported Not estimable;
consistency check;
generated finding is Serious judged on Protective measures Remote
quarantine until checked
relied on severity
and signed

Independent detection
H2. A finding is Not estimable; Occasional. Further
model; radiologist’s primary
omitted from the Critical judged on Protective measures reduction and benefitread; regression set of
draft findings severity risk review needed
known hard cases

H3. Comparison with Not estimable; Patient and study identity
the wrong patient’s Critical judged on matched on DICOM Protective measures Improbable
prior study severity identifiers

H4. Unreviewed Not estimable;
Read-only agents; PACS
finding written to Critical judged on Inherently safe design Improbable
write only after sign-off
PACS and acted on severity

H5. Chat gives a
Not estimable; Scope gate refuses and
treatment
Critical judged on escalates; step and time Protective measures Remote
instruction to a nonseverity budget
specialist

H6. An unvalidated Not estimable; Model checksum verified on
model version runs Serious judged on every call; configuration Protective measures Improbable
in use severity fingerprint on each output

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 42
 Ziqqur

The table supports the shift shown in Figure 6, but it also shows the limits of what deterministic
controls can do. Three observations follow. They cover where these controls rank among ISO
14971’s risk control options, the type of error they are least able to catch, and the condition that
must be met before any of the shift can be credited.

First, deterministic controls would rand above safety in the ISO 14971 hierarchy of risk
control options. ISO 14971 gives priority to inherently safe design, then protective measures, then
information for safety. Every control in the table is a design or protective measure. Whether a given
control is inherently safe design or a protective measure depends on whether it removes the hazard
pathway or enforces a limit around a retained function. By contrast, FDA has asked whether a
patient-facing, action-directing output becomes any less directive when it adds a “talk to your
doctor” statement. Disclaimers of that kind are information for safety, the lowest-priority option.
Deterministic controls offer manufacturers a way to reduce generative AI risk without relying on
that lowest tier.

Second, deterministic controls are weaker against errors of omission than against errors of
commission. A grounding check can block a finding that has no supporting evidence, but it cannot
detect a finding the model failed to mention. Hazardous situation H2 is therefore reduced less than
the others and remains in the region that requires further risk reduction and benefit-risk review.
Controls for omissions depend more on independent detection and on the radiologist’s primary
read. We include H2 deliberately: deterministic controls are not a substitute for evaluating clinical
performance, and residual risk must still be weighed against benefit (ISO 14971:2019, clause 8).

Third, the shift is credible only if it is verified. Each control in the table has a pass or fail outcome
that can be tested, including with synthetic and adversarial inputs, as ISO/TS 24971-2 (7.2 b)
describes for machine-learning risk controls. The independence of the barriers must also be
shown, including the absence of common-mode failures between generative models and any
model-based checks. A control that is present but unverified should not move a function on FDA’s
framework or lower its estimated probability of harm.

D4) Refinements for FDA’s Framework

Our provided hypothetical example suggests three refinements to FDA’s proposed approach:

1. Credit demonstrated deterministic controls when placing a function on the activity axis. Where
verified controls prevent a function from acting without supervision or from producing out-ofscope directive content, its placement should reflect those constraints rather than the
unconstrained capability of the underlying model.
2. Add probability of harm alongside the two axes. The framework currently reflects activity and
severity. Downstream safeguards, as a formal risk modifier, would let manufacturers show that

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 43
 Ziqqur

they have reduced the probability that an incorrect output causes harm, consistent with ISO
14971.
3. Encourage guidance for generative AI risk management. ISO/TS 24971-2 now gives machinelearning-specific guidance on applying ISO 14971 but excludes generative AI. FDA could encourage
the standards community to extend that guidance, including guidance on estimating the
probability of harm when generative outputs are bounded by deterministic controls.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 44
 Ziqqur

Appendix E
Traceability to FDA discussion questions

The following index identifies relevant technical positions. It does not imply that every aspect of
each question has been answered. Broader policy responses can be added without repeating the
technical narrative.

Discussion
Recommendation Traceability
Question

A4, Appendix B, B3; Appendix D, D3, Shift 1 and D4 (credit verified controls; add
Q1
probability of harm as a third dimension)

Appendix D, D3, Shift 1 (function 2: a scope gate removes the most directive content);
Q2
Appendix B, B3

Appendix B, B3 (user expertise and patient vulnerability as risk factors); Appendix D,
Q3
D3, Shift 1 (function 2)

Appendix D, D3, Shift 1 (function 2: a referring physician without specialist expertise);
Q4
Appendix B, B3

Appendix D, D3, Shift 1 (function 2: multi-turn drift, credited only after adversarial
Q5
multi-turn testing); cover letter, 'Credit effectiveness, not presence'

Appendix C, C2 (defined clinically appropriate response to a rejection or timeout);
Q6
Appendix C, C5 (missed or unnecessary escalations)

Appendix C, C4 (hazard-linked evidence chain; a benchmark pass does not offset a
Q7
failed control); Appendix C, C1

Appendix B, B3 (evidence tied to intended use and the evaluated system); Appendix D,
Q8
D4

Appendix C, C4; cover letter, 'Build on existing frameworks' (ISO 14971, ISO/TS 24971Q9
2, IEC 62304)

Appendix C, C4 (protected evaluation assets; agreement between models is not proof
Q10
of correctness)

Q11 Appendix C, C4 (intended users, review conditions, appropriate clinical reference)

Appendix C, C4 (synthetic and real-world evidence kept separate unless
Q12
comparability supports combining them)

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 45
 Ziqqur

Discussion
Recommendation Traceability
Question

Appendix C, C4; Appendix D, D3, third observation (no common-mode failures
Q13 between generative models and model-based checks); cover letter, 'Prohibit selfverification'

Appendix C, C4 (comparators; human-alone, device-alone and human-AI
Q14
performance)

Appendix C, C4 (claims of benefit relative to care without the device need a justified
Q15
comparator)

Cover letter, 'Prohibit self-verification' and the Trust commitment (independent
Q16
checkers); Appendix C, C4 (review and release authority assigned explicitly)

Appendix B, B1 (vision-language, multimodal, image and signal generators); Appendix
Q17
A, A2

Appendix C, C5 (monitoring cannot be credited against harm that occurs before
Q18
detection and intervention)

Appendix C, C5; Appendix C, C2 (monitoring and change admission); cover letter,
Q19
deskilling paragraph (monitoring AI-assisted and unassisted performance)

Appendix C, C5 (a supervisory agent must itself be evaluated); Appendix C, C1 (AI
Q20
judge models are not deterministic controls)

Cover letter, deskilling paragraph (HCP and HDO certification; data sharing between
Q21
HDOs and MDMs)

Appendix C, C5 (change assessment); Appendix C, C2 (monitoring and change
Q22
admission); D2 (fixed benchmark gate under the PCCP)

Appendix C, C5 (defined response when configuration identity or continued
Q23
performance cannot be established)

Appendix C, C5 (third-party foundation models; supplier changes); D2, interface layer
Q24
(model checksum verified on every call)

Appendix C, C5 (a voluntary foundation model master file supplements, but does not
Q25
replace, sponsor evidence)

Cover letter, 'Bound agentic actions'; Appendix A, A3, A4; Appendix B, B2; Appendix C,
Q26
C2 (tool and action authorization); Appendix D, agentic pattern layer

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 46
 Ziqqur

Appendix F
Extra Illustrations

Table F-1 gives a more detailed taxonomy of the model families summarized in Appendix B, B1,
arranged by the descriptive layers of Appendix A. Example families are illustrative and do not imply
FDA authorization or suitability for a particular intended use.

Table F-1. Detailed taxonomy of model families by descriptive layer

Layer Category Type How it works Example families
Replaces or mixes
attention with
Non- State-space /
1 · Model recurrent state Mamba, RWKV,
transformer recurrent
architecture updates, giving linear- Jamba, Griffin
sequence models
time scaling over very
long sequences.
Generates text by
Non- iteratively denoising a LLaDA, Mercury,
1 · Model Diffusion
autoregressive whole sequence in Gemini Diffusion
architecture language model
LM parallel instead of (experimental)
token-by-token.
Smaller transformer
(roughly <15B params) Phi, Gemma,
1 · Model Small language trained on curated Llama small
Size class
architecture model (SLM) data, often distilled; variants, Qwen
runs on device or small, Ministral
modest hardware.
Trained (often with RL)
to produce an internal OpenAI o-series,
Reasoning / reasoning trace before Claude extended
1 · Model Inference
test-time- answering; spends thinking,
architecture strategy
compute model more compute per DeepSeek-R1,
query for harder Gemini Thinking
problems.
Image encoder feeds
GPT-4o-class,
visual tokens into an
1 · Model Vision-language Claude, Gemini,
Multimodal LLM so the model can
architecture model (VLM) LLaVA, Medreason over images
Gemini
and text together.
Single model trained
jointly on text, image,
1 · Model Omni / any-to- audio (and sometimes GPT-4o, Gemini,
Multimodal
architecture any model video) that can take Qwen-Omni
and emit multiple
modalities.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 47
 Ziqqur

Layer Category Type How it works Example families
Diffusion Uses a transformer
1 · Model Generative DiT-style image
transformer backbone to predict
architecture backbone generation.
(DiT) denoising information.
Trained with selfBase / supervision on large
Llama base,
2 · Training & pretrained corpora; captures
Training stage Mistral base, GPT
adaptation foundation general knowledge but
base (not public)
model is not tuned to follow
instructions.
Base model further
trained on instructions
Instruction2 · Training & and human/AI Most commercial
Training stage tuned / aligned
adaptation preference feedback chat models
model
to be helpful, honest,
and safe.
A smaller student is
trained to imitate a DeepSeek-R12 · Training & larger teacher's Distill, Gemma
Compression Distilled model
adaptation outputs, keeping much (partly distilled),
capability at lower many SLMs
cost.
Reduces numerical
precision or removes GGUF builds,
2 · Training & Quantized /
Compression weights to shrink AWQ/GPTQ
adaptation pruned model
memory and speed up checkpoints
inference.
Learns to reverse a
noising process;
Stable Diffusion,
3 · Generative Diffusion image generates images by
Image DALL·E, Imagen,
modality model iteratively denoising
Midjourney, FLUX
from noise, guided by a
prompt.
Learns a direct
Flow-matching / transport path from Stable Diffusion 3,
3 · Generative
Image rectified-flow noise to data; often FLUX, consistency
modality
model fewer sampling steps models
than diffusion.
Generator and
discriminator
Generative compete; generator
3 · Generative StyleGAN,
Image adversarial learns to produce
modality CycleGAN, pix2pix
network (GAN) outputs the
discriminator can't tell
from real.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 48
 Ziqqur

Layer Category Type How it works Example families
Encodes data into a
compressed latent
Variational VQ-VAE, latent
3 · Generative distribution and
Image / latent autoencoder encoders inside
modality decodes samples from
(VAE) diffusion models
it; often a component
of larger generators.
Images are tokenized
Autoregressive Parti, Muse, native
3 · Generative into discrete codes
Image image/token image output in
modality and generated by a
model multimodal LLMs
transformer like text.
Extends diffusion/flow
Video Sora, Veo,
3 · Generative models across time to
Video generation Runway Gen,
modality generate coherent
model Kling
video clips.
Generates natural
Speech speech from text; ElevenLabs,
3 · Generative
Audio synthesis (TTS) voice cloning OpenAI TTS, VALLmodality
& voice cloning reproduces a specific E, XTTS
speaker from samples.
Generates music or MusicGen, Suno,
3 · Generative Music / sound
Audio sound effects from text Udio, Stable
modality generation
or audio prompts. Audio
Generates 3D shapes Point-E, Shap-E,
3 · Generative 3D & scene or scenes from text, DreamFusion,
3D / spatial
modality generation images, or multiple Gaussian-splat
views. generators
Pretrained on large
collections of time
Time-series TimesFM,
3 · Generative series to forecast or
Science foundation Chronos, Moirai,
modality generate signals with
model Lag-Llama
little task-specific
training.
LLM trained heavily on
Claude, GPT,
3 · Generative Code generation source code to write,
Code Codestral, Qwenmodality model complete, explain, and
Coder, StarCoder
fix software.
Maps perception and
Visioninstructions to RT-2, π0, Gemini
3 · Generative language-action
Embodied physical actions or Robotics, Genie,
modality (VLA) / world
learns a simulator of Cosmos
model
how the world evolves.
Generates a sequence
Text completion
3 · Generative Generation Autoregressive by conditioning each
or tokenized video
modality method model new element on earlier
generation.
elements.

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 49
 Ziqqur

Layer Category Type How it works Example families
Composite Combines different
3 · Generative Generation VAE plus diffusion
generative generators, encoders,
modality method plus text encoder.
pipeline decoders or priors.
Generates outputs
Text-conditioned
subject to an input
3 · Generative Conditioning Conditional image or labelsuch as text, labels,
modality modifier generator conditioned
images, or
tabular data.
measurements.
Multiple model calls
and code steps
4· Compound AI arranged in a fixed,
LangGraph, DSPy,
Augmented Pipeline system / LLM developer-defined
n8n, custom code
system workflow sequence; the model
does not choose the
path.
Restricts generated Produce a
4· Constrained /
outputs to specified complaint record
Augmented Output control schema-based
syntax or permitted in a JSON
system generation
structures. schema.
4· Sends work along
Routing Route inquiries by
Augmented Pipeline selected predefined
workflow category.
system branches.
Model repeatedly
reasons, picks a tool, Claude Agent
5 · Agentic Reactive tool- observes the result, SDK, OpenAI
Single agent
pattern using agent and decides the next Agents SDK,
step until the goal is LangGraph agents
met.
Real-time dialog agent
(text or voice) that Voice-agent
5 · Agentic Conversational /
Domain agent answers, gathers info, platforms on
pattern voice agent
and can take actions LLMs
like scheduling.
Runs continuously or
on a schedule, Scheduled agent
5 · Agentic Autonomous / monitors events, and platforms, Claude
Long-running
pattern ambient agent acts with little or no Tag-style team
real-time human agents
prompting.
Agent that perceives Research and
5 · Agentic Embodied / and acts in the early commercial
Embodied
pattern robotic agent physical world through humanoid /
a robot body. assistive robots

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 50
 Ziqqur

Appendix G
References

The following references are cited or relied upon in this response. Web pages were accessed on
October 19, 2026.

[1] U.S. Food and Drug Administration. Considerations for the Regulation of Generative AI-Enabled
Medical Devices: Discussion Paper and Request for Feedback. Docket No. FDA-2026-N-7874.
August 18, 2026. https://www.regulations.gov/docket/FDA-2026-N-7874

[2] U.S. Food and Drug Administration. Artificial Intelligence-Enabled Device Software Functions:
Lifecycle Management and Marketing Submission Recommendations. Draft guidance, January 7,
2025. https://www.fda.gov/media/184856/download

[3] 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; current version August 2025.
https://www.fda.gov/media/166704/download

[4] U.S. Food and Drug Administration. Artificial Intelligence/Machine Learning (AI/ML)-Based
Software as a Medical Device (SaMD) Action Plan. January 2021.
https://www.fda.gov/media/145022/download

[5] U.S. Food and Drug Administration. Proposed Regulatory Framework for Modifications to
Artificial Intelligence/Machine Learning (AI/ML)-Based Software as a Medical Device (SaMD):
Discussion Paper and Request for Feedback. April 2, 2019.
https://www.fda.gov/media/122535/download

[6] U.S. Food and Drug Administration, Health Canada, and Medicines and Healthcare products
Regulatory Agency. Good Machine Learning Practice for Medical Device Development: Guiding
Principles. October 2021. https://www.fda.gov/media/153486/download

[7] U.S. Food and Drug Administration, Health Canada, and Medicines and Healthcare products
Regulatory Agency. Predetermined Change Control Plans for Machine Learning-Enabled Medical
Devices: Guiding Principles. October 24, 2023. https://www.fda.gov/medical-devices/artificialintelligence-enabled-medical-devices/predetermined-change-control-plans-machine-learningenabled-medical-devices-guiding-principles

[8] U.S. Food and Drug Administration, Health Canada, and Medicines and Healthcare products
Regulatory Agency. Transparency for Machine Learning-Enabled Medical Devices: Guiding
Principles. June 13, 2024. https://www.fda.gov/media/179269/download

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 51
 Ziqqur

[9] International Medical Device Regulators Forum, Artificial Intelligence/Machine Learning
Working Group. Good Machine Learning Practice for Medical Device Development: Guiding
Principles. IMDRF/AIML WG/N88 FINAL:2025. January 2025.
https://www.imdrf.org/sites/default/files/2025-02/IMDRF_AIML%20WG_GMLP_N88%20Final.pdf

[10] U.S. Food and Drug Administration. Request for Public Comment: Measuring and Evaluating
Artificial Intelligence-enabled Medical Device Performance in the Real-World. Docket No. FDA2025-N-4203. September 30, 2025. https://www.regulations.gov/docket/FDA-2025-N-4203

[11] U.S. Food and Drug Administration. List of Artificial Intelligence-Enabled Medical Devices. Web
page. https://www.fda.gov/medical-devices/artificial-intelligence-enabled-medical-devices/listartificial-intelligence-enabled-medical-devices

[12] U.S. Food and Drug Administration. Artificial Intelligence and Medical Products. Web page.
https://www.fda.gov/science-research/science-and-research-special-topics/artificialintelligence-and-medical-products

[13] U.S. Food and Drug Administration, Artificial Intelligence Program. Artificial Intelligence
Program: Research on AI/ML-Based Medical Devices, with its research pages on the limitations of
medical data in AI; evaluation methods, performance assessment and uncertainty quantification;
postmarket monitoring; performance evaluation of evolving devices; and regulatory evaluation of
new AI uses. Web pages. https://www.fda.gov/medical-devices/medical-device-regulatoryscience-research-programs-conducted-osel/artificial-intelligence-program-research-aiml-basedmedical-devices

[14] International Organization for Standardization. ISO 14971:2019, Medical devices - Application
of risk management to medical devices. Third edition, December 2019.

[15] International Organization for Standardization. ISO/TS 24971-2:2026, Medical devices -
Guidance on the application of ISO 14971 - Part 2: Machine learning in artificial intelligence. First
edition, June 2026.

[16] International Electrotechnical Commission. IEC 62304:2006+AMD1:2015, Medical device
software - Software life cycle processes. Edition 1.1, June 2015.

[17] Federal Food, Drug, and Cosmetic Act, section 524B, Ensuring cybersecurity of devices (21
U.S.C. 360n-2); and U.S. Food and Drug Administration. Cybersecurity in Medical Devices: Quality
Management System Considerations and Content of Premarket Submissions. Final guidance,
February 3, 2026. https://www.fda.gov/media/119933/download

[18] Turney J, Young T, Chauhan D, Beeharry R, Mahmud M. AI Use for Medical Students: Impact on
Clinical Skill Acquisition and Retention. A Systematic Review. Advances in Medical Education and
Practice. 2026;17:1-13. doi:10.2147/AMEP.S583763

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 52
 Ziqqur

[19] Monteith S, Glenn T, Geddes JR, Whybrow PC, Achtyes ED, Bauer R, Bauer M. Artificial
intelligence and deskilling in medicine. British Journal of Psychiatry. Published online January 8,
2026:1-3. doi:10.1192/bjp.2025.10496

Ziqqur, Inc. · ziqqur.ai · hello@ziqqur.ai Page 53