The ML Reasoning Loop
Problem → Target → Data → Representation → Split → Model → Training → Evaluation → Validation → Deployment → Inference → Monitoring → Drift → Retraining. Fourteen questions in order, and the order is the method.
The problem, the obvious approach, and why it breaks
Every lesson starts where the work starts: someone has a problem, and the first model that comes to mind looks fine offline.
Given any ML problem, incident or number, what is the sequence of questions that locates it, and why does skipping an early one invalidate every later answer?
An engineer is handed a request: "the ops team wants a model that predicts which delivery orders will be late." They want a procedure that takes them from that sentence to a system in production without discovering at the end that the first sentence was wrong.
Start from the model. Pull the orders table, engineer some features, train a gradient-boosted classifier, check the AUC, deploy it. The problem statement was clear enough.
The AUC is fine and the ops team does not use the output, because the prediction arrives at dispatch time and the decision they wanted to improve — whether to re-route — has to be made the night before. The model answers a question nobody can act on.
- The AUC is fine and the ops team does not use the output, because the prediction arrives at dispatch time and the decision they wanted to improve — whether to re-route — has to be made the night before. The model answers a question nobody can act on.
- The label "late" was taken from a column that is written when the delivery is confirmed; orders never confirmed are missing, and those are disproportionately the late ones. The model was trained on the orders that went well.
- The features included the carrier's scan count, which is higher for orders that have already been delayed and re-scanned. Perfect offline, useless at prediction time (Label Leakage).
- Each of these was discovered after deployment, and each was a question from an earlier stage that the model-first approach skipped.
What is being predicted, and from what data
This domain leads with these two. A target nobody defined precisely is a label nobody can trust, and a dataset nobody can describe is a model nobody can debug.
- The eventual target is whether an order will be delivered after its promised window. But the loop's first stop is not the target — it is the decision the prediction serves, and the target is derived from that.
- The loop itself is the target of this lesson: fourteen stages, each a question whose answer constrains the next.
- Order events with timestamps, carrier scans, promised windows and delivery confirmations exist in the operations warehouse. The delivery confirmation arrives hours to days after the promise, and some orders never get one.
- The ops team currently uses a rule — carrier plus distance — and a person who scans the list each morning.
How it actually works
Precisely enough to predict its behaviour — not a framework API.
- The loop is an ordered chain of constraints. The problem fixes the decision; the decision fixes what must be predicted and when; the target fixes what a label is; the data fixes what labels exist; the representation fixes what the model can see at the prediction moment; the split fixes what the evaluation may claim; the model, training and evaluation follow; validation checks the claim; deployment and inference realise it; monitoring watches the assumptions; drift is what monitoring finds; retraining is one response to it.
- Because each stage constrains the next, an error at stage *n* is present in every stage after it and invisible to every metric computed after it. The loop is ordered so that the cheap questions — what decision, what event, when — are asked before the expensive stages that depend on them.
- The loop is also a debugging procedure in reverse: given a production symptom, walk backwards until you find the stage whose assumption no longer holds. The failure classes from What Can Go Wrong each live at one stop.
Fourteen questions in order
Each row is a question, the artefact that answers it for the late-delivery example, and what goes wrong when it is skipped. The failures in the last column are all real ones from the naive approach above, and every one was invisible at the stages after it.
The stages are the same fourteen the What ML Engineering Is lesson lists as the domain's spine. Here they are questions rather than stages.
- 1Problem
What decision do we want to improve? Re-route orders at risk, the night before dispatch.
fails by Predicting something nobody can act on.
- 2Target
What event, defined how? Delivered after the promised window, observed by confirmation timestamp.
fails by A label that measures the wrong outcome.
- 3Data
What exists, and can the label be observed for everyone? Unconfirmed orders need a rule.
fails by Training on the orders that went well.
- 4Representation
Which features exist at the prediction moment? Only what is known the night before.
fails by Leaked features from after dispatch.
- 5Split
How will the model meet new data? Time-based, since orders are temporal.
fails by A random split that leaks the future.
- 6Model
Which family, given data size, latency and interpretability? A baseline first.
fails by "XGBoost" before the questions.
- 7Training
Which objective, reproducibly? Logged run, seed, data version.
fails by A number nobody can reproduce.
- 8Evaluation
Which metric maps to the re-route decision? Precision at the re-route budget.
fails by AUC for a decision with a fixed budget.
- 9Validation
Does the claim hold on data after the training window, per carrier?
fails by An aggregate that hides a broken slice.
- 10Deployment
Which artifact, with which feature code, behind which fallback?
fails by Version mismatch; no rollback.
- 11Inference
Nightly batch, since the decision is nightly.
fails by An online endpoint for a batch decision.
- 12Monitoring
Features, predictions, re-route actions, late-delivery outcomes.
fails by Only the business metric, weeks late.
- 13Drift
Which assumption moved — population, relationship or feature meaning?
fails by "Drift" as a single alarm.
- 14Retraining
Only once the stage is named and it is one retraining fixes.
fails by Retraining as the first response.
Why the order is the method
The reason to take the questions in order is not tidiness. It is that each answer is a constraint on the next, and a constraint discovered late is a constraint that has already been violated by everything built in the meantime. The prediction moment, fixed at the problem stage, rules out half the features before the representation stage begins; discovered at deployment, it rules out the model.
The device below is the moment that costs the most when discovered late. The scan-count feature is the kind of thing a model-first approach always finds, because it is the most predictive column in the table — for the wrong reason.
looks like A count of carrier scans per order in the warehouse table — a plausible proxy for handling complexity.
why it leaks The count in the table is the final count, accumulated through delivery; delayed orders are re-scanned at each hand-off, so the count is partly a record of the delay it is supposed to predict.
fix Fix the prediction moment at the problem stage and compute every feature as of that timestamp; the scan count as of the night before is a legitimate — and nearly useless — feature.
The loop run backwards
Six months after launch the re-route recommendations are being ignored again. Walking the loop backwards from the symptom: retraining and drift — has the population moved? The feature distributions are stable. Monitoring — are outcomes worse? Precision at the re-route budget is where it was. Inference and deployment — unchanged. So the model is fine. Keep walking: the problem stage — the ops team now re-routes at noon, not the night before, because a new carrier contract allows it.
The decision moved and the model did not. No drift monitor could have caught it, because no distribution changed. The problem stage is the one that only a person re-walking the loop can check, and the assumption device below is the one every model carries and almost none monitors.
The prediction is consumed by the same decision, at the same moment, with the same action available, as when the target was defined.
holds when The business process that acts on the prediction is unchanged, and its owner would tell the model's owner if it changed.
breaks when A process change moves the decision moment, changes the action, or removes the decision — a new carrier contract, a reorganised team, a product feature that makes the prediction moot.
respond Return to the problem stage. A changed decision moment changes which features are legal and which split is honest, which usually means a new target and a new model rather than a retrain.
How to build it
Most important first.
- Answer the stages in order, in writing, before any code, and treat an unanswerable early stage as a stop — if labels cannot be observed or the prediction cannot arrive in time, no later stage matters (Problem Formulation, When Not to Use ML).
- Carry the answers forward as the model's specification: the target definition, the prediction moment, the split strategy and the metric go into the experiment record with the weights (Experiment Tracking).
- At each stage, name the assumption it introduces and how it would be detected if it broke; this list becomes the monitoring plan at the monitoring stage (Model Monitoring).
- Run the loop again on every incident, backwards from the symptom, and only enter the retraining stage once a stage has been named (ML Incident Debugging).
What to measure
Which number actually maps to the decision — and which numbers look relevant and are not.
- At the problem stage: the business number the decision is meant to move — late deliveries avoided per re-route. This is fixed first and every later number is judged by whether it predicts this one.
- At the evaluation stage: the metric that maps to the decision's costs, at the threshold the decision will use, on a split that respects the prediction moment. The default metric and a random split answer a different question.
- Do not measure success at the training stage. A loss that went down says the optimiser worked, not that any earlier stage was right.
What must stay true after deployment
The field this whole domain exists for. A model is a set of assumptions with weights attached; these are the ones a monitor or a test should be checking.
- The decision the model serves is still the decision the business is making, at the same moment, with the same action available — a re-route the night before, not a customer notification at dispatch.
- The label rule still captures the outcome the decision cares about, and labels are still observed for the whole population rather than for the orders that went well.
- Every feature the model uses is still available at the prediction moment and not after it.
- The split strategy used at evaluation still reflects how the model meets new data in production.
- Offline: for each stage, a written answer and the artefact that proves it — the label SQL, the split code, the feature availability check at the prediction timestamp — reviewed before training starts.
- Online: at deployment, confirm the prediction is produced at the moment the decision needs it and that the action taken on it is logged, so the problem-stage number can be computed.
- Over time: re-walk the loop quarterly against the current business process; a changed decision or a changed action is a change to the problem stage that invalidates the model without any drift.
What can go wrong
- The loop is followed on paper and the answers are aspirational — "labels will be available" — and the aspiration is discovered false at the data stage, after the target has been committed to.
- The loop is followed once, at launch, and the world moves; the monitoring stage was designed for the assumptions of launch day and does not watch the ones that actually broke.
- The debugging walk backwards stops at the first stage that *could* explain the symptom rather than the one that does, because the earlier stages are more expensive to revisit.
- Answering fourteen questions before training is slower to a first result than training first, and on problems where the first sentence was right, the discipline delays a model that would have worked.
- Written answers become documentation that must be maintained; stale answers are worse than none because they are trusted.
- The debugging walk backwards is thorough and slow; on an incident where the cause really was staleness, retraining first would have restored service sooner.
- "The loop is the pipeline." The pipeline is the system's stages; the loop is the order of questions an engineer asks, and it starts two stops before the pipeline does — at the problem and the decision.
- "We can start at the model stage because the problem is obvious." Every example in this lesson looked obvious. The prediction moment, the label observability and the leaked feature were all invisible from the model stage.
- "Retraining is the last stage, so it is what you do last." It is the last stage of the loop and one of the least likely responses to an incident; the loop's order exists to make sure it is reached only after the others have been excluded.
Where this applies
ML advice is stated as universal far more often than it is. These labels say what each claim is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALThe order of questions holds for any predictive system; for unsupervised or self-supervised work the target stage becomes "what structure, and what will be done with it", and the rest is unchanged.
- SIMPLIFIEDReal projects iterate: the data stage often sends you back to the target stage, and validation back to the representation. The loop is presented as a line because the dependency direction is what matters, not the single pass.
Where the depth lives
This domain teaches the model and hands the rest off by name.