The short version

In a case published by integrator Xylos on 31 August 2026, a Flemish manufacturer of micro-ingredients and functional feed additives uses a local computer-vision system to inspect seams on filled bags. Xylos says a working solution took 16 weeks; the targets were to detect at least 90% of defects, keep false alarms below 5%, and make a decision in under one second. The system combines two models with Raspberry Pi nodes by the production line, rather than a cloud-based generative chatbot.

This is a useful example for manufacturers where a defect can be seen by a camera before it becomes a return, rejected shipment, or lost order. But the figures come from the integrator, the customer is not named, and the public case does not provide an independent audit, project cost, or full measurement methodology. What transfers is the pilot logic and architecture—not a promised percentage.

The problem: catch a seam before it opens in transit

The company makes micro-ingredients and functional additives for the animal-feed sector, serves international buyers, and brings production, laboratory, logistics, and commercial functions together at its main site. According to Xylos, defects in the seam of a filled bag are difficult to see with the naked eye. In some instances, the problem was found after a leak in transit, when an export shipment could already be rejected.

Checking every bag manually on several continuous lines was not realistic; sample checks always left a chance of missing a defect between inspections. The team therefore set acceptance targets before development: detect at least 90% of defects, keep false alarms below 5%, and return a decision in under one second—in the rhythm of the line itself.

The task has an observable physical signal, not a vague definition of “good quality.” A camera can see the bag’s position and seam; production staff decide in advance which deviations count as defects and what the system should do when uncertain. That is a much better first machine-vision project than asking AI to “inspect the whole factory.”

What was actually built

The case describes a two-model pipeline:

1. YOLOX finds each bag and tracks its position and movement in real time. This lets the system analyze the relevant region rather than the entire frame.
2. EfficientAD detects anomalies in the seam. It learns from images of normal seams and flags deviations, so every possible defect type does not have to be listed and labeled in advance.

The models run locally across a network of Raspberry Pis with a central controller. The integrator explains the edge design in terms of latency requirements and cost compared with an industrial PC. The case does not publish the board versions, camera, optics, lighting, controller, or total bill of materials. The careful conclusion is “this project used local Raspberry Pi compute nodes,” not “any production line will work with the same kit,” and not “deployment is always cheaper than cloud.”

The system ran in parallel with the existing human inspection for two weeks: detections were compared with inspectors’ decisions and the thresholds were tuned. After that, it became the main inspection method, with operators remaining as a safety net. At the time of the case, the integrator said the system had been in production for six months.

That transition matters more than the catchy claim that “AI replaced inspection.” A comparison phase gives the team a chance to find misses before automated decisions affect output. A person also remains available to notice a new material, a camera failure, or a situation that was not represented in the test data.

How it fits into a production line

Computer vision is not a single neural-network file. Reliable inspection needs a coordinated chain:

  • a sensor or signal indicates when a bag enters the inspection zone;
  • a camera captures the seam at a repeatable distance and under controlled lighting;
  • a model identifies the object and analyzes the relevant region;
  • a controller receives the result within the time budget;
  • a reject mechanism or operator acts according to an approved rule;
  • the event is logged so a process engineer can review disputed cases.

Xylos discloses the models, local execution, and high-level inspection method, but not the camera, line-controller connection, operator interface, or image-retention setup. For another plant, these are essential discovery questions—not details that can be inferred from the case page.

Latency must also be measured for the entire chain: exposure, image transfer, processing, result transfer, and reject-actuator response. If bags move quickly, “the model responds in 300 ms” does not guarantee the whole station can remove a bag safely. The threshold must be checked at actual line speed and with the actual equipment geometry.

What data is required

A controlled pilot does not necessarily need to start with a complex data platform. It does need images representative of the real process:

  • good seams under normal operating conditions;
  • defects of different sizes and severity;
  • bags from different shifts, material batches, and sealing settings;
  • ordinary changes in position, folds, and glare that are not defects;
  • borderline examples on which inspectors may disagree.

