Industrial AI

AI for Metal Detector Investigations: What Food Plants Need First

Deborah Akande Interview contributor Last updated on August 24, 2026

When a metal detector rejects a pouch containing 45 stick packs, the detector has done only one part of the job: it has identified a product that requires investigation.

It has not identified the exact stick pack, machine, material, maintenance event, or process condition behind the rejection.

For a quality professional such as Deborah Akande, who works with HACCP, SQF, root-cause analysis, laboratory testing, and continuous-improvement methods, the next step may involve searching production records, maintenance history, material genealogy, detector checks, changeovers, and previous incidents.

In our interview, Deborah Akande described metal-detector investigations taking 3–4 hours when production, maintenance, material, and quality records are spread across several systems.

That creates a legitimate opportunity for better technology.

But the first question is not:

What does the AI think caused the rejection?

The first questions are operational and food-safety related:

Is the affected product under control?
Is the approved rejection and investigation procedure being followed?
Has the detector been verified according to the plant’s requirements?
What production or material scope may need to be held?
What evidence is required to determine the source and final disposition?

Only after those controls are in place does AI become relevant.

Its role should not be to decide whether the product is safe, release held material, or replace the qualified quality professional.

Its most useful role is narrower:

show the investigator where to look first and bring the supporting evidence together faster.

That is what AI-assisted quality investigation in food manufacturing should look like in practice.

What an AI-Assisted Investigation System Would Actually Do

An investigation system would begin when the detector rejection is recorded.

Ideally, the event would receive a unique identifier linked to the basic production context:

rejection timestamp,
detector,
line,
product,
finished-product lot,
work order,
detector result,
reject count.

The system could then retrieve the production context surrounding the event.

Depending on the plant’s traceability capability, it might identify:

the stick packs contained in the rejected pouch,
the machine or group of machines that could have produced them,
the relevant production time window,
ingredient lots used in the batch,
packaging-material lots,
recent maintenance work,
the most recent product changeover,
previous detector rejections involving the same SKU,
open corrective actions involving the equipment,
and detector test-piece verification results.

The important phrase is depending on the plant’s traceability capability.

Not every factory can identify the exact machine and timestamp associated with every individual stick pack.

That level of genealogy may require synchronized machine timestamps, PLC or MES integration, reliable line-routing data, serialization, container identification, or another traceability mechanism.

A plant should therefore distinguish between:

Current capability: what its systems can reliably prove today.

Target capability: what it would eventually like to trace.

An investigation system must be designed around the first one.

What the Investigator Should See

The system’s output should not pretend to prove the root cause.

It should organize the investigation.

For example:

Most relevant investigation areas

Packaging machine 6
Review because a previous rejection followed maintenance on the sealing assembly.
Ingredient lot A142
Review because the lot is connected to previous foreign-material investigations.
Recent changeover activity
Review because the current product followed a production run using an aluminum-lined ingredient package.

Evidence to review

maintenance record for machine 6,
receiving and inspection records for ingredient lot A142,
changeover verification,
detector verification results,
other rejects from the same production period.

This is an investigation priority list.

It is not proof.

The quality professional still decides what inspections, tests, interviews, or additional records are needed.

The system creates value when it reduces time spent searching for records and testing low-value explanations.

The First Technical Step Is Not Choosing an AI Model

The first technical step is defining the rejection event.

Every rejection should have a unique identifier that allows the detector signal to be connected to the relevant production records.

A practical minimum event structure could include:

Data category	Typical information
Rejection	Event ID, timestamp, detector, result, reject count
Product	SKU, customer if relevant, formula, lot, work order
Packaging	Pouch or container ID where available, packaging line or machine
Materials	Ingredient lots, packaging-material lots, suppliers
Operations	Shift, production period, line speed, changeover, significant adjustments
Equipment	Maintenance history, downtime, recent repairs or component changes
Quality	Detector verification, inspection results, quantity placed on hold
Investigation	Failure mode, investigation status, confirmed cause if known, corrective action, verification, disposition

The exact fields will vary by plant.

What matters is that the records can be connected reliably.

The Field Plants Often Miss: The Confirmed Investigation Outcome

It is not enough to record that a package was rejected.

The historical record must show what the investigation actually concluded.

But this information should not be stored in one vague “root cause” field.

Different concepts need to be separated.

For example:

Investigation field	Example
Failure mode	Ferrous material detected
Suspected source	Packaging machine
Confirmed root cause	Damaged fastener on sealing assembly
Investigation status	Confirmed
Affected scope	Product produced between defined start and end times
Corrective action	Fastener replaced
Verification	Equipment inspected and detector challenge completed
Product disposition	Released, reworked, destroyed, or other approved disposition

Other investigations may conclude:

