Case study · Machine learning, Instrumental Partners · 2025 to 2026
Machine learning for bid pricing on defense supply contracts
A US aircraft-lighting manufacturer bids on Defense Logistics Agency solicitations for spare parts, each identified by a National Stock Number (NSN). For every open solicitation it needs a price that wins without leaving money on the table. I built the model that suggests it.
- Context
- Instrumental Partners · client confidential
- Best model
- MedAPE 7.7% vs ~10% baseline
- Stack
- Python · XGBoost · MLflow · EC2
Start from the obvious baseline
The simplest rule is to bid the last winning price, and any model has to beat it. So the target is the change from the last observed price, in log terms. Features include lags, rolling statistics, price bands and market features about the other suppliers approved for the same part. Training is weighted by contract value, and the test set takes the most recent award for each NSN, which is the situation the client actually faces.
Nineteen models, one cascade
I compared OLS, SVM, naive Bayes, XGBoost, neural networks and quantile models. The winner is a cascade. XGBoost classifiers first decide whether the price will move by more than 1% (AUC 0.86), by more than 5% (AUC 0.86), and in which direction (AUC 0.89). Only when a real move is expected, for about 54% of rows, does a neural network estimate its size.
Results
- On the most recent award per NSN: median absolute percentage error of 7.7% against about 10% for the last-price rule, MAE of $2,480 against $3,400, and R² of 0.48 where the baseline is negative.
- 43% of predictions land within 5% of the real price, and 78% within 50%.
- On a separate holdout of 2,196 NSNs the gap is narrower: 19.1% against 20.0% for the last price. About three quarters of parts are stable enough that the last price is the right bid, and the model earns its keep on the volatile rest.
That second result changed how the tool is used. It now tells the bidder when to repeat the last price and when a part needs attention.
In production
Models are tracked and versioned in MLflow, with a production alias. The model scores active solicitations scraped from DIBBS and writes its suggestions next to the opportunity data in PostgreSQL on AWS EC2, where the sales team sees them in their dashboards. The data pipeline behind it is described in procurement intelligence.