Direct answer

An automated system can record the evolution of an interface or associated signal during a test and derive a curve, characteristic times and slopes under documented conditions. It can also improve the traceability of reading times and retain the record for review.

That does not by itself demonstrate metrological accuracy, sample representativeness, flocculant savings, water recovery, thickener stability or control capability. Each claim requires its own test and acceptance criterion.

What it can measure directly

The term ‘directly’ should be reserved for the signal captured by the system. Depending on the architecture, this may be a position detected in an image, optical intensity, a distance or a time mark. Interface height may already depend on an algorithm and an operational definition.

The minimum record should retain:

  • test and sample identifier;
  • start time and time base;
  • original signal or sufficient evidence to audit it;
  • spatial scale, geometry and initial height;
  • configuration and algorithm version;
  • visibility incidents, bubbles, movement or loss of detection;
  • the person or system responsible for preparation and execution.

Without those elements, a curve may be reproducible as a file but not traceable as a measurement.

What it can derive

The time series can be used to calculate height versus time, velocity over an interval, time to reach a height, final height within a window and curve-shape features. Derived quantities must retain their link to the original data and calculation method.

A slope must not be reported without the interval used. A characteristic time must not be compared if the initial height or interface criterion changed. An automated classification must state the conditions under which it was trained or validated.

Software can execute the same calculation many times. That computational consistency does not remove variability in the sample, mixing, reagent, vessel or physical phenomenon.

Three verification levels that must not be confused

  • Functional verification The system starts, records, stores and retrieves a test without losing data or altering identifiers.
  • Metrological verification The indication is compared with a reference and resolution, bias, repeatability, range and uncertainty are estimated under defined conditions.
  • Process-utility validation The result is linked to a plant decision or response and demonstrates performance in the regimes where it is intended to be used.

Passing one level does not automatically establish the next. A correctly stored file does not demonstrate that height is accurate. A validated height does not demonstrate that changing a dosage improves the thickener.

What it does not prove by itself

  • that the sample represents feed over an operating period;
  • that an interface velocity is a constant property of the tailings;
  • that the algorithm detects every interface or turbidity condition;
  • that a laboratory dosage transfers to the plant;
  • that faster settling produces better overflow or underflow;
  • that flocculant or make-up water is reduced;
  • that an alert leaves enough time for action;
  • that the system is integrated into thickener control;
  • that a correlation with plant variables is causal;
  • that client results are authorised for publication.

These exclusions do not reduce the value of the test. They define the additional evidence needed to advance from observation to comparison, diagnosis and decision.

How to design proportionate validation

First formulate the exact claim. To claim that the system measures height, compare it with a length reference and a reading criterion. To claim that it distinguishes materials, evaluate replicates, within-regime variation and data not used to fit the classification. To claim anticipation, demonstrate the temporal sequence relative to the thickener.

The protocol should set conditions, reference, range, replicates, excluded data and the acceptance criterion before the result is observed. Negative results and uninterpretable conditions must also be recorded.

Public GENKO evidence must keep functional status, verified measurement and process results separate. The GENKO Evidence page is the appropriate place to maintain that distinction and update it when new authorised evidence exists.

Implications for purchase, pilot and operation

A solution should be evaluated through a claim-evidence matrix. Each proposed benefit must be linked to data, method, scope and an approval owner. Functional demonstrations are useful for reviewing workflow; comparative pilots estimate performance under agreed conditions.

Integrating an output into operation also requires availability, failure handling, cybersecurity, maintenance, version traceability and a safe rule for cases where the result is unavailable or outside the validated range.

This page does not certify GENKO or another instrument. It defines the evidence standard that should apply before test results become technical or commercial claims.

Sources and evidence status