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.

Is FDA's AI Model Description Checklist Final? 🔗

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.

How Is a Model Description Different From Other Submission Documents? 🔗

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.

Start With the Clinical Function, Not the Neural Network 🔗

Open each model description with a short functional statement:

• what clinical or technical task the model performs;
• where it sits in the device workflow;
• whether it drives, informs, prioritizes, measures, segments, reconstructs, or quality-checks;
• who or what consumes the output;
• whether the output is displayed directly or used by another algorithm; and
• whether the model is locked, customizable within predefined controls, or subject to an authorized PCCP.

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.”

What Technical Content Belongs in the Model Description? 🔗

Inputs 🔗

Define the data object the model actually receives after any upstream processing. Include, as applicable:

• modality, signal, image, waveform, tabular field, text, or derived feature;
• dimensionality, shape, units, scale, channels, sampling, encoding, and required metadata;
• acquisition equipment, protocols, or compatible input range;
• temporal window and aggregation;
• required and optional variables;
• missing, malformed, unsupported, or low-quality input handling; and
• whether another model or deterministic algorithm generates the input.

“DICOM image” is rarely enough. The reviewer should understand what pixel data, frames, series, orientation, reconstruction, and metadata reach the model.

Outputs 🔗

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:

• output type, range, units, resolution, and class mapping;
• confidence, probability, score, contour, localization, measurement, reconstruction, or category semantics;
• postprocessing and aggregation;
• thresholds and operating points;
• abstention, no-result, failure, or indeterminate states; and
• which outputs are presented to users, passed downstream, or stored.

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.

Architecture and major blocks 🔗

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:

• model type and topology;
• stages, branches, layers, encoders, decoders, attention, recurrence, or feature extractors;
• learned and deterministic components;
• input/output dimensions at important boundaries;
• activation or normalization methods when material;
• parameter count or bounded size;
• ensemble members and combination rules;
• routing, cascade, or gating logic; and
• dependencies on pretrained representations or third-party components.

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.

Features and feature selection 🔗

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.

Preprocessing, postprocessing, and quality control 🔗

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.

How Should Model Training Be Described? 🔗

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.

What Should Be Said About Pretrained or Foundation Models? 🔗

A pretrained component changes the model's provenance. “Initialized with public weights” is not enough.

Identify:

• model name, provider, source, version, and immutable artifact identifier;
• architecture relevant to use;
• how it was obtained and secured;
• pretraining objective and known pretraining-data information;
• whether weights were frozen, fine-tuned, adapted, prompted, or otherwise modified;
• layers or components retained or replaced;
• downstream training and evaluation controls;
• known limitations, biases, content risks, or unsupported inputs; and
• change-control strategy if the upstream provider releases new versions.

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.

How Much Detail Is Enough to Reproduce the 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:

1. the complete model pipeline;
2. the training objective and method;
3. the controlled data and split roles;
4. the material architecture and parameter choices;
5. how the final candidate, threshold, and calibration were selected; and
6. which immutable artifact was tested and submitted.

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.

How Should Thresholds and Calibration Be Documented? 🔗

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:

• the output being thresholded;
• how the candidate range was chosen;
• the dataset and metric used for selection;
• the clinical and risk tradeoff;
• whether the value is fixed or user-selectable;
• allowed configurations and safeguards; and
• how the operating point maps to labeling and performance evidence.

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 for the separate question of defining pass/fail evidence for the final device.

What Biases and Limitations Belong in the Model Description? 🔗

Do not confine limitations to the performance report. The model design itself may create predictable boundaries.

Address, as applicable:

• unsupported modalities, protocols, equipment, populations, anatomies, languages, or environments;
• limited input quality or field of view;
• dependence on proxies, prevalence, workflow, or metadata availability;
• known subgroup or intersectional performance concerns;
• sensitivity to missingness, artifacts, distribution shift, or adversarial inputs;
• stochastic variation or nondeterministic output;
• inability to recognize out-of-distribution cases;
• cascading error from upstream models; and
• ambiguity, confidence, or calibration limitations.

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.

What Do Public FDA Records Show? 🔗

Public records do not expose the complete confidential model-development package, but several show the scope of information FDA has considered relevant.

• Special controls established through Fibresolve (DEN220040) require a detailed technical description of image-analysis algorithms, including model inputs and outputs, major components or blocks, and model limitations for that device type.
• The decision summary for Viz HCM (DEN230003) notes a detailed machine-learning model description, inputs, outputs, supported patient population, intended-system integration testing, and evaluation across ECG acquisition hardware.
• The 510(k) summary for HistoSonics Planning Tool (K252947) identifies the anatomy-specific segmentation models, which models use machine learning, and that the implemented models are static rather than adaptive.
• The summary for CogNet AI-MT+ (K252482) describes forward and backward passes, loss-based optimization, fixed iterations, development monitoring, and the modalities included during training.

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.

What Changes When the Device Has a PCCP? 🔗

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:

• which elements may change and their bounds;
• the retraining or development method;
• data-management practices;
• verification and validation with acceptance criteria;
• comparison with the original and previous versions as applicable;
• failure handling;
• update, labeling, and monitoring procedures; and
• configuration and version traceability.

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.

A Practical Model Description Workflow 🔗

1. Inventory every model and learned component 🔗

Include quality-control, routing, feature-extraction, foundation, ensemble, and postprocessing models—not only the headline classifier.

2. Map inputs, outputs, and dependencies 🔗

Create one diagram showing data objects, transformations, model boundaries, combination logic, and final device outputs. Give every model a stable identifier.

3. Freeze the development record 🔗

Link the selected model to its data manifest, code, training configuration, dependencies, environment, thresholds, calibration, and artifact hash.

4. Write the clinical-functional summary 🔗

Explain each model's task, workflow role, consumers, and relationship to intended use before describing architecture.

5. Document material technical choices 🔗

Cover architecture, features, objective, training paradigm, optimization, regularization, hyperparameters, selection, pretrained components, ensemble logic, and quality controls at risk-appropriate depth.

6. Trace design choices to risk and evidence 🔗

Link limitations, input constraints, thresholds, and failure states to requirements, risk controls, tests, results, and labeling.

7. Reconcile every submission section 🔗

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.

Common AI Model Description Mistakes 🔗

Naming an architecture without describing the function 🔗

“ResNet-based CNN” does not explain what enters the network, what emerges, how results are processed, or how the model affects the device.

Reproducing a research paper 🔗

Academic novelty is not the organizing principle. Lead with intended function, controlled configuration, risks, and evidence links.

Describing only the headline model 🔗

Quality filters, routing models, upstream segmenters, ensembles, and learned postprocessors can materially affect safety and effectiveness.

Hiding preprocessing in code 🔗

Normalization, resampling, imputation, cropping, and channel construction may be clinically consequential. Describe and version them.

Reporting the best development score as validation 🔗

Development metrics explain selection. Independent testing of the final device supports performance claims.

Leaving the selected configuration ambiguous 🔗

The narrative, model artifact, preprocessing, threshold, calibration, runtime, and performance evidence must identify the same device.

Treating proprietary detail as a reason for vagueness 🔗

FDA review is not limited to public labeling. Protect trade secrets through appropriate submission handling, but provide enough technical information for review.

Frequently Asked Questions 🔗

Does FDA require source code or model weights with the model description? 🔗

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.

Must every neural-network layer be listed? 🔗

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.

Should proprietary hyperparameters be disclosed to FDA? 🔗

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.

Is a model card enough? 🔗

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.

Where should the model description go in eSTAR? 🔗

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.

How should an ensemble be described? 🔗

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.

Final Takeaway 🔗

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.