The task: turn subjective assessment into a repeatable procedure

Big Saint Food is a Spanish microbusiness with one to nine employees. It works with the livestock and agri-food sectors and produces Iberian products. One process depended on expert visual assessment of the quality of individual cuts. That expertise is valuable but difficult to scale: the result depends on the individual evaluator, inspection conditions, and whether employees interpret the quality classes consistently.

Instead of immediately buying an industrial 3D scanner, the company worked with AIR Institute and the DIGIS3 hub to test the hypothesis first. The team examined the workplace, captured initial calibration images, and selected two-dimensional photography with an ordinary smartphone. The goal was to find out whether an accessible image could support more systematic classification, not to automate the whole control process on day one.

The European Digital Innovation Hubs Network published the case on 13 July 2026. Its value for small businesses lies less in the specific food category than in the decision sequence: standardise data acquisition, validate a model, and only then invest in equipment and integration.

Why the smartphone mattered more than the “smartest” model

In computer vision, a model sees pixels rather than the physical object. If angle, distance, background, and lighting change each time, the algorithm may learn the photography setup instead of product quality. The on-site visit was therefore not a formality: the team defined camera position, tripod use, and a uniform background.

An ordinary smartphone camera was chosen over 3D scanning to keep the approach accessible, reduce computational complexity, and collect data quickly. The case says that an operator without specialised technical training could capture samples. This lowers the entry cost, but it does not remove the need for a protocol. “Any phone in any conditions” and “a standard phone at a fixed station” are different architectures.

For any small manufacturer, a similar pilot should begin with a simple question: can each shift produce the same kind of image? If not, the first budget belongs to lighting, a holder, background, batch identification, and operator instructions. A more expensive neural network will not repair an unstable data source.

How the system was structured

The official description identifies the main components:

  • 2D photographs from a standard smartphone camera;
  • feature extraction and classification-model training;
  • validation with macro‑F1 to include performance for minority classes;
  • a FastAPI back end;
  • Docker containers for reproducible deployment;
  • AWS EC2 infrastructure;
  • an operational platform available to the company.

Macro‑F1 averages the F1 score across classes without weighting each class by its frequency. A large “normal” class therefore cannot completely conceal weak recognition of a rare defect. This is a sensible metric for an imbalanced dataset, but one average is not enough for a production decision.

Each class needs a confusion matrix, precision, recall, and an error cost. Incorrectly downgrading a good product loses margin. Passing a problematic sample can create quality and traceability claims. The operating threshold should reflect those different consequences, not merely maximise an aggregate score.

What the publication does not disclose

The official case does not provide the actual macro‑F1 value, image-dataset size, number of classes, train/test split, or results on new batches. It does not report response latency, cost per assessment, manual-review rate, or robustness to another phone or lighting setup.

The material therefore confirms that a prototype was built and deployed as an operational platform, but it does not establish readiness for fully autonomous sorting. The authors themselves describe reduced time, variability, and classification errors as potential effects. Quantification requires a longer period of operational use.

This is a useful example of how to read vendor and public-support case studies correctly. A working platform and a higher digital-maturity score are project results, but they are not the same as return on investment. Management should request baseline operating figures and compare them with measurements after the pilot.

What changed for the company

Under the Digital Maturity Assessment, the overall score rose from 33% to 40%. Human-Centric Digitalisation increased from 39% to 59%, Automation & Artificial Intelligence from 36% to 52%, and Green Digitalisation from 25% to 35%. Data Governance, however, fell from 52% to 39%, while Digital Readiness moved only from 16% to 19%.

This mixed result is more informative than an unconditionally positive chart. Introducing one AI capability does not solve data governance or general infrastructure readiness. The second assessment may have been stricter or exposed new requirements, but the official material does not explain the decline, so it should not be guessed at.

The company also secured €30,000 in PADIH funding after receiving proposal-preparation support. This is a verified financial outcome, but it is not a saving produced by the model; it belongs to the project-funding mechanism.

Data required for a similar pilot

The minimum data unit is not simply a photograph but a linked record:

  • batch and sample identifiers;
  • a class confirmed by an authorised expert;
  • the version of the quality criteria;
  • device, camera position, and capture settings;
  • lighting and background conditions;
  • date, shift, and operator;
  • model decision, confidence, and final human decision;
  • a disagreement reason when the expert corrects the result.

Training and test data should preferably be separated by batch, date, or supplier rather than randomly splitting adjacent images. Otherwise, nearly identical photographs of the same object can appear in both sets and inflate performance. The final evaluation needs genuinely new batches that were absent from development.

If images can contain personal data, supplier labels, or commercially sensitive information, retention, access, and deletion must be defined before upload. An on-premises design may be appropriate when photographs cannot leave the company or connectivity on the shop floor is unstable. Locality does not repair poor labels or replace model-version tracking.

Adapting the architecture for on-premises use

A compact small-business workflow can look like this:

1. A smartphone or fixed camera sends an image to an internal web interface.
2. A service checks size, format, sharpness, and framing.
3. A local model returns a class and confidence score.
4. A business rule automatically accepts only safe, high-confidence cases.
5. Remaining images go to an expert queue with neighbouring classes and batch history.
6. The approved decision is written to the system of record; corrections enter a dataset for later reevaluation.

FastAPI and Docker from the source case are optional, but they demonstrate a useful separation between interface and model. Inference can run on a small GPU or CPU server, depending on image resolution, model architecture, and required response time. For a few dozen inspections per hour, maintainability often matters more than maximum throughput.

Do not connect an automatic sorter immediately. At first, the model can act as a second opinion and display its estimate alongside the human decision. The next level is automatic approval of only simple cases. A mechanical action should follow only after fail-safe behaviour and error economics have been validated.

Economics: calculate decision cost, not camera cost

The smartphone makes the pilot inexpensive, but total cost comes from elsewhere:

  • expert time for class definition and labelling;
  • a stable image-capture station;
  • interface development, integration, and testing;
  • server or cloud compute;
  • review of uncertain cases;
  • data-drift monitoring and retraining;
  • process downtime when the system is unavailable;
  • false-accept and false-reject costs.

A basic economic model compares the monthly cost of current inspection with the new workflow, adds error costs, and measures the volume that can genuinely be handled without another employee. If an expert still reviews 100% of images at the same speed, the model may improve consistency or training, but it has not yet saved labour.

Payback appears when the system reliably removes part of repetitive work, reduces expensive mistakes, or allows higher volume without proportional headcount growth. Those effects should be measured separately.

A four-week pilot

A practical plan for one visual process:

  • Week 1: fix the classes, error costs, capture protocol, and baseline expert time and accuracy.
  • Week 2: collect representative batches, double-label disputed samples, and check image quality.
  • Week 3: train a baseline model and calculate macro‑F1, per-class metrics, and a confusion matrix on held-out batches.
  • Week 4: run the model as a second opinion and measure time, agreement, expert corrections, and cost per approved decision.

Continue if performance holds on new batches, an automatic-decision zone is clear, and economic value survives the cost of the manual queue. If the model is unstable, the pilot is still useful: it reveals whether the process needs better data, different optics, or no automation at all.

What management should take away

The main Big Saint Food lesson is to begin with a repeatable way to acquire data, not with an expensive camera or model name. A smartphone can be a sufficient sensor for hypothesis testing when the station is standardised, experts define the classes, rare cases are not hidden by an average metric, and a human retains the final decision.

Before approving a machine-vision budget, ask the team for one fixed experiment: the same camera, the same light, new batches, per-class metrics, and a modelled economic case. That test costs less than a 3D scanner and says much more than a demonstration on a handful of favourable photographs.