An FDA AI model description should explain what each model does, what it receives and produces, how its architecture and features support the intended function, how it was trained and selected, what preprocessing and postprocessing surround it, what parameters and operating points define the submitted configuration, and what limitations or biases could affect device performance.
The description should be detailed enough for a technically competent reviewer to understand and critically evaluate the model's design and development. It should not read like a machine-learning tutorial or a journal paper. The regulatory purpose is to connect the model's technical choices to the device's intended use, risk controls, software implementation, and performance evidence.
For a device with multiple models, describe each model and show how their inputs, outputs, dependencies, and decision logic combine into the final device output. FDA's most detailed model-description recommendations appear in the January 2025 draft guidance, Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations. As of July 2026, FDA still labels that document Draft—Not for Implementation.
The draft is useful planning evidence, but it is not a final binding checklist. It proposes describing each model's inputs, outputs, architecture, features, feature selection, loss functions, parameters, customization, input-quality controls, preprocessing, postprocessing, augmentation, training method, regularization, hyperparameters, development performance, pretrained models, ensembles, thresholds, and calibration.
However, in practice, a draft guidance represents FDA’s thinking on the matter at the time and I have seen them be put into practice well before FDA finalizes them. This materializes by the way of a reviewer asking you for additional information clearly taken from a draft guidance. In these circumstances, it is usually always better to just provide the information rather than argue about draft status.
FDA's final device software premarket guidance provides the broader software-description framework. Device-specific special controls, pathway expectations, recognized standards, and review questions may add or change the necessary detail.
Use the draft AI list as a risk-based planning tool. Do not paste it into an acceptance checklist and assume every item requires the same depth for every model. AI submissions become repetitive when the device description, software description, model-development report, software design specification (SDS), architecture diagram, and performance report all try to tell the entire story.
Give each artifact a primary job:
| Artifact | Primary question | What the model description should not duplicate |
|---|---|---|
| Device description | What is the complete device and how is it used? | Full workflow, hardware, user interface, and accessories |
| Software description | What software functions and components make the device work? | Every implementation detail from lower-level design |
| AI model description and development report | What is each model, how was it developed, and what configuration was selected? | Full test protocols and complete result tables |
| SDS | How is the model integrated, controlled, loaded, executed, and recovered within the software? | Training history and exploratory model selection |
| Architecture diagram | How do components, data flows, trust boundaries, and external systems connect? | Long prose descriptions of algorithms |
| Performance report | Does the final device meet prespecified requirements for its intended use? | Development-set performance presented as confirmatory evidence |
The model description commonly sits within or supports the software-description section. Cross-reference the controlled training-data package, design documents, risk file, verification, validation, labeling, and PCCP rather than copying their content.
Open each model description with a short functional statement:
This prevents a common failure: describing a convolutional network in detail without explaining how its prediction changes the device output or user decision.
Name and version every model. If the product has several anatomy models, acquisition-specific models, classifiers, or quality-control models, give each a stable identifier and define its scope. Do not call all of them “the algorithm.”
Define the data object the model actually receives after any upstream processing. Include, as applicable:
“DICOM image” is rarely enough. The reviewer should understand what pixel data, frames, series, orientation, reconstruction, and metadata reach the model.
Define the raw model output and the device-facing output separately. A network may produce logits that are calibrated, thresholded, aggregated, filtered, or converted into a measurement before the user sees anything.
Document:
Trace each marketed claim and performance endpoint to the applicable device output. If five models feed one displayed result, the description should show the combination logic.
Describe the model family and the major computational blocks that determine behavior. The necessary depth depends on risk, novelty, and complexity.
A useful architecture description may identify:
Do not list every layer merely to look complete. Use a diagram and a parameter table when they help a competent practitioner understand the design. Focus prose on choices that affect performance, risk, reproducibility, and change assessment.
For engineered features, define how each feature is calculated, why it is relevant, and how it was selected. For learned representations, describe the input representation, important feature-extraction stages, and any constraints placed on feature use.
If feature selection used the same data later presented as independent testing, disclose the issue and reassess independence. If variables can encode protected or site-specific information indirectly, discuss the associated bias or confounding risk.
Treat these as part of the AI function, not housekeeping.
Document the exact order and parameters for normalization, resampling, resizing, filtering, reconstruction, registration, imputation, tokenization, segmentation, cropping, augmentation, calibration, smoothing, and thresholding as applicable.
Describe input-quality algorithms and their relationship to intended use. Explain what happens when quality criteria fail. A quality model that blocks inference, selects a view, or changes the output path is a model that affects device behavior and needs its own description.
The SDS should explain how these operations are implemented in the released software. The model report should explain why they are part of the selected model pipeline and how they relate to development.
The goal is reproducibility and critical review—not a chronological diary of experiments.
| Development element | Useful submission content | Weak description |
|---|---|---|
| Objective | Target task, optimization objective, loss function, and rationale | “Optimized for accuracy” |
| Training paradigm | Supervised, self-supervised, semi-supervised, active, federated, transfer learning, or other method | “Deep learning was used” |
| Optimization | Optimizer, material settings, schedule, stopping rules, initialization, and randomization controls | “Standard optimizer” |
| Regularization | Dropout, weight decay, augmentation, early stopping, constraints, or other methods | “Overfitting was prevented” |
| Hyperparameters | Final material values, selection ranges/method, and controlled configuration | Unversioned notebook defaults |
| Development monitoring | Training/tuning curves, relevant metrics, convergence, instability, and overfitting assessment | Best development score only |
| Selection | Candidate comparison method, prespecified or controlled criteria, and chosen model rationale | “Best model selected” |
Explain which dataset role informed each decision. Training, tuning, and internal evaluation results can justify development choices, but they are not substitutes for independent verification and validation of the final device.
Summarize unsuccessful experiments only when they explain a material design choice, limitation, failure mode, or risk control. FDA generally does not need an indiscriminate export of every run.
A pretrained component changes the model's provenance. “Initialized with public weights” is not enough.
Identify:
If the pretraining dataset is unknown or only partially characterized, state that limitation and explain how downstream testing, input restrictions, monitoring, or other controls address it. Do not imply that a large or widely used model is automatically suitable for a medical function.
For a generative or foundation-model component, also describe decoding, sampling, temperature or equivalent controls, retrieval or tool use, prompt/system instructions, output constraints, grounding, refusal or fallback behavior, and how nondeterminism is bounded and evaluated.
In the age of generative AI, the prompt itself is a model. A system prompt encodes design decisions selected against example cases, exactly the way weights do. Apply the same data discipline: split the evaluation data used to create, iterate, and evaluate the prompt into training, tuning, and test roles. Cases used to draft the prompt are training data. Cases used to compare candidate prompts are tuning data. Neither can double as independent test evidence. A prompt "validated" on the same cases that shaped it is a development score dressed up as confirmatory evidence, and the same overfitting and leakage concerns apply. Version the final prompt as part of the submitted configuration and control changes to it the way you would control a retrained model.
FDA's January 2025 draft proposes enough detail for a competent AI practitioner to produce an equivalent model. Read “equivalent” as a functional and methodological target, not a promise that stochastic training will recreate identical weights from prose alone.
A reviewer should be able to understand:
The controlled development environment should retain more detail than the reviewer-facing narrative: code revision, dependency lock, seeds, hardware, training configuration, data manifest, run logs, checkpoints, and artifact hashes. Cross-reference those records as appropriate rather than embedding raw logs in the submission.
Thresholds and calibration can change clinical behavior while the model weights stay fixed. Treat them as controlled parts of the submitted configuration.
For each operating point, describe:
For calibration, describe the method, fitting data, target interpretation, evaluation, and conditions under which calibration may degrade. A score labeled as a probability creates different expectations than an uncalibrated ranking score.
See our [acceptance-criteria guide](https://innolitics.com/articles/ai-samd-acceptance-criteria/) for the separate question of defining pass/fail evidence for the final device.
Do not confine limitations to the performance report. The model design itself may create predictable boundaries.
Address, as applicable:
Connect each material limitation to a risk assessment, control, test, labeling statement, or monitoring activity. A candid limitation with an effective control is stronger than a blanket claim of robustness.
Public records do not expose the complete confidential model-development package, but several show the scope of information FDA has considered relevant. The records vary because the devices and public-document conventions vary. They support a general editorial conclusion: a useful model description explains the technical mechanism and its clinical boundaries, not merely the brand name of an architecture.
An authorized PCCP may allow specified changes to data, hyperparameters, preprocessing, postprocessing, loss functions, architecture, or other model elements without a new marketing submission before each change, provided the modification is made consistently with the authorized plan.
The model description still needs to identify the initially authorized configuration. The PCCP should separately define:
Do not describe a broad family of possible architectures in the current device description and assume the PCCP authorizes all of them. The planned modifications and methods need sufficient specificity.
Include quality-control, routing, feature-extraction, foundation, ensemble, and postprocessing models—not only the headline classifier.
Create one diagram showing data objects, transformations, model boundaries, combination logic, and final device outputs. Give every model a stable identifier.
Link the selected model to its data manifest, code, training configuration, dependencies, environment, thresholds, calibration, and artifact hash.
Explain each model's task, workflow role, consumers, and relationship to intended use before describing architecture.
Cover architecture, features, objective, training paradigm, optimization, regularization, hyperparameters, selection, pretrained components, ensemble logic, and quality controls at risk-appropriate depth.
Link limitations, input constraints, thresholds, and failure states to requirements, risk controls, tests, results, and labeling.
Confirm that model names, versions, counts, operating points, inputs, outputs, and limitations match the device description, SDS, testing, performance reports, labeling, public summary, and PCCP.
“ResNet-based CNN” does not explain what enters the network, what emerges, how results are processed, or how the model affects the device.
Academic novelty is not the organizing principle. Lead with intended function, controlled configuration, risks, and evidence links.
Quality filters, routing models, upstream segmenters, ensembles, and learned postprocessors can materially affect safety and effectiveness.
Normalization, resampling, imputation, cropping, and channel construction may be clinically consequential. Describe and version them.
Development metrics explain selection. Independent testing of the final device supports performance claims.
The narrative, model artifact, preprocessing, threshold, calibration, runtime, and performance evidence must identify the same device.
FDA review is not limited to public labeling. Protect trade secrets through appropriate submission handling, but provide enough technical information for review.
Not routinely for every 510(k) or De Novo. FDA may request additional information when needed. The model description should identify and characterize the submitted artifact even when source code or weights are not initially provided.
Not necessarily. Describe the topology and major blocks at enough depth to understand the technical mechanism, reproduce an equivalent approach, assess risk, and evaluate changes. Detailed diagrams or controlled appendices can carry layer-level information when material.
Material parameters and development methods should be documented at the depth needed for review. A generic assertion that values are proprietary does not answer safety and effectiveness questions. Public summaries can be less detailed than confidential submission content.
Usually not by itself. A model card may organize intended use, performance, limitations, and transparency information, but the submission also needs technical development, software, risk, testing, traceability, and configuration evidence appropriate to the device.
FDA's draft AI guidance proposes placing model description and development information within the Software Description in the Software Documentation section. Use the current eSTAR version and the applicable review pathway, then cross-reference related evidence rather than duplicating it.
Describe each constituent model, its input and output, the combination or voting rule, weighting, routing, disagreement handling, failure behavior, and the versioned ensemble configuration tested as the device.
An FDA-ready AI model description connects the technical mechanism to the medical device. It identifies every model, defines inputs and outputs, explains architecture and development choices, controls preprocessing and operating points, characterizes pretrained components and limitations, and points to the exact tested configuration. Use FDA's January 2025 AI lifecycle draft as a planning signal—not a final checklist—and keep the model report distinct from the SDS, training-data package, and performance evidence.