metal contamination associated with equipment wear,
foreign material introduced during ingredient handling,
damaged packaging-machine component,
detector false rejection,
source not confirmed after investigation.

A statement such as “product cleared after retesting” belongs under disposition or verification.

It is not a root cause.

That distinction becomes especially important if historical investigations will eventually be used to train a predictive model.

Which Technology Fits Each Part of the Problem?

The project should not rely on one AI model for everything.

In fact, several valuable parts of the system are not AI at all.

Different parts of the workflow require different tools.

1. Rules Should Handle Known Requirements

Use deterministic rules when the correct requirement is already defined.

Examples might include:

the required detector verification must have been completed,
the active product must match the approved work order,
production cannot begin before required pre-operational approval,
a held lot cannot be released without authorization.

These controls do not require machine learning.

Using AI for a fixed requirement adds complexity without improving the control.

2. Retrieval Should Organize Existing Records

Retrieval may be the first area where advanced software creates significant value.

An investigator could ask:

Show me previous metal-detector incidents involving machine 6 during the last six months, including confirmed causes, corrective actions, and verification results.

A retrieval system could find the approved internal records and present the most relevant results.

A large language model could help summarize those records.

But the original controlled documents should remain the source of truth.

The language model should retrieve and organize approved records.

It should not become the quality record itself.

This is also safer than asking a general-purpose chatbot to invent a root cause from a short incident description.

3. Anomaly Detection Should Identify Unusual Conditions

Anomaly detection compares current production behavior with an established normal pattern.

It could help flag:

an unusual increase in detector rejections,
seal or packaging failures concentrated around one machine,
unusual package-weight distribution,
more coding corrections than normally occur during startup,
abnormal defect behavior following maintenance,
or a supplier lot behaving differently from comparable historical lots.

An anomaly is not a confirmed root cause.

It is a reason to investigate a condition more closely.

This approach can be useful when the plant has enough process data to recognize abnormal behavior but not enough confirmed historical cases to predict a specific failure reliably.

4. Supervised Learning May Eventually Rank Likely Causes

A supervised model learns from historical incidents with trustworthy, labelled outcomes.

For a new rejection, it might rank investigation paths such as:

packaging equipment,
ingredient or material source,
changeover activity,
detector-related issue,
unresolved or other source.

The ranking can help determine where the investigator looks first.

But the article should not attach precise-looking probabilities such as 48%, 27%, or 15% unless the model has actually been trained, calibrated, and validated well enough for those probabilities to have meaning.

Otherwise, mathematical precision can create false confidence.

The model is useful only when the historical root-cause records are consistent, the labels are trustworthy, and there are enough examples representing the relevant failure modes.

There is no universal number of historical cases that automatically makes a cause-ranking model reliable.

A few dozen cases may be enough to test data availability and retrieval.

They are not automatically enough to train a dependable predictive model.

Why Poor Root-Cause Records Will Break the Model

Many factories already use standard incident-report templates.

That improves consistency, but a prepared form is not the same as analytical-quality data.

Consider two records.

Record A

Metal detector rejected pouch. Product retested. Machine checked. Staff retrained.

Record B

Ferrous contamination confirmed in a stick pack associated with machine 6. Investigation identified a damaged fastener on the sealing assembly. Product from the defined production window was placed on hold. The fastener was replaced, the equipment was inspected, detector verification was completed, and the affected product received documented disposition.

Record B provides much more useful information.

It identifies:

the failure mode,
suspected and confirmed source,
equipment involved,
affected scope,
corrective action,
verification,
and disposition.

Record A does not.

Before using historical reports for analytics or machine learning, review:

whether the root cause was confirmed or only assumed,
whether the affected equipment was identified consistently,
whether the affected product boundary was documented,
whether corrective actions were specific,
whether verification results were recorded,
whether unresolved investigations were clearly identified.

Do not force every investigation into a confirmed category.

“Unknown after investigation” is more useful than an incorrect root-cause label.

False certainty creates bad training data.

A machine-learning model trained on weak investigation records will reproduce the weaknesses of those records at scale.

How the Investigation Workflow Would Change

The current process may require the quality professional to open several systems, review detector records, inspect production documentation, contact maintenance, trace materials, and reconstruct what was happening around the rejection.

A better digital workflow would reduce that search effort without changing the plant’s food-safety authority.

Step 1: Capture and Control the Rejection

The detector rejection is linked to an event containing the correct time, line, product, batch, and work order.

Where technically possible, basic information should be captured automatically rather than manually re-entered.

The plant’s approved procedure still controls:

containment,
detector checks,
product hold,
escalation,
investigation,
and disposition.

The investigation system does not replace these controls.

Step 2: Build the Production Timeline

