Why a general AI weather forecast diverges from the field
A general model computes the atmosphere on a computational grid, where a single cell covers several farms at once.
The value for a specific field is obtained by recalculating from the cell center — and anything smaller than its size simply does not enter the calculation: a slope, a shelterbelt, a hollow, the difference in soil warming across different parts of the plot.
Therefore, weather forecast accuracy at the district level and at the field level are two different quantities, and the discrepancy between them reaches several degrees in temperature and a multiple difference in precipitation.
The field microclimate is determined by three things: terrain, soil, and the wind corridor of the plot.
A southern slope warms earlier and releases moisture faster, heavy soil holds it longer, and cold air stagnates in a lowland — frost arrives there two to three hours earlier than the general forecast.
This is also where model error comes from: they are statistically correct, but not for the point where you operate.
Then the error scales into operations. Spraying started when the wind is above the working threshold or during temperature inversion hours causes drift of the working solution and uneven coverage.
Irrigation based on an averaged forecast means either overwatering or crop stress during a critical phase. The treatment window is often measured in hours, and missing it means a repeat pass over the field.
A local forecast is built differently: the model is tied to data from stations within the plot, to terrain elevations, soil type, and prevailing wind direction. Below, we break down how this is addressed — from data collection to the decision to start treatment.
What a plot-level microclimate forecast provides
The average temperature for the district says almost nothing about a specific field: a lowland near a shelterbelt cools noticeably more than a slope a couple hundred meters away.
The microclimate forecast is calculated not from a single point but on a plot grid — the model combines satellite imagery from Sentinel-2, weather station data, and field sensors and recalculates conditions for each cell separately.
Zonal accuracy changes treatment planning.
Instead of going over the entire field "just in case," the agronomist sees which areas are actually in the risk zone and which remain outside it: unnecessary passes are eliminated, product consumption drops, and soil load decreases.
The second effect is predictable work windows.
The forecast maintains a horizon of several days and updates as it goes, so equipment dispatch is planned in advance rather than reacting to "wind, spraying is canceled." Shifting treatment by a day or two during a critical crop development phase directly translates into reduced losses.
The third effect is a removed class of failures. A sudden frost or overheating stops being a surprise: the system warns about them several hours in advance, when there is still time to turn on irrigation, ventilation, or protective measures. These are precisely the events that usually account for the bulk of crop losses.
We configure warning thresholds for the crop and development phase: what is critical for flowering passes without a reaction during vegetation.
We check model quality on the plot's historical seasons — it must reproduce already known frosts and heat waves before decisions are made based on it.
Methods for calculating field microclimate: comparison of approaches
Field microclimate is calculated in several ways, and the choice among them is determined not by "the best model" but by available data and the required spatial step.
Let us examine the options by applicability and limitations: comparing them is only correct with respect to a specific farm.
Ready-made external services provide a forecast on a coarse grid — within a single square they do not distinguish a slope, a lowland with cold air, and a field edge near a shelterbelt.
An in-house model based on farm measurements is more accurate for your conditions but requires a sensor network and regular calibration. Satellite data, for example Sentinel-2, cover the entire area without equipment, but depend on cloud cover and update with a delay.
| Approach | When it fits | Limitations |
|---|---|---|
| Ready-made external service | A general regional background is needed, no own observations | Grid step in kilometers, does not see plot microclimate |
| In-house model based on farm data | There are sensors and a history of observations over several seasons | Calibration and maintenance of the sensor network |
| Satellite data with recalculation | Coverage of the entire area without equipment is needed | Cloud cover, infrequent imaging periodicity |
| Hybrid calculation | Detail by plot is needed with a limited number of sensors | More complex setup: reconciliation of heterogeneous sources |
In practice, hybrid calculation more often wins: satellite data set the temperature and moisture field over the area, sensors tie it to specific points, and the model recalculates values at a step of tens of meters.
We select the scheme for your plots and equipment — this determines what volume of field measurements is actually needed.
Implementation stages: from data audit to model handover
The sequence of implementation stages is arranged so that an error in the model is detected before decisions on irrigation, treatment, or harvesting begin to be made based on the forecast.
Each stage ends with a verifiable artifact — a report, a dataset, or a recorded metric — so the project does not get stuck in the "model is almost ready" state.
-
Data audit. We analyze observation archives: ground stations, soil moisture and temperature sensors, satellite imagery, terrain layers. We look at series length and homogeneity, the share of gaps, sensor displacements during relocation, and areas without coverage.
-
Metric definition. We agree on what we consider an accurate forecast: permissible error in temperature and moisture, the share of hits within tolerance, separate requirements for frosts, dry winds, and other edge cases.
-
Data preparation. We bring heterogeneous sources to a single grid with a step of up to 100 m, restore gaps, form features based on terrain, soil, and seasonal dynamics, and split the history into training and holdout parts.
-
Model building and tuning. Machine learning proceeds from several families of models: we compare them on holdout periods and select by robustness, not by the best score on training.
-
Accuracy validation. First, a retrospective on past seasons, then field validation: the forecast is compared with control sensors at points the model has not seen. A discrepancy above tolerance sends us back to the previous stage.
-
Integration into the operational loop. We configure the recalculation schedule, monitoring of forecast-to-actual discrepancies, and the retraining procedure when the season or variety changes.
-
Model handover. We provide documentation, access, a description of metrics and the update procedure, and train your team — ongoing support can then be carried out in-house.
What we hand over: models, data schemas, procedures
Handover is not a folder with files but a working system and documentation that your team can use to operate it without us. Therefore, we record not only the result but also the assumptions, the model's applicability boundaries, and the procedure to follow when accuracy drops.
- A configured AI weather forecast model with a fixed configuration: rerunning on the same data produces the same result.
- Data schema: linking fields, contours, and sensors to coordinates — the forecast is calculated per cell of up to 100 m, not for the district as a whole.
- Description of input data: sources, arrival frequency, required fields, and replacement options if the channel is unavailable.
- Update procedure: recalculation schedule, procedure for connecting new sensors, and retraining rules when discrepancies accumulate.
- Accuracy control: methodology for comparing forecast with actual measurements and thresholds after which the model is sent for rebuilding.
- Access policies: roles of agronomist, analyst, and administrator, rights to export and change settings, and request logging.
- Instructions for agronomists: how to read the forecast, what a decrease in confidence means, and how to leave feedback in the quality control loop.
- Documentation set: architecture diagram, data schema, settings registry, and recovery procedure after a failure.
Acceptance follows a checklist: a run on your data, analysis of discrepancies, transfer of access, and training of responsible staff. After that, you decide whether to carry out support in-house or leave it to us.
Case study: how a local model changed treatment planning
The Stepnoye farm manages about 14,000 ha across three agroclimatic zones — floodplain, slope, and plateau.
Before implementation, treatment planning relied on a single forecast from the nearest weather station: for distant blocks that is up to 30 km, meaning already different weather.
Frosts on the slope were not caught, field trips were canceled after the fact, and the spread of dates between zones reached six days.
What was changed
We collected an archive of observations over six seasons — stations, soil moisture and near-surface temperature sensors — and trained a local AI forecast model that recalculates the general background onto a 100 m grid and updates several times per day.
The forecast is tied to field contours: the agronomist sees a specific block, not the entire district, and receives a warning a day before the event.
Metrics before and after
- Share of correct frost warnings one day ahead: 60% → 90%.
- False alarms: one in three → one in ten.
- Canceled field trips per season: 11 → 3 — equipment and people do not idle at the turn.
- Spread of treatment dates between zones: 6 days → 1-2 days; plots stopped "waiting" for each other.
Separately, we closed a class of failures that had not been tracked before — a missed treatment window. In the first season of the model's operation, there were seven such cases; in the second, none.
Why does a general regional model err on a specific field?
A regional model calculates weather by grid cell, not by your field. Inside such a cell are dozens of farms, slopes, lowlands, shelterbelts, and a water body, and the model outputs the average across them. That average is correct for the district and almost always off for a specific contour.
Terrain and soil type add variance within a single cell.
A sandy slope warms and dries faster than a lowland with loam, and a wind corridor along a shelterbelt accelerates the flow — a general regional calculation does not distinguish this because a single physics is applied to the entire area.
A nearby water body acts as a buffer and smooths the diurnal temperature course over a strip of hundreds of meters.
Then the calculation scale comes into play. As long as the model step is larger than the field itself, any data provider will give the same averaged answer — changing the source will not add information that is not in the calculation.
A local correction is trained on measurements from a specific plot and ties the forecast to a point rather than a district, removing systematic bias exactly where the decision on irrigation or treatment is made.
In practice, this changes the picture more than changing the provider does: the same field, the same horizon, but instead of a single average number — a value for the plot contour and an estimate of the spread around it.
Therefore, calculation scale and local correction are included in the loop by default, rather than coming as an improvement on top of a ready-made regional forecast.
Technical concerns: data, accuracy, integrations
Technical questions come at the evaluation stage, and they are almost always the same: what to do with already installed sensors, how accurate the calculation is without own measurements, and how the result will get into the systems the farm uses every day. Below are direct answers, without promises of "full autonomy" and "zero error."
Sensors are already installed in the field — will they have to be replaced?
No. We read the archives of existing stations, bring them to a single time step, and use them as reference points for calibrating the model on a specific contour.
Where there are no sensors, the calculation relies on satellite imagery, terrain, soil type, and moisture storage — a grid on the order of 100 m is built even without local measurements.
Own measurements do not replace the model but refine it: after the first calibration, the discrepancy in temperature and moisture on the plot drops noticeably.
How accurate is the forecast without own measurements?
The model calculates microclimate on a grid of about 100 m, not at a single point per farm, so it distinguishes a lowland, a slope, and an open plateau — precisely where frosts and overheating occur.
On flat terrain and uniform soil, the calculation is stable from the first days; on complex plots, the first two to three weeks go into comparison with actual measurements.
If accuracy for a specific field is critical, we add control points — this is cheaper than maintaining a continuous network of stations.
How can the result be integrated into systems already used on the farm?
The result is exported in two ways: as layer files for agronomic platforms and via a software interface to which the accounting system or the agronomist's mobile application connects.
The update schedule is set for the task — from a daily forecast to notifications when there is a risk of frost on a specific contour. We start integration with one field or crop, test it on real decisions, and only then roll it out to the entire crop rotation.
Let's discuss the task: what is needed to start work
To come back with an estimate and work plan rather than general words, we need a minimum set of inputs.
An AI weather forecast with a step of up to 100 m is built on data from a specific farm, so in the first conversation we clarify how decisions are made based on the forecast and what materials you already have.
- Territory: field and contour boundaries, division into plots that require a separate forecast.
- Target indicators: which microclimate parameters and over what horizon we calculate — temperature, moisture, precipitation, wind, frost risk.
- Source data: weather station archive, satellite imagery, field sensor readings, telemetry history from past seasons.
- Agronomic context: crops and development phases, treatment procedure — these determine which model errors are critical.
- How the result is used: what action follows the forecast — irrigation, treatment, harvesting — and who reviews it.
- Output format: map, mobile application, table, or your operational loop.
- Trial period: launch on one contour or season with a fixed quality metric and comparison with actual measurements.
- Data requirements: who is the owner, where it is stored, what restrictions apply to transfer and access.
After that, work starts according to fixed stages: data preparation, model training, validation on historical seasons, and deployment into the operational loop.
Describe the task and available source data — we will come back with an estimate, a plan, and the applicability boundaries of the forecast.