A handful of attractive laboratory examples is not enough. Lighting, speed, bag angle, dust on the lens, and film properties change on the line. A review of industrial computer vision research notes that shifts in illumination, cameras, surfaces, and production batches can degrade performance, and that image quality can matter more than choosing a larger model. The OECD also highlights data availability and labeling, legacy infrastructure, and the cost of equipment as barriers for manufacturing AI.

The pilot protocol should therefore keep training images separate from tests on new batches and shifts. Otherwise, the system may simply learn the background and lighting from one day. If the packaging supplier, camera, lens, lighting, or line speed changes, inspection should be repeated. That does not always require retraining, but it does require validation on new examples.

A pilot that does not stop production

A practical rollout can be staged:

1. **Describe the cost of errors.** Estimate the consequences of a missed defect, false rejection, downtime, and manual reinspection. Agree with quality staff on what counts as a defect.
2. **Choose one station.** Record the product, line, speed, packaging type, camera, and lighting. Do not extend the project to the whole assortment before seeing results.
3. **Build a baseline sample.** Review normal and defective examples with a process engineer and inspectors. Record the source of each example and its capture conditions.
4. **Start in observation mode.** The system produces a label but does not control the reject mechanism. An employee independently records a verdict, and the team reviews disagreements.
5. **Check the pre-agreed metrics.** Measure defect recall, false alarms, end-to-end latency, and stability across shifts.
6. **Enable a limited action.** Allow automatic rejection only for a validated defect class, keep an operator for borderline cases, and provide a fast bypass mode.
7. **Assign an operations owner.** Who cleans the optics, checks thresholds, responds to drift, and retains disputed frames? Without an owner, even a good pilot can become unpredictable over time.

In the Xylos case, two weeks of parallel comparison preceded the move to primary automated inspection. Two weeks may be insufficient on another line if rare defects or shift conditions did not occur during that period. Duration should be set by the diversity of real events, not by an integrator’s calendar.

Illustrative economics—not the case’s ROI

Xylos does not disclose the project price or the amount of prevented loss, so the company’s ROI cannot be calculated from the public case. For internal discussion, use a transparent model. Assume a line produces 20,000 bags per month, the historical defect rate is 0.5%, the system actually detects 90% of those defects, and avoidable cost per leaking bag is provisionally estimated at RUB 800.

The modelled gross value of detected defects, before other costs, is:

20,000 × 0.5% × 90% × RUB 800 = RUB 72,000 per month.

This is not actual savings and is not a result reported in the case. It excludes cameras and lighting, installation, line integration, false alarms, reinspection, maintenance, depreciation, rare severe incidents, and losses already prevented by existing inspection. Substitute your own data and calculate a range. If the project only pays back under ideal assumptions, improve the baseline inspection process before buying a system.

Where local AI fits—and where caution is needed

A local vision module can fit when a decision is required within a strict cycle time, images reveal production information, or sending factory images to an external service is undesirable. But “local” does not mean “free” or “maintenance-free”: cameras, lighting, mounting, an edge device, line-controller connectivity, replacements, and update validation remain part of the lifecycle.

This task does not need RAG: inspection instructions may be useful to operators, but the seam is assessed from an image, not by searching documents. A generative agent should not change line settings by itself either. A language model could separately help explain a result, prepare a log, or find an instruction, but the quality-control and actuation path should remain deterministic and auditable.

If the packaging changes, camera quality drops, or the system begins sending more good product for reinspection, there must be a clear signal and a safe return to manual inspection. “The model is confident” is not a substitute for a process engineer’s confirmation.

What the manager should take away

This case is useful not only for its reported results, but for the sequence: first identify a measurable and costly failure, then agree on quality criteria, install local inspection on one process, compare it with a person for two weeks, and only then make automated inspection primary.

The integrator reports reaching 90% defect detection, fewer than 5% false alarms, and sub-second decisions, but the customer is unnamed and no independent validation is provided. Use the case as a checklist of questions for your own pilot, not as a promise of the same effect.

**What the manager should take away:** ask production and quality teams to select one repeatable defect, show real samples, and estimate the cost of a miss and a false reject. Then run machine vision in observation mode on one line before connecting automatic controls.