Engineering declares one version as the release that goes into the submission and stops changing it. The team supports the clinical analysis by running the frozen device on study cases, exporting outputs in the format the statistician needs, and answering questions about failures and outliers. The validated build is archived with everything needed to reproduce it, including container images, model weights, dependency pins, test data and expected outputs, and the version history records what was released.
On the map: Freeze the release. Reader-study analysis support. Archive the validated build.
Rows are disciplines, columns are stages 1 to 8. Select a square to open that task.
Back to the full map
Lock the release with regulatory before anyone writes final numbers. The software description, labeling, SBOM and performance report must all cite the same version.
The freeze happens before validation data are scored, so the version tested is the version submitted. After the freeze, only documentation changes go into the package. Any code or model change starts a new version with its own regression decision and a new version history entry.
The claim type decides it. A claim that the device improves reader performance needs a multi-reader multi-case study. A measurement or segmentation claim usually rests on standalone agreement with expert reference readers. Engineering keeps standalone case collection and inference running while the reader study is in washout, so extra data are ready if FDA asks.
Enough to rebuild and re-run the device years later: the system image or container, model weights, dependency versions with hashes, build instructions, test suites with expected outputs, and the verification records. The checklist is written so someone outside the original team could restore the build.
See the open positions and apply.