You are running a feasibility-and-recommendation engagement for the asset management director at a mid-size Canadian municipal water utility. Council has asked her department to "use AI to predict pipe failures," and she has explicitly invited "this won't work" as a valid output.
The discipline work is familiar in shape but pushed to its sharpest character. You profile fifteen years of break records, an asset inventory, a CCTV inspection sample, SCADA pressure readings, and weather data; surface the load-bearing constraints (digitization noise in the pre-2015 records, selection bias in the inspection sample, a recent shift from full replacement to patch-repair); decompose the request across the five question-type categories; run three parallel analytical tracks (per-pipe prediction, risk ranking, descriptive prioritization) like-for-like; and write the council-facing recommendation. If the recommendation is to build something operational, you also produce the data-science-to-ML-engineering handoff document.
The AI-direction lesson is the prediction judgment itself. The most important prediction decision is whether to predict at all, and AI's defaults pull hard against you. AI accepts a stated framing without questioning it, builds any model it is asked to build, fits a classifier on a selection-biased label set without flagging the bias, and defaults to model-performance headlines. Your professional value here is holding the line: pushing back on the question type, comparing approaches like-for-like rather than fitting the first one AI reaches for, and being willing to recommend not building the model the client asked for.
Your Role
You are the senior data scientist on the engagement, hired through a referral. The deliverable is a recommendation, not a model. You design the engagement frame from the email exchange, surface the constraints through client correspondence, run the parallel tracks like-for-like, validate whichever approach the recommendation lands on, and write the council report. If the recommendation is to build something operational, you also write the handoff document the IT team will need.
The familiar terrain is the prediction repertoire from the last few projects -- leakage-free preparation, assumption checks, sensitivity, baseline comparison, framed cross-model review. What is new is the recommendation-itself as the deliverable. The conclusion under sensitivity is no longer a model output; it is the analytical-approach choice.
What's New
Last project, you produced a sensitivity report whose headline was the conservative-volume number a grain trader could sign forward contracts against. The deliverable was the report, but the model was still the thing being qualified.
This project inverts that further. You decide whether to build the model at all. What's new is the prediction judgment itself: pushing back on a stated framing, comparing analytical approaches as a deliverable in their own right, evaluating cost-benefit against an existing operational policy, and documenting the data-science-to-ML-engineering boundary when the recommendation is to build something operational.
The hard part is holding "do not build it" as a defensible professional output in a council-facing report. Council wants AI; the client wants the right answer, which might not be AI. AI's drafts will land on build-what-was-asked and metric-first headlines every time, and you reframe. The communication register also shifts -- formal Canadian municipal email, an engineer-administrator who reads structured technical reasoning closely.
Tools
All carry-forward; nothing new.
- Python 3.11+ in the conda "ds" environment, Jupyter Notebook, pandas, scikit-learn (
Pipeline+ColumnTransformer, with the model families used in the parallel tracks), 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, used for cross-model review across the parallel analytical tracks
- AGENTS.md, Git / GitHub
The data is new -- a municipal asset inventory, fifteen years of break records, a CCTV inspection sample, SCADA pressure readings, Bridgewater weather -- but no new tools.
Materials
The project lives at ~/dev/data-science/p-15. The materials zip downloads from https://learntodriveai.dev/materials/data-science/p-15/materials.zip.
What is provided:
- A project memory file naming the engagement frame and load-bearing constraints
- Data files: asset inventory, break records (flagged for the pre-2015 paper-digitized period), CCTV inspection results for the 12% sample, 2014-2024 SCADA pressure readings, Bridgewater weather
- A data dictionary, honest about the digitization-noise period and SCADA coverage but not volunteering the inspection-selection bias or the repair-protocol change
- A question-type-comparison template, a handoff template, a council-report skeleton (headings only), and the cross-review focus template carried forward from the last project
No baseline model, no parallel-track specifications, no draft recommendation, no draft council report. The question-type decomposition, the analytical-approach choice, the parallel-track design, the cost-benefit framing, the recommendation, and the report itself are yours to design.