Farm-specific P removal factors

Working with an ag retailer to estimate farm-specific P removal factors for a customer.

The gist

• Ag retailers use nutrient removal factors to determine the amount of fertilizer to apply on their grower fields.

  • A removal factor is the amount of a nutrient needed to grow a crop (usually in lbs per bushel)

• An ag retailer customer was using the local university removal recommendations which hadn’t been updated since 1992, and wanted to know if there were more accurate removal factors for their region.

• We used 10 years of yield, application, and soil sample history from a 10,000 acre grower to estimate a phosphorus build rate and phosphorus removal factors for corn, wheat, and soybeans for the grower’s farm.

• Compared to the 1992 university recommendations, the estimated P build rate was 70% lower and the P removal factors were reduced by about 10%.

The story

We started working with an ag retailer interested in improving their data use. For the first project, their agronomy team was most interested in refining their phosphorus removal factors for corn, wheat, and soybeans.

The agronomy team was currently using P removal factors from the local university that had not been updated since 1992, and using a P build rate that was published by a university from another region. The agronomy team didn’t have much trust in these numbers, and were curious to estimate region-specific removal factors.

We decided to estimate these factors using one of their customer’s yield, application, and soil sample history.

The data

The yield, application, and soil sample history for the grower spanned from 2017 to 2024 across 10,000 acres.

We ingested the data into our system from different sources:

Data layer	Source
Yield	Grower’s Ops Center
Application	Retailer’s Fieldalytics, Slingshot, paper history, and Grower’s Ops Center
Soil Sample	Retailer’s Fieldalytics

Data cleaning

With any good data science project, the work was in the data preparation. We had to filter for missing harvests and applications and corrupted soil samples.

Cleaning the data is usually an arduous process, but because the data was in our system, and because our system makes interfacing with AI coding tools easy, we were able to speed up the data cleaning process by creating a problem-specific web app.

One example of a tool we created was a soil sample auditing tool. This tool was able to identify any soil samples with inconsistent and unexpected values, then provide the retailer’s agronomists the ability to increment through each soil sample to determine if it’s trustworthy and if the soil sample should be included in the final dataset.

The results

Once we had clean data, we were able to run the regressions to estimate the build rate and removal factors with the clean data.

Estimated variable	Estimated value [94% confidence interval]	University values
P build rate	5.4 lbs/ppm	18 lbs/ppm
Corn P removal	0.35 lbs/bu [0.31, 0.39]	0.4 lbs/bu
Soybeans P removal	0.84 lbs/bu [ 0.77, 0.91]	0.9 lbs/bu
Wheat P removal	0.56 lbs/bu [ 0.51, 0.61]	0.6 lbs/bu

Fit model by crop:

Estimated Corn Removal

Estimated Soybeans Removal

Estimated Wheat Removal

The future

Someday, a grower or agronomist will be able to pull up their AI tool and prompt, “Look at the last 10 years of my farm history and estimate the fertilizer recs for my farm.”

We’re not ready for that today. The above process still required data and modeling knowledge and took days of an experienced data scientist’s time. It’s not reasonable to expect a grower to manage that process on their own. It’s also not reasonable to assume an AI agent can run these steps on their own today. There’s likely too much field-specific context needed for the data cleaning and modeling.

But it would be a mistake to assume this doesn’t meaningfully change our ability to estimate removal factors today. Aggregating and cleaning data are the hardest tasks for this modeling. That just got easier. An ability that was previously reserved for only those in a university setting can now be cheap and easy enough for an agronomist with a little bit of data skill to run the process.

Which means we just made it easier for an agronomist to make more precise farm-, retailer-, region-specific recommendations.

Where do we fit in?

We build the infrastructure to bring these growers and agronomists closer to their data. As we develop this infrastructure, our goal is to reduce the steps needed by the user to answer their questions from the data. For this workflow, we see ourselves building the tools to make doing this data analysis easier. Instead of having to vibe-code a soil sample audit tool, we imagine providing soil sample cleaning tools that will audit the soil samples for you, or dataframe-building priors that help a user build the data in the structure they intend.

As we build this infrastructure, we’ll remove the data and modeling knowledge barriers, allowing more people to get more out of their data.