What Utilities Taught Me About Machine Learning
Most of the useful predictive systems I have worked on were not built to maximize engagement, recommend media, or classify internet-scale content. They were built to help people allocate scarce resources in physical infrastructure systems.
That difference matters.
In Flint, predictions about lead service line replacement helped decide which blocks should be inspected and replaced first. In sewer systems, computer vision could prioritize the human review of pipe inspection video. In natural gas operations, forecasting and permit analysis could help allocate crews before seasonal odor calls or risky excavation work overwhelmed response capacity.
These are all resource allocation problems. If time, money, crews, and equipment were unlimited, the model would be unnecessary. We would inspect every pipe, replace every suspect service line, review every video frame, and respond instantly to every call. The model becomes useful precisely because the real system has constraints.
That makes the culture of ordinary machine learning feel incomplete. A boosted tree or neural network may produce a strong predictor when the data is good and the relevant relationships are not obvious. But infrastructure problems usually ask for more than a score. They ask for a defensible account of why the score should influence a consequential human decision.
The missing ingredient is often domain knowledge. Local plumbers may know that houses of a particular era are more likely to contain lead. Sewer engineers may know which pipe materials fail in which soil conditions. Gas operators may know how construction activity changes the risk profile around buried assets. These facts are not just extra features. They are partial knowledge of the data generating process.
A purely outcome-oriented model can notice a pattern without understanding the process that produced it. It might discover that a neighborhood, vintage, or contractor history correlates with lead service lines. But it cannot tell us whether the relationship reflects plumbing code, construction economics, missing records, inspection bias, or a story known only to people who worked in the system.
This is why consequential predictions require more than accuracy. The people affected by a model need a system that is fair enough to defend, transparent enough to interrogate, and uncertain enough to admit what it does not know.
My current hypothesis is that many infrastructure prediction problems should move closer to interpretable statistical modeling and probabilistic programming. These tools encourage us to separate what we know from what we are trying to infer. They let us encode substantive assumptions, inspect uncertainty, and collaborate with domain experts without pretending the model is an oracle.
This does not mean abandoning machine learning. It means treating machine learning as one piece of a larger modeling practice. Flexible prediction is valuable. So are causal structure, measurement error, missing data, prior knowledge, and expert review.
The garden version of this essay is intentionally decomposed. The long argument lives here, while reusable pieces live as smaller notes:
- Resource Allocation Problems
- Domain Knowledge in Modeling
- Consequential Predictions
- Machine Learning Culture
- Interpretable Statistical Models
- Probabilistic Programming
Those fragments can grow independently, connect to future posts, and preserve the parts of the original unpublished drafts that are still useful.