Shipping ML into a cleared device without losing your mind
What the validation boundary actually changes about how you build.
The validation boundary is the single most underrated artifact in medical-device ML. Cross it once and the cost function of the rest of your work changes — every downstream decision about data, training, evaluation, and deployment is shaped by what lives on which side of that line.
Most ML engineers meet regulation as a wall of documents. That framing is wrong, and it produces the two classic failure modes: teams that treat validation as paperwork to be endured after the real work, and teams so frightened of it that they stop shipping. The boundary is neither. It is an engineering constraint, like a power budget or a latency target, and like any constraint it rewards the teams that design around it deliberately.
What the boundary actually is
When a device is cleared, what is cleared is not "the product" in the colloquial sense. It is a specific claim, supported by specific evidence, produced by a specific system whose behavior was characterized under a specific verification and validation plan. The boundary is the perimeter of that evidence.
Everything inside the perimeter is expensive to change, because changing it invalidates evidence that took months to produce. Everything outside is ordinary software. The single most consequential architecture decision you will make is which of your components live inside.
The instinct from consumer ML is to put the model at the center and let everything orbit it. Inside a cleared device, you want the opposite: the smallest possible validated core, with the sharpest possible interface, and everything that benefits from iteration speed pushed outside it.
Frozen interfaces are the real deliverable
Inside the boundary, interfaces freeze. Not the implementation — the interface: input specifications, output ranges, preconditions the system may assume, failure behavior when those preconditions are violated.
This freezing is uncomfortable for ML people because our habits assume renegotiable contracts. We retrain, the output distribution shifts a little, downstream consumers adapt. Inside the boundary, "the output distribution shifted a little" is a verification event, and downstream consumers are not allowed to quietly adapt — they are part of the evidence too.
So you learn to spend design time where it pays: on the specification of what the model owes the rest of the system. What are the units, the valid ranges, the confidence semantics? What happens on garbage input? A model that answers those questions precisely can be retrained, replaced, or re-architected behind its interface with a bounded revalidation cost. A model that answers them vaguely turns every improvement into an excavation.
The interface, not the model, is the asset. Models depreciate the day you train them. A well-specified boundary appreciates every time you swap something better in behind it.
Acceptance tests are the contract
The most useful thing I did early on was to build the image-quality assessment pipeline that eventually became the cleared device's acceptance test. That experience rewired how I think about evaluation.
An acceptance test inside a validation plan is not a benchmark. A benchmark says "here is how well we do on average." An acceptance test says "here is the specific, pre-registered set of conditions under which the system is fit for use, and here is the evidence it meets each one." The difference is the difference between a leaderboard and a contract.
Writing evaluation as a contract changes your data strategy. You stop optimizing for aggregate metrics and start enumerating conditions: lighting, tissue types, geometries, edge cases where the system must refuse rather than guess. Coverage of the condition space, not volume, becomes the thing you argue about in review. And because the test is pre-registered, you cannot quietly move the goalposts when the model struggles — which, honestly, is a discipline worth importing even where no regulator requires it.
Iteration speed lives outside the boundary
None of this means the work slows to a regulatory crawl. It means you become deliberate about where speed lives.
Capture guidance, review tooling, reporting, workflow automation — the software that helps a clinician get a good measurement and act on it — can iterate at ordinary product velocity, provided it is architected outside the validated core and cannot alter the measurement itself. In practice this is where much of the user-visible value accrues, and it is where we shipped fastest.
The same logic applies inside the development loop. Training infrastructure, simulation, data tooling, offline evaluation harnesses — all of it lives outside the boundary and should move as fast as any startup's stack. The discipline is at the seam: what crosses from the fast world into the validated world does so through a documented, tested gate, not through a Friday-afternoon deploy.
Getting this partition wrong in either direction is costly. Put too much inside and you have frozen your product's ability to improve. Put a load-bearing computation outside because validation felt inconvenient and you have built a device whose actual behavior is not the behavior that was characterized. The second failure is worse. It is also more common than anyone admits.
A model change is a verification event, not a deploy
The mental model I give new hires: in consumer ML, shipping a model is a deploy — reversible, observable, cheap. In a cleared device, shipping a model is a verification event. It has an entry criterion (the change is characterized: what moved, why, what could regress), an evidence obligation (the acceptance suite, rerun and documented), and an exit criterion (review and sign-off by people whose job is to be skeptical).
Once the team internalizes that, something useful happens: model changes get batched, motivated, and characterized before anyone asks. You stop proposing changes that cannot justify their verification cost, and the changes you do propose are better. The regulatory frame, applied early enough, is just rigor with a deadline.
The corollary is that your infrastructure must make verification events cheap. Deterministic training and evaluation pipelines, versioned datasets, environment pinning, one-command regeneration of the full evidence package. Reproducibility is often sold as scientific virtue; inside a cleared device it is a cost-reduction strategy. Every hour of automation at the verification gate is repaid on every model you ever ship through it.
What I would tell past me
Three things, in order.
First, find the boundary before you write code, and design your interfaces as if they will freeze — because they will, and the ones you designed casually will freeze in the shape of that casualness.
Second, build the acceptance test early and make it the team's shared definition of done. It is much easier to develop toward a contract than to retrofit evidence onto a model that grew up on benchmarks.
Third, protect the fast loop. The validated core deserves its rigor, but a team that loses its ability to iterate outside the boundary loses the improvements that would have been worth validating in the first place. The job is not choosing between speed and rigor. It is drawing the line so each lives where it belongs — and losing your mind over neither.