learntodriveai.dev/Data Science/Sensitivity as the Deliverable: Robust-vs-Fragile Reporting
Data Science·Project 14·7 units

Sensitivity as the Deliverable: Robust-vs-Fragile Reporting.

**Track:** Data Science

§ Brief

You are producing a yield-prediction sensitivity report for an independent grain trader in Geelong, Victoria. He sells wheat forward six months before harvest and needs a number he can sign a contract against, plus an honest account of which assumptions could flip it.

The discipline work is familiar: a leakage-free baseline yield prediction across three buying regions (year-aware regression, not a forecast), then a sensitivity sweep across substantive specifications -- training window, weather-variable inclusion, drought-year handling, pre-2015 statistical-area-boundary handling, model family, regional correlation structure -- with cross-model review by a second AI on the methodology decisions. The model-family comparison is itself a sensitivity test, not a "best model" search.

The AI-direction lesson: when the client's downside is asymmetric, the sensitivity report IS the deliverable. The headline is the conservative end of the spread -- the volume he can commit to without losing sleep -- not the central prediction. AI's defaults pull the other way. It runs sensitivity on random seeds when asked, picks a "best" specification and buries the spread, fits a forecasting frame onto a regression because the data is temporal, paraphrases prediction outputs into causal language, and returns generic validation when handed a generic "review this" prompt. The work is to specify which assumptions matter, frame each cross-review with explicit focus, and write the robust-vs-fragile narrative that maps the spread onto the contract calls the client has to make.

Your Role

You are the analyst on a sensitivity-anchored yield prediction for forward-contract sizing across three buying regions, with the client's bank as a secondary technical audience. You design the specification axes that move the answer, run them with the methodological guardrails held constant across every variant, frame the cross-model reviews with focus areas a generic prompt would miss, and write a one-page report whose executive summary leads with the conservative volume the client can sign against. You hold the question-type boundary against AI's forecasting drift, catch causal-language slips in the interpretation, and report divergence between specifications honestly when they disagree.

The familiar terrain is the sensitivity work itself. What is new is the deliverable -- the spread is no longer a column on a prediction output, it is the document.

What's New

Last project, you architected AI infrastructure at scale -- phase-scoped MCP connectivity, three orchestration modes for three specification runs, cross-agent composition discipline, a portability test, a handoff package for an incoming analyst. The AI columns advanced; the discipline held.

This project inverts that. The infrastructure carries forward as your working capability and none of it gets re-architected. What advances is the prediction work: sensitivity analysis as the answer to "how confident should we be?", the correlation-causation boundary inside prediction interpretation, cross-model review framed with explicit focus areas, robust-vs-fragile documentation as the deliverable's spine, and model-family comparison as a substantive sensitivity test.

The hard part is the communication challenge under asymmetric downside. The conservative number is the headline; the central prediction is supporting evidence. The bank reads the report after the client does -- the assumptions you name as fragile are exactly the ones a sceptical lender will ask about. AI's drafts will land you on metric-first headlines and best-specification interpretations every time, and you reframe.

Tools

All carry-forward; nothing new.

  • Python 3.11+ in the conda "ds" environment, Jupyter Notebook, pandas, scikit-learn (Pipeline + ColumnTransformer, plus Ridge for the regularised model-family comparison), statsmodels, matplotlib / seaborn
  • MLflow -- a new experiment on the existing local file store
  • DuckDB, DuckDB MCP server, Jupyter MCP server, MLflow MCP server -- phase-scoped
  • Claude Code with the assumption-checking skill and pre-evaluation hook active (you do not modify these)
  • Codex CLI as the second AI tool, now used for cross-model review framed with explicit focus areas
  • AGENTS.md, Git / GitHub

The data is new -- Australian Bureau of Statistics yield by SA2, Bureau of Meteorology weather station data, satellite NDVI composites, soil moisture index -- but no new tools.

Materials

The project lives at ~/dev/data-science/p-14. The materials zip downloads from https://learntodriveai.dev/materials/data-science/p-14/materials.zip.

What is provided:

  • A project memory file naming the load-bearing constraints (regression-not-forecasting, conservative-end-of-the-spread headline, bank as secondary audience)
  • Data files: yield by SA2 region for Victoria and South Australia 2014-2024, BOM weather station data, NDVI monthly composites, soil moisture index
  • A data dictionary, honest about the pre-2015 boundary change and the drought-assistance-driven practice shifts in 2018-2020
  • A sensitivity-report skeleton -- section headings and prompts, no body text
  • A cross-review focus template

No baseline model, no specification list, no analytical plan, no draft report. The specification axes, the focus framing for each cross-review, the conservative-volume threshold, and the report itself are yours to design.