Commodity price forecasting at 97% accuracy

The Challenge

Coconut is not a commodity you can hedge on an exchange. For Sri Lanka's largest food manufacturer it is a primary input, priced in a domestic market that moves on weather, smallholder harvest cycles, export demand, and occasional policy intervention. A ten percent swing in coconut price moves the cost of an entire product line.

Procurement was planning against a three-month view built from moving averages and supplier conversation. In practice that view held up about seventy percent of the time: good enough to notice a trend, not good enough to commit volume against. When the forecast missed, it missed in the expensive direction: contracts locked before a price fall, or spot buying into a rise nobody saw coming.

Two in-house attempts had already stalled. Both treated the problem as a generic time-series exercise: fit a model on historical prices, extrapolate, report an error metric on a random holdout. The models validated well and performed badly. Random holdouts leak future information into the training set, so the reported accuracy described a scenario that could never happen in production. Nobody in the business trusted the output, and nobody could explain a single number it produced.

Our Approach

We started from the failure mode rather than the model. The first thing we changed was validation: every model is scored with walk-forward, rolling-origin cross-validation. Train on everything up to a date, forecast forward, step the date, repeat. It is a harsher test and it produces a number you can actually plan against, because it mirrors the way the model will be used.

The second change was what went into the model. Price history alone cannot anticipate a harvest. We built the feature set around the physical drivers of supply: seasonal harvest cycles, lagged rainfall, and El Niño intensity via NOAA's Oceanic Niño Index, which leads Sri Lankan coconut yield by several months. The ONI series also gave us a principled way to build scenarios: perturb the index, and the model tells you what a strong El Niño does to your input cost.

The third change was explainability. We used an ensemble rather than a single estimator, and ran SHAP over every forecast so each number arrives with its drivers attached. A procurement head does not need the architecture. They need to know that this month's forecast moved because the ONI crossed a threshold and last quarter's rainfall was below normal, and then decide whether they believe it.

What We Built

FOCAST is a monthly forecasting service, not a model handover. Each cycle the client receives a three- and six-month price forecast with confidence bands, a sensitivity view showing which drivers moved the number, and a scenario tool for testing procurement decisions against alternative weather outcomes.

The delivery surface is deliberately plain: a Streamlit application for analysts who want to interrogate the scenarios, and a written monthly forecast note for the people who make the buying decision. There is no dashboard to learn and no login for an occasional user to forget. The forecast arrives, it is explained, and it is dated so its accuracy can be checked against what actually happened.

We also publish our own misses. Every monthly note carries the realised accuracy of the forecast issued three months earlier. A forecasting service that only reports its wins is not a forecasting service.

Results

• 97% accuracy at the three-month horizon, against a prior baseline near 70%
• 90.5% accuracy at the six-month horizon under rolling-origin cross-validation
• Deployed as an ongoing monthly subscription rather than a one-off project
• Adopted as a standing input to procurement decision-making
• Led to a formal vendor partnership with the client

Technologies

Python · scikit-learn · ensemble methods · NOAA ONI data · SHAP · Streamlit · walk-forward cross-validation

What This Means for Other Enterprises

Nothing in this work is specific to coconut. The method applies wherever a business buys a volatile input whose supply is driven by something physical and observable: dairy, packaging resin, spices, tea, industrial metals, freight capacity.

The transferable parts are the three corrections we made. Validate the way you will deploy, or your accuracy number is fiction. Feed the model the causal drivers of supply, not just the price series. Ship explanations alongside forecasts, because a number nobody can defend never reaches a decision.

That is what domain fluency buys. A generic data science team can fit the same estimator. Knowing that the ONI leads a South Asian harvest by two quarters is the part that moved accuracy from 70% to 97%.