In agriculture, missing data is part of the job. Farm data comes from different sources, under changing field conditions, and at different points in the growing cycle, so a complete and perfectly synchronized dataset is rare.
AgTech models still have to work with whatever information is available. Some gaps barely affect the result, while others remove an important part of the signal. Knowing the difference is what makes the model useful outside a clean development dataset.
Agricultural data is collected through day-to-day farm operations, with each source following its own schedule, tools, and collection practices. That often leaves uneven coverage across fields, seasons, and data types, even when plenty of data has been collected overall.
Satellite imagery can cover large areas efficiently, but it rarely gives a complete view of what is happening in a field over time. Clouds can block optical images altogether, and the next usable pass may come days later. If crop stress, weed growth, or another short-lived change happens in between, there may be no clear image of it at all.
Drones make timing more flexible, but flights still depend on weather, access, and equipment. Resolution, image quality, and capture conditions can also vary from one survey to the next.
Field data can be messy in less obvious ways. A sensor may miss a few readings, switch to a different reporting interval, or start producing slightly different values after recalibration or replacement. Measurements can also vary between devices, even when they track the same variable.
Farm records add another source of variation. Planting, irrigation, treatments, and other field activities may be logged manually, kept in different formats, or recorded only when something changes. Combined with weather, soil, and sensor data, those records often follow different timelines and levels of detail.
The hardest data to collect is often the data that confirms what actually happened in the field. Yield is only known after harvest, while crop-quality measures may depend on lab tests that are too expensive to run at scale. Weed, disease, and crop-condition labels can be just as difficult, since they often require someone with agricultural expertise to review and annotate the data.
A model may see thousands of images or sensor readings but have only a much smaller set of verified outcomes to learn from. Those labels may also come mostly from a handful of farms, regions, or growing seasons.
Farm data rarely arrives in a form that can go straight into a model. Different sources have to be brought together, turned into useful inputs, and handled carefully when some of the expected information is missing.
One source rarely tells enough of the story on its own. An image may show that crop conditions have changed, but not necessarily why. Weather, soil, crop variety, and management history can add the context needed to interpret what the model sees.
Different sources contribute different pieces of that picture:
These sources also need to refer to the same field and the relevant stage of the growing cycle.
Once the data is in one place, it still rarely fits neatly into a model. A satellite image, a week of weather readings, and a soil sample all describe the same field in very different ways. The next step is to turn those raw inputs into signals the model can actually compare and learn from.
That can mean:
Not every project needs the same amount of manual feature engineering. With smaller datasets, carefully selected agricultural variables can make useful patterns easier to detect. With larger image or time-series datasets, the model can often learn more of those representations directly from the raw data.
Missing data doesn’t always need to be filled. If a sensor skips a few readings, estimating the gap may be reasonable. If an important observation is missing altogether, replacing it with a guessed value can do more harm than good.
A few approaches are useful in practice:
The choice depends on what was lost and how important it is to the prediction. Some gaps are minor. Others remove exactly the signal the model needs, and should stay visible rather than being quietly filled in.
A good average score can hide where a model is fragile. It may work well overall and still fail in a few repeatable situations. Those weak spots matter once the model starts being used beyond the conditions where it performed best.
A model needs to be tested on data it did not learn from. The problem is that a simple random split can make this test easier than it looks. Images from the same field, measurements from the same season, or observations collected only a few days apart can end up in both the training and test sets.
For AgTech, it often makes more sense to leave out a whole farm, season, region, crop variety, or time period during training and use it only for testing. That creates a tougher test, but it is also much closer to what the model will face once it is used on new data.
Testing only on complete inputs can hide how dependent a model is on particular data sources. Evaluation should also cover cases where part of the expected data is unavailable, delayed, sparse, or lower quality than usual.
These tests show how quickly performance drops as input quality gets worse. They can also expose hidden dependencies, such as a model that handles several missing inputs well but fails when one particular source disappears. That helps define which gaps the system can tolerate in production.
Not every prediction deserves the same level of trust.
A weaker result can be flagged, sent for human review, or held until another measurement is available. Confidence thresholds can define when each response applies, while drift monitoring can show when uncertain predictions start becoming more common after deployment.
If a low-confidence prediction is handled exactly like a strong one, the confidence score is not doing much useful work.
SciForce worked with a Swiss AgTech startup building tools for yield prediction, weed detection, and sugar-content estimation. The company already had useful agricultural data, but coverage varied from one task to another.
Cloud cover could block optical satellite images for weeks. Some field datasets were small and limited to one region, while sugar-content data was available only for a subset of crops because it depended on lab testing. The platform also had access to weather, soil, crop-variety, and other farm data that could help fill in part of the missing context.
Long gaps in satellite coverage made it harder to follow crop development and predict yield across the season. Weed detection had to work with a limited amount of image data, while sugar-content prediction had relatively little direct ground truth.
Vegetation indices could capture changes in crop condition, but they were not enough on their own. Similar-looking fields could still produce different results because of soil, weather, crop variety, or management practices.
Different tasks used different combinations of data. SAR imagery helped cover periods when optical images were unavailable, while weather, soil, crop variety, and vegetation indices added context around what could be seen from satellite data.
The modeling approach also changed with the task. Structured agricultural data was handled with traditional ML methods, while image and time-series problems used computer-vision and sequence models. Available field and laboratory measurements were then used to compare predictions with actual outcomes.
Using several data sources together made the available information more useful across the platform. In practice, this led to:
Different tasks still needed different combinations of data and models. There was no single method for filling every gap, but the platform could make better use of the signals that were available.
Real farm conditions will keep putting pressure on the data pipeline. Satellite coverage drops, sensors miss readings, and some measurements arrive late or only for part of the season. An AgTech model has to keep working through that mess without turning weak evidence into confident output.
Before scaling, test the product on the kind of data it will actually receive in the field. If performance holds up, failures are predictable, and uncertain cases are handled clearly, the model is in a much stronger position for production.