The system retrieves significant events from a defined period around the rejection.

These could include:

product changeover,
machine startup,
maintenance intervention,
detector verification,
ingredient introduction,
operator adjustment,
previous minor rejects,
production interruption.

The investigation window should be based on the plant’s process, traceability capability, and risk assessment.

It should not be an arbitrary AI setting.

Step 3: Identify Connected Products and Materials

The system shows which other products share relevant conditions with the rejected product.

Depending on the plant’s available data, this could include a shared:

machine,
ingredient lot,
packaging lot,
production period,
work order,
or maintenance event.

This information can help the quality team establish the appropriate investigation and hold boundary.

The system provides evidence.

The qualified plant team determines the official scope according to approved procedures.

Step 4: Rank Investigation Paths

The system brings the most relevant evidence to the investigator.

Initially, this may be based primarily on retrieval and rules.

Later, validated anomaly detection or cause-ranking models may provide additional prioritization.

The quality professional still decides which tests, inspections, interviews, or records are required.

Step 5: Record the Confirmed Outcome

At closure, the investigation should record:

failure mode,
investigation status,
confirmed root cause when supported,
affected quantity or scope,
corrective action,
verification,
final product disposition.

That information becomes evidence for future investigations.

This is what turns an investigation system into a learning system.

Where machine vision fits

Machine vision is an adjacent quality-control application rather than the main subject of this article. It can support label verification, date-code inspection, seal or cap presence, fill-level checks, packaging integrity, and other line-side checks.

The same controls still matter: the approved code must come from a controlled source, the active SKU must be confirmed, the reject mechanism must remove the correct package, and employees need a recovery procedure for unreadable or uncertain images.

If a plant chooses vision as its first pilot, validate it against real production variation, line speed, lighting, sanitation conditions, false accepts, false rejects, reject confirmation, and operator recovery. Treat it as a separate pilot with its own acceptance criteria.

How to Pilot the Investigation System Without Creating Food-Safety Risk

The first pilot should run in shadow mode.

The system receives real or representative production information and generates investigation support, but it does not:

release product,
dispose of product,
redefine the official hold,
stop the line autonomously,
or override the approved procedure.

Quality employees continue following the established process.

For each rejection, compare:

the investigation path chosen by the quality team,
the evidence ranked or retrieved by the system,
the confirmed outcome,
the time saved or added,
important evidence the system missed,
irrelevant or incorrect recommendations.

A practical pilot can be divided into four phases.

Phase 1: Reconstruct Historical Cases

Start with a representative set of previous investigations.

Thirty to fifty cases may be enough to expose basic problems in:

event matching,
timestamps,
genealogy,
missing fields,
investigation quality,
document retrieval.

This sample can help determine whether the plant is ready for retrieval and rules-based investigation support.

It should not automatically be treated as sufficient training data for a cause-ranking model.

The amount of data required for prediction depends on:

number of failure modes,
class balance,
process stability,
quality of the labels,
available predictive signals,
and variation between products and lines.

Phase 2: Build a Retrieval-First Investigation Workspace

Before predicting root causes, bring the relevant records together.

From one incident screen, the investigator should be able to access the most relevant:

detector data,
production context,
material records,
maintenance records,
previous incidents,
corrective actions.

This phase often creates value before predictive AI is necessary.

For a related look at why AI projects depend on connected production data, see CPAI’s guide to why AI in manufacturing starts with data. For traceability testing, see the batch genealogy guide for food and beverage managers.

It also exposes integration problems that need to be solved first.

Phase 3: Add Cause Ranking in Shadow Mode

If the historical data becomes sufficiently trustworthy, a cause-ranking model can be tested without changing the official process.

The system ranks possible investigation paths.

Quality employees document whether the ranking was useful.

The plant should evaluate performance using held-out historical cases and live shadow-mode events.

If the ranking is unstable, misleading, or unsupported by the available data, the system should remain focused on retrieval and rules.

Prediction is optional.

Reliable investigation support is the objective.

Phase 4: Add Controlled Alerts or Escalation

Only after the system performs consistently should the plant consider allowing it to trigger controlled actions such as:

requesting additional inspection,
highlighting repeated failure patterns,
notifying maintenance or quality personnel,
requesting additional evidence,
escalating a recurring condition.

Product-release and disposal decisions should remain within the plant’s approved authority structure.

What Success Should Look Like

Model accuracy is not enough.

The system should improve the investigation workflow.

The plant should establish a baseline before the pilot and compare performance against it.

Useful measures include:

