When machine learning is not the next step for a scientific dataset

A team has 42 participants, one outcome per participant and 86,400 ten-second windows. The feature table has 3,200 columns. A gradient-boosting model reaches an AUC of 0.91 after random window splitting.

The project does not have 86,400 independent examples. It has 42 participants and one outcome measured 42 times.

I would stop the model build there and inspect the study.

“Predict fatigue” is not a decision.

Ask who will see the output, when they will see it and what they can change because of it.

User: laboratory researcher
Timing: after each completed recording
Output: probability that the recording contains a usable response
Action: retain, review or repeat the session
Cost of false positive: analyst time and contaminated estimates
Cost of false negative: unnecessary repeat visit

That is an analysable use case.

Compare it with:

User: unspecified
Timing: unspecified
Output: fatigue score
Action: unspecified

A model can still be trained. Its metric has nowhere to land.

For health prediction studies, TRIPOD+AI requires authors to state the intended use, target population, outcome, predictors, sample-size rationale and evaluation methods.^[a6-1] Those fields are useful outside clinical prediction too. A model built without them becomes a flexible answer to a question that can change after the score appears.

A label can be numeric and still be unsuitable.

Examples:

• a questionnaire collected once is copied onto every minute of an eight-hour recording;
• “event onset” is taken from a technician note rounded to the nearest five minutes;
• two image annotators disagree on whether touching cells form one object or two;
• machine failure time is recorded when maintenance arrived, not when degradation began;
• a diagnostic code reflects billing practice as well as disease;
• treatment response is defined after looking at the observed trajectories.

Measure the target before predicting it.

For repeated ratings, inspect within-person variation and test-retest reliability. For annotations, use overlapping labels from two readers and record the disagreement type. For event logs, reconstruct how the timestamp entered the system. For composite outcomes, calculate which component drives the variation.

If the target changes materially under two defensible definitions, the first deliverable is a target-definition report.

Windowing is useful for signal representation. It can also make a small study appear huge.

Suppose 30 participants each provide 1,000 windows. The training table contains 30,000 rows. For a new-participant claim, the effective independent unit remains the participant.

The same problem appears elsewhere:

• thousands of cells nested within six animals;
• hundreds of images from four tissue blocks;
• repeated measurements from eight machines;
• patches cut from 12 whole-slide images;
• daily observations from five sites;
• multiple spectra from the same physical specimen.

Riley and colleagues’ sample-size framework for clinical prediction models starts from the number of participants and outcome events, anticipated model fit and precision requirements, rather than a universal events-per-variable rule.^[a6-2] Deep learning does not repeal the sampling hierarchy.

Before fitting, create this table:

If the unit that must be new has 42 observations, model complexity should be discussed in terms of 42.

A model often finds the cleanest separator available.

Imagine a microscopy dataset where all treated images were collected on Tuesday with a new exposure setting, while controls were collected on Monday. A classifier can identify treatment from brightness and sensor pattern noise.

Other shortcuts are less obvious:

• positive participants used firmware 1.4 and controls used firmware 1.2;
• one hospital contributed most severe cases;
• files from one class were compressed by another export process;
• missing channels occur mainly in one outcome group;
• the protocol always presents condition A before condition B;
• a technician repositioned the sensor only for difficult participants;
• background pixels retain plate or scanner identity;
• the length of a clinical note reveals the target.

Build a confound table before the feature table:

Kapoor and Narayanan documented leakage across at least 294 papers in 17 scientific fields and described eight leakage classes.^[a6-3] Leakage includes more than accidental duplicate rows. Study design, preprocessing and feature availability can place information from the answer inside the predictors.

A complex model should beat something that a sceptical colleague could implement in an afternoon.

For classification:

• class-prior predictor;
• majority class;
• one prespecified clinical or physical threshold;
• logistic regression;
• a model using only site, device or missingness indicators.

For regression:

• mean or median prediction;
• previous observation;
• subject baseline;
• linear trend;
• simple domain equation.

For forecasting:

• persistence;
• seasonal naïve forecast;
• moving average;
• last valid value.

DummyClassifier and DummyRegressor in scikit-learn explicitly ignore the input features and provide rule-based baselines.^[a6-4] They are not toys. They expose targets where class imbalance or a stable mean makes an accuracy figure look impressive.

A wearable classifier with 92 per cent accuracy against a 90 per cent majority-class baseline has not earned 3,200 features.

I also fit a shortcut baseline. If device ID, recording length and missingness reproduce most of the model’s score, the model has described the data-collection system.

A feature can be present in the retrospective table and unavailable at the decision point.

Common examples:

