A model can run on a laptop and still not be a product.
The gap usually appears when the camera is real, the device is warm, the connection is gone, or the person using the result needs to know what happens next. Before an edge model ships, we want a release record that describes the whole path—not just a successful inference screenshot.
1. Name the task
“Object detection” is not a product requirement. The record should say what the user is trying to decide, what counts as a useful result, and what the system should do when the answer is uncertain.
For a camera workflow, that may mean identifying one supported object, rejecting an irrelevant frame, or asking for another capture. Those are different behaviours and should be measured separately.
2. Fix the input boundary
The same model behaves differently with a still photo, a live camera frame, a cropped region, or an image captured in difficult light. Record the input size, colour format, crop rules, and the conditions that produce a no-result state.
This is where many demos quietly move the goalposts. A clean test image is not the same thing as the image a person will capture in the field.
3. Test the target device
The target is not “mobile” or “edge hardware.” It is a specific device class, operating-system version, camera path, memory budget, and power condition. Run the workflow on the hardware that will carry it.
Keep quality, latency, memory, throughput, and thermal behaviour as separate observations. A single average number hides the trade-off that matters to the product.
4. Record the runtime path
Write down which runtime actually executed the model, which operators or delegates were used, and what happens when the preferred path is unavailable. If the app falls back, that is part of the product boundary—not a footnote to the demo.
The handoff should include the model artifact, preprocessing, postprocessing, version, and a repeatable smoke test. Another engineer should be able to reproduce the result without guessing which pipeline was used.
5. Define failure as a user state
An edge system has more outcomes than “prediction returned.” It may have no usable input, low confidence, missing model assets, insufficient storage, a busy device, or no network for an optional download.
Each state needs a visible product response. The user should know whether to try again, continue locally, download something later, or treat the result as unavailable.
The practical rule is simple: measure the path that people will use, on the device they will carry, including the moments when the model cannot answer. That is the evidence that turns an edge model into a dependable product.