Updated July 2026 · 7 min read · Adente Vision Engineering Team
What do multi-line managers actually need from inspection data?
A quality or production manager running several lines does not need to see every part. They need the shape of the process: reject rate per line, how it is trending this week versus last, where throughput is dipping, which defect reason codes are climbing, and which station is drifting toward a threshold. Those are all counts and aggregates, not pictures.
Raw part images answer a different, narrower question, one that belongs on the line, not in a head-office report. An operator or a process engineer looks at an image when they are diagnosing a specific reject at a specific station. A manager comparing eight lines is reading rates and trends. Confusing the two needs is what pushes plants into shipping every frame to a central store they do not actually need.
The practical consequence is that a fleet view can be built almost entirely from metrics. If each unit decides locally and reports numbers, the manager gets the trend dashboard they want without a raw-image pipeline behind it.
Why do raw frames not need to leave the line for those trends?
A defect trend is a time series of counts, and a count is tiny next to an image. To know that line 3's surface-reject rate rose from a stable baseline to a climbing one, you need the per-part verdicts and their reason codes over time, not the megapixels behind each verdict. The information a manager acts on survives the compression from image to metric.
This matters because a raw part image is sensitive. It can carry geometry, tooling detail, throughput, and defect patterns that an OEM customer treats as protected IP. Centralizing a lake of those frames creates a data-residency and NDA surface that a metrics feed simply does not. The trend you want and the risk you want to avoid are separable, and keeping images local is what separates them.
It also keeps the pipe small. Shipping counts, rates and reason codes over an existing plant network is a light, predictable load. Shipping full-resolution frames from every station is a different order of bandwidth and storage, and one that grows with every line you add.
How does the metrics-up, images-down architecture work?
Each unit runs the full inspection on the line and emits only the result: a verdict, a confidence, a reason code, and the running counts. Adente Vision is an edge-AI visual inspection unit built by ADENTE Advanced Engineering Technologies, part of the Aden Group, sold through automation system integrators, and this local-decision design is what lets the fleet view be built from metrics rather than frames.
The raw frame is processed on the unit and the decision leaves as a signal your controller and dashboard already understand. From there, aggregated metrics roll up to a web-based dashboard, and remote monitoring lets a manager or an integrator watch line health without a site visit. The picture that produced each verdict stays on the line, where the diagnostic work that needs it happens.
That split is deliberate. The dashboard is fed by the same numbers the line already produces for its own pass/fail control, so the fleet layer is an aggregation of existing signals, not a second, heavier data path bolted on top. The exact volume of parts and events you centralize depends on your line count and rate; treat any per-plant figure as something to size against your own fleet, not a fixed number.
What leaves the line versus what stays on it?
The clean rule is that verdicts and aggregates travel and pixels do not. The table below shows how a fleet setup splits the two.
| Data item | Where it lives | Why |
|---|---|---|
| Raw part image | On the unit, on the line | Sensitive IP; only needed for local diagnosis of a specific reject |
| Per-part verdict and reason code | Emitted locally, aggregated up | The unit of a trend; small and non-sensitive |
| Reject and throughput counts | Rolled up to the dashboard | What a multi-line manager reads |
| Drift and threshold signals | Rolled up to the dashboard | Early warning across the fleet |
| Deliberately kept sample images | On the line, pulled on demand | Retraining or audit, governed and intentional |
What governance decisions does centralizing metrics require?
Even a metrics-only feed is a governance decision, because you are choosing what is safe to move off the line and who can see it. The questions to settle up front are which aggregates leave a station, at what interval, to which dashboard, and who has remote-monitoring access. Answering those makes the fleet layer auditable rather than an unmanaged copy of shop-floor data.
The advantage of the metrics-up model here is that the sensitive asset never enters the conversation. Because raw frames stay local, the data-residency question narrows to counts and rates, which are far easier to place under a policy an OEM customer or a plant IT team will accept. You are governing numbers, not a library of part photographs. For the underlying case on why the image itself should stay put, the sibling post on edge versus cloud visual inspection walks the data-sovereignty argument in full.
When should you deliberately pull a few sample images?
There is one honest exception to images-down: sometimes you want a small, chosen set of frames to leave the line, for retraining a model or for an audit trail on a disputed reject. The point of the architecture is that this is a deliberate, governed pull of a handful of samples, not a standing firehose of every frame.
That is the difference between a policy and an accident. A retraining set is a curated capture of specific parts, sized to the task and signed off, and it uses the same on-device modes the line already runs across anomaly, defect, counting and quality. It stays the exception because the default, metrics up and images down, already answers what a manager needs across the fleet. This post is a spoke of the pillar guide on AI visual inspection; to see the fleet view alongside the other line tasks the unit runs, browse the real applications.