• a “baseline” calculated using the whole recording;
• a normalisation constant estimated from future samples;
• final length of stay used to predict deterioration at admission;
• pathology measurements obtained after the treatment decision;
• a manually corrected event marker produced during later review;
• failure labels back-filled from a maintenance investigation;
• batch correction fitted using the held-out experiment;
• summary statistics calculated after the event being predicted.

Add availability to the data dictionary:

feature: rolling_signal_quality_5min
source: wearable channel 2
available_at_prediction: yes
latency: 10 seconds
requires_future_samples: no
requires_manual_review: no
failure_mode: absent when contact is lost

Delete or redesign features that need future knowledge. Do this before comparing algorithms.

There are datasets where another collection round is valuable only after changing the protocol.

I would pause modelling when:

• the event marker was logged in a different clock with no shared anchor;
• one class was collected under a different acquisition configuration;
• a sensor saturated during the condition of interest;
• the reference channel failed systematically;
• labels are missing for the difficult cases;
• every participant experiences conditions in the same order;
• the outcome is measured after an uncontrolled delay;
• ground truth was created by the same algorithm being evaluated.

Collecting 100 more sessions under the same confound can make the wrong result more precise.

A protocol-repair document should name:

• the variable to randomise or balance;
• the technical marker to record;
• the calibration or control condition;
• the minimum metadata fields;
• the unit of replication;
• the planned held-out group;
• the failure that triggers repeat collection.

Prediction is one analysis mode.

Suppose the question is whether a stimulus changes a physiological trace within participants. A mixed-effects model, event-related average, functional analysis or prespecified contrast may address it directly. Turning the condition into a classification label can obscure timing, effect direction and participant variation.

Suppose the question is whether a new image pipeline agrees with manual counts. Agreement analysis, error stratification and Bland-Altman plots are more informative than a model trained to predict the manual count from unrelated metadata.

Suppose a sensor manufacturer wants to know why false alerts occur. A failure taxonomy and threshold analysis may remove most alerts before anomaly detection is justified.

Machine learning should enter when the desired output is predictive, the inputs are available at the required time and a learned relationship offers something beyond the baseline.

A saved estimator can be a small file. The operating system around it includes:

• ingestion;
• schema validation;
• versioned preprocessing;
• feature computation;
• calibration;
• monitoring;
• failure handling;
• user interface;
• access control;
• documentation;
• retraining decisions;
• support when the input distribution changes.

Sculley and colleagues described ML-specific technical debt including data dependencies, hidden feedback loops, configuration debt and changes in the external world.^[a6-5] A research prototype can avoid some production concerns, but it still needs a reproducible path from raw input to reported result.

For a task run twice a year on 60 samples, a reviewed Python command and a QC report may be preferable to a continuously deployed model.

Two more conditions require a separate commercial and governance decision: the output would influence diagnosis or treatment, or a false result could create safety-critical industrial loss. Those projects need intended-use, liability and insurance review before technical scoping.

I use a short feasibility phase to produce evidence rather than a miniature production model.

Inputs

• representative raw data;
• data dictionary;
• collection protocol;
• target definition;
• group identifiers;
• current code or notebook;
• intended user and decision;
• known failure cases.

Work

1. reconstruct the sampling hierarchy;
2. audit target provenance and availability;
3. test target association with site, device, date, missingness and protocol;
4. define the deployment-relevant split;
5. fit dummy, simple and shortcut baselines;
6. run one bounded challenger model where the data support it;
7. inspect participant, batch or asset-level errors;
8. identify the smallest useful next collection or pipeline change.

Output table

A negative feasibility result should include runnable code, failed comparisons and a data-collection plan. “Insufficient data” without showing the limiting structure is a dismissal, not an analysis.

Send the raw-unit table rather than only the model matrix.

Include:

• number of participants, specimens, devices, batches or assets;
• number of repeated observations inside each;
• target definition and who assigned it;
• date, site, device and protocol fields;
• the earliest time at which each predictor exists;
• current train/test split;
• majority-class or simple baseline;
• three cases where the current model fails;
• the decision the output is expected to change.

A table with 80,000 rows and no participant column is not ready for a quote.

References

Collins GS, Moons KGM, Dhiman P, et al. TRIPOD+AI statement: updated guidance for reporting clinical prediction models that use regression or machine learning methods. BMJ. 2024;385:e078378.

Riley RD, Ensor J, Snell KIE, et al. Calculating the sample size required for developing a clinical prediction model. BMJ. 2020;368:m441.

Kapoor S, Narayanan A. Leakage and the reproducibility crisis in machine-learning-based science. Patterns. 2023;4(9):100804.

scikit-learn developers. Dummy estimators. scikit-learn documentation.

Sculley D, Holt G, Golovin D, et al. Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems 28. 2015.