Measure	What it reveals
Time to identify likely investigation areas	Whether evidence retrieval is faster
Time to final disposition	Whether the overall investigation is faster
Time to establish affected scope	Whether traceability supports faster containment decisions
Investigator search time	Whether employees spend less time locating records
Useful top-ranked evidence rate	Whether ranking helps investigators
Critical evidence missed	Whether the system creates investigation risk
False-alert rate	Whether the system generates unnecessary work
Complete structured incident records	Whether data quality is improving
Repeat incidents	Whether corrective actions are preventing recurrence
Quantity placed unnecessarily on hold	Whether the affected scope can be defined more precisely

The most useful model may not identify the final root cause as its first suggestion every time.

It may still create value if the relevant evidence consistently appears near the top of the investigation and the supporting records are easy to retrieve.

Instead of adopting an arbitrary target from another plant, each facility should set success criteria from its own baseline.

For example, a plant might aim to:

reduce evidence-gathering time,
shorten investigation duration,
reduce unnecessary search effort,
improve the precision of hold boundaries,
increase the percentage of investigations with structured outcomes,
reduce repeated failures associated with the same equipment or process.

The baseline must be measured before the pilot begins.

Why Investigation Speed Matters

A rejected pouch can look like an isolated event.

Sometimes it is.

Sometimes the source is associated with a larger production period, material lot, supplier input, or equipment condition.

In those cases, the ability to establish relationships quickly matters.

In fiscal year 2024–2025, the Canadian Food Inspection Agency reported 131 food-recall incidents and 233 total recalls. Its food-safety investigations data records 1,632 investigations involving extraneous material, a category that includes foreign materials such as metal.

A recent example is the Sifto Hy·Grade salt investigation, in which metal contamination led to secondary recalls involving products made with the affected salt.

The operational lesson is straightforward:

A material or contamination event that appears isolated can affect multiple finished goods when they share a supplier lot, production period, or other common input.

That is why the plant needs to know quickly:

which products share the lot,
which products share the machine,
which products share the production period,
and which records support the final investigation boundary.

The business case does not need to depend on an old industry estimate claiming that every recall has the same average cost.

The more defensible argument is measurable inside the plant.

A better investigation system may help:

establish affected scope sooner,
avoid unnecessarily broad holds,
reduce employee search time,
improve root-cause documentation,
improve corrective-action learning,
and respond faster when an event could affect multiple lots or products.

The Practical Decision for Plant Leaders

A metal detector rejection reveals a specific technology opportunity.

The plant already knows that something requires investigation.

The delay comes from determining:

where to look,
what else may be affected,
which records are relevant,
and what evidence supports the final conclusion.

Before approving an AI project for that problem, plant leaders should ask four questions.

1. Are Rejection Events Recorded Consistently?

Can the plant reliably identify:

when the event occurred,
which detector was involved,
which product was running,
which lot and work order were active?

If not, the first project is better event capture.

2. Can Product, Machine, Material and Maintenance Data Be Connected?

Can an investigator reconstruct the relevant production context without relying primarily on memory, phone calls, and disconnected spreadsheets?

If not, the first project is integration and traceability.

3. Do Historical Investigations Contain Trustworthy Outcomes?

Are confirmed causes separated from assumptions?

Are unresolved investigations labelled honestly?

Are corrective actions and verification documented?

If not, the first project is improving the investigation record.

4. Do Qualified Employees Own the Final Decision?

The system can retrieve, organize, flag, and rank evidence.

Qualified plant personnel must continue to own:

containment,
investigation,
product hold,
food-safety decisions,
release,
rework,
disposal,
and corrective-action approval.

Technology should strengthen that authority, not blur it.

When the first project is not AI

When the four readiness conditions are missing, the first project is workflow and data improvement: event identification, traceability, connected production records, structured root-cause fields, and clear ownership. Those changes can create value before predictive machine learning is introduced. The objective is reliable investigation support, not AI for its own sake.

The real role of AI in food-plant quality investigations

When the foundation is strong, AI can turn a broad investigation into a focused search. For Deborah, that may mean moving from hours of record hunting to a prioritized set of machines, materials, events, and historical cases, with the underlying records attached for review.

The benefit is not that a model replaces the quality professional. The benefit is that the quality professional reaches relevant evidence faster while retaining responsibility for containment, holds, investigation, release, disposition, and corrective action.

The right first investment is therefore clear: build reliable event records, traceability, connected production data, honest investigation outcomes, and validated technology before asking AI to rank causes.

Sources and further reading

Next step: If your plant is considering a retrieval-first pilot, contact CPAI to discuss the data, ownership, and validation questions.

Featured in this article

Interview contributor

Deborah Akande

Deborah Akande is a Quality Assurance Specialist and Food Safety Coordinator whose public professional profile identifies expertise in HACCP, SQF, root-cause analysis, internal audit, regulatory compliance, SFCR/CFIA, and Lean Six Sigma process optimization.