The four-piece contract
Machine learning is not a magic box that turns data into answers. It is a contract among four pieces: a target you want to predict, the features you are allowed to use at prediction time, the data that pairs the two for training, and the metric that decides whether the model helped. Change the target and the required examples may change; change the metric and “good” may mean a different model.
Learning is not memorization
A learning algorithm changes parameters so a loss on training examples decreases. The goal is for those parameters to work on examples the model has never seen. That is not automatic. It depends on representative examples, a stable target definition, and features that truly exist at prediction time. A model that reproduces its training set and collapses on new cases has remembered answers rather than learned a useful pattern.
The model is one system component
In production, the model sits inside feature extraction, scoring, thresholding, decisions, logging, monitoring, and feedback. A model file without an input contract or rollback path is still a laboratory object. Its internal algorithm can be elegant and still be replaceable if it violates the larger system's interface.
A good score can still lie
A 0.97 ROC-AUC on a notebook split proves only that one calculation finished. Post-event refund information may have leaked into the features, or the served population may differ from the training rows. Draw the prediction timeline, verify that every feature existed before the decision, and compare the result with the simple rule or process already in use.
Write this before the first model
On one page, state whose outcome is predicted, what the outcome means, when prediction occurs, which information is legal at that moment, which historical cases become training data, and which metric must beat the baseline. If the team reads the page and imagines different decisions, the next task is to repair the problem contract—not to choose an estimator.