The auto-* pipeline
How a model gets built, layered, reduced and served
Building one model by hand is a research project. Building fifty means the repetitive parts have to be automated, or every project pays the same setup cost again. Our framework is organised as four steps, each automated to the point where the modeller only supplies the judgement.
They are one pipeline, not four products, and they run in this order.
autoModeller — build
From a conversation to running equations. A structured description of the system (states, rates, controls, drivers, outputs) becomes a specification, and the specification generates the model code, the parameter tables and the first plots. Language models are useful here, for turning a domain expert’s description into a first draft specification. They are not trusted with the mathematics: the equations are checked, the units are checked, and the model has to reproduce known behaviour before anything else happens.
The point is not that a machine writes the model. It is that the boring two-thirds, the file structure, the bookkeeping, the plotting, the documentation, does not get typed again.
autoLayer — layer
A bare model is not yet useful. Real questions arrive in layers on top of it:
- a species or cultivar calibration,
- a farm, with its own equipment, prices and constraints,
- a scenario, such as a hot summer, a contract price, a stocking plan,
- an economics layer turning kilos and hours into margin,
- a stress or disease layer switched on or off.
Each of these is a set of overrides that stacks on the base model with a defined precedence, rather than a forked copy of the model. That is what keeps twelve customer variants from becoming twelve models nobody can maintain, and it is what makes a comparison between two farms an honest comparison.
autoFocus — reduce
Large sensitivity sweeps over parameters, scenarios and time windows, run as routine rather than as a special study. It answers: which parameters actually drive the outputs, which ones only appear to, which ones move together, and which combinations the available data can distinguish.
The result is a smaller model, or the same model with most of its parameters fixed with a stated reason, plus a shortlist of the quantities worth measuring. This is where identifiability gets confronted instead of assumed. The reasoning behind it is on the small data page.
autoServe — deliver
The model has to leave R and land where the decision is made. The same equations are translated into JavaScript and shipped as a simulator that runs in a browser, with the scenario controls and KPIs a user needs and nothing else. It runs on a phone, in a meeting, offline if need be.
Where the model itself is confidential, it stays behind an API and only the interface ships. That is a deployment choice, made per customer, not a rewrite. cropsimulator.com is a public example of the front end.
Beyond that sits the online part: feeding real measurements back in as they arrive, filtering them against the model, and correcting the state and the slower parameters as the season runs. That is where a simulator turns into a digital twin, and it is work we do with you and your data partners rather than alone.
Supporting machinery
Three smaller pieces sit alongside the four steps and matter more than they sound:
- Specification from a handful of questions. A new scenario or a new variant is usually pinned down by two to six well-chosen questions, with the rest interpolated from known cases. Faster than a parameter form with eighty fields, and much less likely to be filled in wrong.
- Model audit. Every model is checked automatically for the things that silently break results: parameters that are declared and never used, units that do not match, drivers that are not connected, outputs that no KPI refers to.
- Clinic. A standing diagnostic pass over a model’s behaviour, for the failure modes that only show up when you push the model somewhere it has not been: extreme drivers, long horizons, switched-off subsystems.
Why it is organised this way
Speed, and honesty about what is reused. When a new project starts, the questions are new but the machinery is not. Roughly fifty models have gone through this pipeline, across greenhouse crops, open field crops, fish, and human physiology. That is why a new model takes days rather than months, and it is also why a bug found in one project gets fixed for all of them.