Chapter 1.1 — Systems thinking for ML

🎯 Objective

Apply the systems thinking from Ch. 0.1 to the specific ML lifecycle. In ML, the system is wider than the training pipeline: it includes upstream (data), downstream (consumers), and the team that operates the model after deployment. Most ML incidents in production are born at the edges, not in the algorithm.

🧠 Concept

ML systems have three critical couplings:

1. Data ↔ code: changes in schema or distribution break pipelines.
2. Model ↔ product: the product defines how the output is interpreted.
3. System ↔ organization: who owns the dataset, the model and the incident?

Failures are usually upstream (bad data arriving) or downstream (misuse of the output), rarely in the model itself. That is why a mature team invests as much in boundary contracts (data, output, ownership) as in the model architecture. Contracts are deterministic; the model is probabilistic (Ch. 0.6). Swapping their roles is the recurring mistake.

🏗️ How this shows up in production

• The upstream team renames a column; the feature pipeline breaks silently.
• The downstream team starts interpreting a score as a probability when it is a ranking.
• Compliance asks for sensitive features to be removed and the model must be retrained.

In all three cases, the algorithm did not change; what changed was the edge of the system. The fix is architectural — a data contract, an output contract, an explicit RACI — not a hyperparameter tweak.

📌 Checklist

• [ ] Is there a versioned data contract between upstream and the pipeline?
• [ ] Is there a versioned output contract between model and product?
• [ ] Is there a quality and freshness SLA?

---