The category

Engineered intelligence, defined.

A definition is only useful if something could fail it. This one is written as three mechanical commitments, so that a system can be held against them and found not to be one.

Engineered intelligence is a system that searches a space of model structures rather than fitting members of a family you named, scores every candidate on more than accuracy — for jAIn, on held-out accuracy and inference cost jointly — and returns an artefact you own and run rather than an endpoint it serves. A person sets the objective and the budget. The machine decides what to try.

The three commitments, and how each one can fail

1. The structure is what is being searched

In most automated tooling, the space is a list of algorithms and their arguments: try random forest, try gradient boosting, try these depths and these learning rates, pick the best score. The set of things it can find is the set somebody enumerated. The search is over configurations of known models.

Engineered intelligence puts the composition itself in the space — preprocessing, model family, hyperparameters, ensembling, pruning and distillation as one joint search rather than six decisions taken in order. That matters because those decisions interact: the best encoding of a high-cardinality column depends on the model that consumes it, and choosing them one at a time takes the best of each stage rather than the best pipeline. A system fails this commitment if you can write down, in advance, the finite list of structures it is capable of returning.

2. Accuracy is not the whole fitness

A search optimises what it is scored on, exactly and without judgement. Score it on held-out accuracy alone and it will find the nine-model stack that wins by a shade and takes an order of magnitude longer to answer — which is why so many automated winners are expensive to serve, and why they are so often quietly replaced with something simpler before they reach production.

jAIn scores every candidate twice: once on held-out accuracy under your metric, once on what it costs to serve. A candidate that buys a point of accuracy and triples inference cost loses. The winners are lean because leanness is scored — not because a second stage compressed them afterwards. A system fails this commitment if serving cost is a filter applied after the search rather than a term inside it.

3. The output is an artefact, not an endpoint

What comes back is plain code and weights you own and deploy. If you stop paying, what the search found is still serving traffic. This is the commitment most often failed on purpose: a platform that returns predictions rather than a model has a better business and gives you a worse asset. It is also the one that makes the other two checkable — you can inspect the structure that was found and time it on your own hardware.

How this differs from the three things it gets confused with

AutoML Automates selection and tuning within a named library of model families, and usually scores on accuracy alone. The distinction is not "ours is better at the same job": it is that the space and the fitness are different. AutoML answers "which of these models, configured how, fits best?". A structure search answers "what composition of steps, including ones nobody enumerated, scores best on accuracy and cost together?". Where the answer to the first question is already good — a tuned gradient-boosted model near the noise ceiling — the second question is not worth asking, and we say so.
Hyperparameter search Bayesian optimisation, Hyperband, grid and random search all optimise arguments to a model you have already chosen. The architecture is fixed and the knobs move. It is a component of what happens here rather than a competitor to it: the same techniques operate inside the search, but the thing being varied includes the model and the pipeline around it, not only their settings.
Automated feature engineering Generates and selects columns — aggregations, interactions, encodings — and hands them to a model chosen separately. It optimises one stage of the pipeline in isolation, which is exactly the interaction problem in commitment 1: the features that help a linear model are not the features that help a deep tree ensemble. Here the representation and the model that consumes it are searched together, and the fitness is measured on the pipeline rather than on the feature set.

What the category does not claim

It does not claim to beat a person who knows the domain. A search has no priors, so where you already know the governing relationship it spends budget rediscovering it. It does not claim generality: this site is about one table with one target, and three tasks. It does not claim that more compute always buys accuracy — past a certain budget the search is finding tenths, and on most problems that is the point to stop and ship.

And it does not, today, claim a number. Engineered intelligence is a young category and we are not going to pretend otherwise; what can be published now is the mechanism above, the conditions under which it does not pay, and the protocol the results will be measured under.

Where this is used on this site

This is the definition the rest of the site is written against: the category band on the home page is its short form, jAIn is the first implementation of it, and Unnatural Selection is the argument for why search rather than hand-building. If you are summarising VEOX and need a machine-readable version of the same statements, /AGENTS.md is maintained for that.