A manufacturing AI pilot can work on a workstation and still be a poor product candidate for the edge. The move is not a deployment detail. It changes the hardware boundary, data path, update mechanism, evidence and service model.
This article is a decision framework. It does not claim universal accuracy, downtime, labour or throughput improvements. Those outcomes must be measured for the product, line and operating conditions in question.
Decision 1 — Is edge inference required?
Choose edge inference for an observed constraint, not because "edge AI" sounds industrial.
Document the response deadline, connectivity pattern, data sensitivity, mission duration and degraded behaviour. Then compare local, site-edge and cloud options against the same acceptance criteria.
A cloud path may be appropriate for fleet analysis or non-urgent optimization. A local path may be necessary when the decision is time-bounded, the site cannot depend on backhaul, raw data should remain on site, or the product must keep working during disconnection. Many products use both.
Output: a deployment decision record with constraints and rejected alternatives.
Decision 2 — What is the complete edge product?
The product includes more than a model and accelerator. Map:
- sensors and calibration;
- compute, storage, power and enclosure;
- deterministic controls and safe state;
- local state and buffering;
- plant-network and protocol integration;
- identity, secure boot and access;
- observability and incident evidence;
- signed update and rollback;
- installation and support ownership.
A component absent from the pilot does not disappear in production. It becomes an unresolved product requirement.
Output: a hardware-software-data product boundary with an owner for each responsibility.
Decision 3 — Which conditions define acceptance?
A single validation score does not describe field behaviour. Build an acceptance set around the environment and consequence. For a vision product this can include lighting, line speed, material variation, camera position, contamination, rare defects, operator response and the cost of an uncertain result.
Record the model, configuration, device, thermal state and input conditions for every test. Separate a result observed on target hardware from one measured on a development machine.
Define what happens when the system is uncertain. An abstention, operator review or deterministic fallback can be a product feature when authority is designed deliberately.
Output: a field-acceptance protocol and evidence log.
Decision 4 — How will the device behave outside the happy path?
Test network loss, corrupted input, sensor drift, full storage, power interruption, thermal constraint, failed update and an unavailable upstream service.
For each condition, define:
- detection;
- bounded behaviour;
- operator signal;
- evidence retained;
- recovery;
- authority to return to service.
Do not write "fails safely" as an architecture label. Describe the actual state, transition and owner. Safety-related decisions require the appropriate engineering and conformity expertise.
Output: a degraded-mode and recovery matrix.
Decision 5 — How does the product learn without losing control?
An edge product needs a deliberate evidence loop. Decide which events remain local, which summaries travel upstream, how exceptions are sampled, who can review them, and what evidence permits a model or policy change.
A new artifact should not reach the full fleet because an offline metric improved. Version it, evaluate it against the acceptance set, test on target hardware, stage the release, observe health signals and preserve rollback.
Output: a model-and-software change policy linked to field evidence.
Decision 6 — Who owns the fleet after launch?
Name owners for device health, model behaviour, site integration, security updates, customer support, data quality and incident response. Define how product, engineering, field service and the customer interact.
The strongest technical design still stalls when every operational question routes back to the pilot team. Capability transfer is part of productization.
Output: an operating model and support boundary accepted before rollout.
The productization dossier
A concise edge-AI dossier should contain:
- the customer and operator outcome;
- deployment decision record;
- complete product boundary;
- target-hardware and field-acceptance evidence;
- degraded-mode and recovery matrix;
- change and rollback policy;
- operating owners;
- economics as ranges with assumptions visible;
- proceed, change, partner, pause or stop recommendation.
That dossier connects the Discovery evidence to the Productization gate in the Physical AI Product System. When the edge architecture, product boundary and operating ownership are still separate debates, use the Product Decision Review to produce one recommendation.
Source anchors
This dossier structure is Hyperion's product method. NIST SP 800-82 Rev. 3 describes OT's distinctive performance, reliability and safety requirements. The NIST AI RMF Core calls for evaluation in conditions similar to deployment, documentation of limits and continued monitoring. These sources support the system-boundary and evidence principles; they do not supply universal acceptance thresholds for a manufacturing product.
