Updated July 2026 · 7 min read · Adente Vision Engineering Team
What does the operator see on the dashboard day to day?
The daily view for a line operator is a web dashboard that shows pass/fail per part, running counts, and a reject reason for every part the unit stops. That is the operating surface: the operator does not read model internals, they read outcomes and act on them. A reject with an image and a reason is something a shop-floor operator can judge; a raw confidence vector is not.
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, so the handover you get is the integrator's, and the dashboard is what they leave the operator running. The unit inspects in one of four modes, Anomaly, Defect, Counting or Quality, and the mode was set during commissioning; day to day the operator confirms it is running the right recipe for the part on the line, not switching modes at will.
The counts matter as much as the pass/fail. A rising reject count over a shift is the first signal an operator can catch before it becomes scrap, and the reject reasons group those stops into patterns: all edge defects, all one fixture position, all after the light warmed up. Reading the pattern is the operator's core skill after handover.
What can an operator change, and what needs the integrator?
The safe rule of thumb is that an operator runs and monitors, while the integrator owns the model and the operating point. An operator can start and stop inspection, acknowledge and clear rejects, read the dashboard, sort rejected parts, and escalate a pattern. Changing the decision threshold, re-aiming the camera, editing lighting, or retraining the model are integrator tasks, because each one moves the trade-off between escapes and false rejects and should be done with a method, not on a hunch.
This split protects the line. A well-meaning threshold nudge to clear a cluster of false rejects can quietly raise the escape rate, which is the expensive error. Across the industry the cost of a missed defect reaching a customer runs far higher than the cost of re-inspecting a good part, so the operating point is set deliberately at commissioning and changed deliberately, under the integrator or a trained quality engineer, not adjusted per shift.
What the operator absolutely should do is capture and log. Reject images live on the dashboard, and the operator noting which rejects were true defects and which were good parts wrongly stopped gives the integrator the exact evidence needed to tune, without a site visit for every question.
Who owns which task after handover?
One table keeps the handover unambiguous: for each daily task, the sheet names who acts. Post it at the station so a new operator on a later shift inherits the same boundaries.
| Task | Operator can do | Needs the integrator (or quality engineer) |
|---|---|---|
| Start, stop, monitor inspection | Yes, per shift | No |
| Read reject reasons and counts on the dashboard | Yes | No |
| Decide rework vs scrap on a flagged part | Yes, per the quality plan | Escalate borderline cases |
| Move the decision threshold | No | Yes, sets escape vs false-reject balance |
| Re-aim camera or change lighting | No | Yes, re-baseline after any change |
| Retrain or add a defect class | No | Yes, from about 20 reference images |
How does an operator read a reject and decide rework or scrap?
Every reject arrives with an image and a reason on the dashboard, and the operator's decision is rework, scrap, or set aside for review. A dented housing may be scrap; a smudge that a wipe removes may be rework; a part the operator believes is good but the unit rejected goes to a review bin and gets logged as a suspected false reject.
That logging is the whole point of a disciplined handover. A single false reject is noise, but a bin of them with a common reason is a signal, and the reason is usually not the model. Lighting that has drifted, a part sitting slightly off in the fixture, or a threshold set a touch tight will produce a cluster of look-alike rejects that a re-baseline fixes faster than a retrain. The operator does not fix it, but the operator's log is what points the integrator straight at the cause.
Where the result drives an action downstream, the unit signals it over its discrete I/O: with 4 outputs at 24V it can drive a reject gate, a stack light, or a line stop directly, so a scrap decision does not depend on the operator catching every part by eye. At a catalog throughput of 100+ parts per minute, the machine handles the sorting the operator would never keep up with by hand.
When should the operator call for retraining?
Retraining is warranted when the rejects are real but new: a defect type the unit was never shown, a part revision, or a new SKU on the same station. That is different from a false-reject cluster, which is a tuning problem. The operator's job is to tell the two apart from the reject log and escalate the right one.
Because the model trains on good parts from about 20 reference images and training completes under 48 hours, adding a new defect class or a revised part is a short field task, not a return-to-vendor project. The integrator captures the new reference set on the line, retrains, and pushes the update, and because updates load by USB stick the unit stays air-gapped if the line requires it. The operator's contribution is the trigger: a clean escalation with logged evidence, not a guess.
What belongs on a one-page handover sheet?
A one-page handover sheet is the artifact that makes the unit outlive its commissioning. It lists the part and mode the station runs, what a normal shift looks like on the dashboard, the exact rework-versus-scrap rule for this part, the three or four adjustments the operator may and may not make, and the single escalation contact with what to send: the reject reason and a few dashboard images.
Keep it specific to the station. A generic sheet gets ignored; a sheet that names this part, this reject bin, and this contact gets used. For the deeper method behind the numbers an operator escalates, see the sibling post on escapes vs false rejects and the pillar guide on AI visual inspection; to see where these checks run in production, browse the real applications.