Your ML team isn't the bottleneck.

This is a condensed reading of Unnatural Selection, the VEOX technical brief. The brief argues that the returns on conventional machine learning investment are capped by something structural rather than something fixable by hiring, and it puts a specific alternative — inventing and verifying algorithms rather than selecting them — under an evaluation protocol designed to catch it cheating. Everything below is drawn from that document; the full paper carries the protocol in detail and the complete source of every pipeline it reports.

The ceiling is structural#

Most enterprise ML value is created in bounded, messy, structured settings: risk, fraud, churn, compliance flags, incident likelihood. These problems tend to be tabular, small-to-medium, noisy, and full of partial correlations — signals that look valid and then vanish in production. That combination punishes leakage, weak evaluation and generic recipes.

The brief separates the field into three tiers. A Tier 1 team applies standard recipes — XGBoost, LightGBM, logistic regression — and reaches a stable, mediocre plateau. A Tier 2 team brings serious tooling and serious evaluation: AutoGluon, DataRobot, SageMaker Autopilot, heavy ensembles, real feature work. It is a genuine improvement, and it runs into a wall that is not about effort.

Both tiers are confined to the same menu of human-authored algorithms. They can combine XGBoost, random forests and neural networks in unlimited ways, but they cannot invent a method that is not already in the library. If the signal requires a transformation that does not exist in scikit-learn, no amount of searching will surface it.

Tier 3 — what the brief calls engineered intelligence — changes the unit of progress. Rather than selecting from the catalog, it decomposes algorithms into typed stages, evolves new stages, verifies them, and recomposes the survivors into complete pipelines. The catalog stops being an input and becomes an output.

Enterprise data is not a competition dataset#

The brief is blunt about why results that look good in a notebook do not survive contact with production. In competitive data science the dataset is a sanitised product: stable columns, a clear target, and a metric worth over-optimising. In an enterprise, data is closer to a hostile actor. It drifts. It contains subtle leakage — a next_payment_date column that quietly encodes the answer. It is full of correlations that hold right up until they do not.

This is the setting in which searching harder becomes actively dangerous, because standard algorithms cannot tell a robust causal signal apart from a fragile statistical artefact.

How the numbers were produced#

The brief puts its evaluation protocol before its results, which is the right order — a super-human score and super-human overfitting are indistinguishable without one. Three controls matter most.

A sealed holdout

For every dataset, 20% of the data is cryptographically sealed — SHA-256 hash verified — before any search begins. All three tiers see the same 60% train and 20% validation splits. The final score is computed on the sealed fifth once, at the end, and no result from it is ever passed back to the search. The search agent never sees it at all.

Leakage controls

• Where rows carry a time order (crypto, lending), splits are strictly chronological — no future row is available to a past prediction.
• Patient IDs and user IDs are kept distinct across splits, so a model cannot score by memorising a subject.
• Columns describing the future are removed before ingestion.

Safety floors, not "better than random"

A model is only accepted if it clears a domain floor: 0.60 AUC for credit and churn, 0.70 for clinical work, with calibration error held under 0.10 where calibration matters. Anything below is discarded as noise rather than reported as a result.

What the evidence shows#

Seven notoriously difficult "graveyard" datasets were audited — small samples, high noise, complex interactions, the places where standard AutoML flattens out. Reading the two comparison tiers against the same Tier 1 baseline is the clearest way to see what happened.

The same figures, with the absolute baseline each percentage is measured against:

The trap in the Tier 2 column

The Pima result is the one worth pausing on. A Tier 2 system runs thousands of models and keeps the one with the best validation score — and by selecting the maximum of thousands of trials, it selects the model that got luckiest on validation. The brief calls this the overfitting trap, and it is why a Tier 2 holdout score can land below a Tier 1 one. More search against a reusable validation set is not more evidence.

The three +0.00% rows say something else. On Lending Club, credit scoring and crypto, the Tier 2 system searched hard and returned the baseline: better mixing of static ingredients cannot close an information gap when the signal is not reachable by any combination of stock components.

What the search actually invents#

Tier 3 treats code as a genome and runs an evolutionary loop over four operators. Fitness is not raw AUC but a robustness measure that penalises the gap between train and test and rewards generalising across other datasets. Cross-over mates verified structures, so a feature transformation proven on credit scoring can be bred with a risk adjuster from medical data. Mutation refines boundaries by directed micro-evolution rather than random guessing. Creation is the differentiator: the system generates new compute units — interaction-term generators, fusion strategies, specialised architectures — and injects them into the pool.

The appendix makes this concrete, and the evolved pipelines are not recognisable as anything out of a template:

• On Lending Club, a generative fusion layer in which a meta-learner predicts the ensemble weight per sample at inference, so the system trusts different branches depending on the individual borrower — rather than fixing one blend for everybody.
• On EEG Eye State, an uncertainty-weighted fusion that adjusts each branch's influence by the entropy of its own predictions, so only confident signals drive the result.
• On credit scoring, a Gaussian process over polynomial interactions combined by averaging log-odds rather than probabilities — a consensus that penalises models which are confidently wrong.

Each verified component is retained. That is the compounding claim in the brief: a discovery made for one problem becomes a permanent asset available to every future search, and the library grows into an institutional asset rather than walking out of the door with the person who wrote it.

Evaluation as security#

Any system that searches at volume will eventually find seams in its own evaluator. When an objective becomes a target, it stops being a good measure — so the brief treats evaluation as an adversarial problem and names the search agent as the attacker. Three failure modes are scoped explicitly: evaluator gaming, where candidates overfit quirks of the test suite; leakage, where the proposer learns too much from intermediate feedback; and false accepts, where rare evaluator errors become inevitable at scale.

Three defences answer them. The sealed holdout is an air gap the agent cannot reach. A complexity penalty means that where two models perform equally, the simpler one wins. Automated scanners look for time travel and ID leakage.

The behaviour on failure is the part worth checking in any vendor claim. When no safe, novel model beats the baseline, the run returns the best Tier 1-equivalent baseline and emits a report explaining the rejection — for example, that every novel candidate failed calibration against validation. It does not ship an unsafe artefact to demonstrate activity.

Where it fits, and what it is not#

Input is a standard warehouse or object store — Snowflake, BigQuery, S3 Parquet. The search itself runs on an ephemeral cluster, and more compute buys a faster search rather than a different method. What comes out is auditable source code, packaged as a Python wheel or a Docker container. Serving is a plain .predict() call: no exotic runtime, no GPU for inference, deployable on-premise or in a cloud.

The brief is equally specific about the limits, and they are worth quoting in a summary because they are the claims a buyer should hold it to:

• Not a foundation model trainer. This does not train LLMs or diffusion models; it targets structured enterprise data.
• Not a magic wand. If the signal is not in the data, no amount of evolution will find it.
• Not instant. Search duration is chosen by the practitioner, from thirty minutes to days.
• Not zero-governance. The code is generated; the safety constraints still require oversight, and a human reviews the final artefact before deployment.

The bottom line#

For decades software has been written in stone: an algorithm composed today is identical tomorrow. The argument of the brief is that this is the actual constraint on production ML, and that lifting it requires an invention engine with governance attached — explicit verifiers, sealed holdouts, novelty auditing, replayable logs — rather than another round of tuning against the same catalog.

The question the brief leaves with a technical leader is a practical one. When the plateau arrives — and on the evidence above it arrives whether or not the tooling is good — do you hire, tune, wait, or build something that compounds?