How to Evaluate a Machine Learning Definition Before Trusting It
Not every definition you read in a paper, blog post or textbook deserves equal trust. Here is a short checklist I use before I let a definition shape my thinking.
Why this matters more than it looks
Machine learning is unusually generous with vague definitions that sound rigorous. Terms like generalisation, overfitting, robustness or interpretability get used constantly, often with a confident one-sentence gloss that nobody questions. The trouble is that a definition which sounds precise can still be operationally empty: it tells you what the word means in principle but gives you no way to measure it, and no way to know when it has been violated.
I care about this because the definitions we accept quietly become the assumptions baked into our experiments. If I define generalisation as "performing well on unseen data" and leave it there, I have not actually told myself what counts as unseen, over what distribution, or measured by which metric. Those gaps are where leakage, cherry-picked splits and overstated claims creep in. A sloppy definition does not just mislead you in conversation; it can quietly corrupt an evaluation pipeline for months before anyone notices the gap between what was claimed and what was measured.
So before I let a definition into my mental toolkit, let alone into a report or a model card, I run it through a small set of questions. None of them are exotic. They are the kind of questions a careful reviewer asks, and the kind I wish I had asked myself earlier in my own work.
Is it operational, or just descriptive
The first test is whether the definition tells you what to measure, not just what to imagine. Take "a model generalises well if it performs similarly on training and test data." That sounds operational, but it hides a question: similarly according to what tolerance, and on what test set? If the test set was constructed by randomly shuffling rows from the same time period and the same users as the training set, then "similar performance" might just mean the leakage is doing its job, not that the model has learned anything transferable.
A better operational version specifies the split protocol explicitly: for example, training on data up to a fixed date and testing only on data collected afterwards, with no shared entities between the two sets. Suppose a model scores 91 percent accuracy on a random split and 74 percent on a strictly time-based split with disjoint users. Both numbers are true, but only one of them tells you anything about generalisation in the sense most people actually care about, which is performance on genuinely new, future cases. The definition that does not specify the split protocol cannot distinguish between these two very different stories.
This is why I treat "define your test conditions in the same sentence as your term" as a non-negotiable rule. A definition of robustness that does not say robust to what, measured how, is not yet a definition; it is a placeholder for one.
Does it survive a concrete counterexample
The second test is to try to break the definition with a specific, realistic scenario rather than an abstract one. Take "interpretability means a human can understand why the model made a decision." Apply this to a decision tree with four thousand leaves and a depth of thirty. Technically every split is a simple threshold rule, so by a shallow reading the tree is interpretable. In practice, no human is tracing four thousand branching paths to explain a single prediction, so the definition, as stated, lets something through that nobody would actually call interpretable in the way the word is meant to be used.
Running this kind of stress test quickly exposes whether a definition is doing real work or just restating the obvious case. A definition of fairness that only mentions equal overall accuracy across two groups will pass for a model that is 95 percent accurate on one group and 95 percent accurate on another purely by averaging out large errors on different subpopulations within each group. The counterexample does not need to be contrived or dramatic; it just needs to be plausible enough that you can imagine encountering it in an actual dataset.
I find it useful to write the counterexample down rather than just picturing it, because vague mental objections tend to evaporate, while a written scenario with rough numbers forces you to check whether the definition actually handles it or quietly assumes it away.
A short checklist, and the practical payoff
Putting this together, I ask four questions of any definition before I rely on it: does it specify a measurable procedure rather than a vague property; does it state the conditions under which it was validated, such as the data split or the population; does it survive a concrete counterexample rather than only the textbook case; and does it distinguish between two situations that intuitively feel different, such as leakage-inflated accuracy versus genuine out-of-distribution performance.
The payoff for doing this is not academic tidiness, it is avoiding wasted months. A definition of generalisation that silently permits temporal leakage will let a weak model look strong right up until it is deployed on genuinely future data, at which point the gap between reported and real performance becomes someone else's expensive problem. Catching the loose definition early, at the point where you first write it down or read it in a paper, is far cheaper than catching it after the model has shipped.
None of this requires new theory. It requires treating every definition in machine learning the way I would treat an unfamiliar function in someone else's codebase: read the signature, check the preconditions, and try at least one input designed to break it before trusting the output.
