Predictions for Valentina

Step 1: Generate Per-Farm Predictions

Use the best model from Unit 4 -- whichever performed better on the honest temporal test set, whether that's the PyTorch model or the scikit-learn baseline. Direct Claude to generate yield predictions for each of the twelve farms for the upcoming harvest.

Format the predictions as a table Valentina can read: farm name, predicted yield in kilograms, and a confidence indicator (high, medium, or low based on how consistent the farm's historical predictions are).

Step 2: Flag Underperforming Farms

Valentina specifically asked to know which farms are likely to underperform. Review the predictions and flag any farms where the predicted yield is below what she'd need for her contract commitments.

Pay attention to farm_05 and farm_09 -- the Gesha farms. Their yield profile changed after the variety switch. The model's predictions for those farms should reflect the lower volume. Note this explicitly: Valentina needs to know how the model handles the variety difference and whether those predictions are reliable given the limited post-switch data (only one or two harvests after the change).

Step 3: Send Valentina the Results

Send Valentina a summary of the predictions in her terms. Not model metrics -- contract decisions. "Based on the sensor data, here are the predicted yields per farm. Farms X, Y, and Z are likely to produce less than their historical average. The two Gesha farms have a different yield profile since the variety switch -- their predictions reflect lower volume."

Valentina reviews the predictions practically. She'll check whether the results match her intuition about the farms. She'll ask about the Gesha farms specifically -- whether those predictions are reliable given the variety change. If your predictions make sense to her, she can plan her contract negotiations around them.

Step 4: Handle the Scope Request

After seeing the yield predictions, Valentina asks: "Can we also predict quality scores, not just quantity? My roasters in Tokyo pay double for lots that score above 86. If I knew which farms would hit that, I could price the contracts differently."

This is a reasonable ask. Quality prediction would add real business value. But it's also a significant scope expansion -- from single-output regression (yield) to multi-output prediction (yield and quality), and the quality data has different patterns than yield.

Decide how to respond. Explain what would be needed to add quality prediction, whether the current data supports it, and whether it's in scope for this engagement. A good scope management response acknowledges the value ("that would help with contract pricing"), explains the constraint ("quality prediction needs different features and the Gesha farms only have one post-switch harvest for quality comparison"), and proposes a path forward ("let's get the yield predictions working first, then evaluate whether the quality data is sufficient for a follow-up").

Step 5: Document Key Decisions

Write a brief summary of the major technical decisions across the project:

• Temporal splitting: Why you used train-on-earlier, test-on-later instead of random splitting. What happens to the metrics when you use random splitting (they inflate because future information leaks into training).
• Feature construction: Which features you built and why. The domain hypotheses behind each one.
• Outlier handling: How you distinguished between variety effects and sensor anomalies. Why the Gesha farms were kept.
• Loss function and model selection: Why MSELoss for regression. Whether the PyTorch model outperformed the baseline and by how much.

This documentation is for Valentina's team. If someone else picks up the project next season, they should be able to understand the pipeline and rerun it with new data.

Step 6: Write the README and Close

Direct Claude to produce a project README covering: what was built, the data pipeline, the models, and how to rerun the prediction with new data. The README should be practical -- a practitioner reading it should be able to set up the environment, run the pipeline, and generate new predictions.

Commit everything. The repository should contain: the feature engineering pipeline, the trained model, MLflow experiment logs, feature documentation, the evaluation template, and the README.

Push to GitHub.