A baseline answers "compared to what." A control answers "compared to nothing."
Two very different runs get called by the same word, and the confusion is expensive. A baseline is a rival system measured on the same data, and it sets the size of a claim. A control is a run built so that a specific wrong explanation of your result would have shown up in it, and it decides whether there is a claim at all. A report can carry four carefully tuned baselines and still be indefensible, because nothing in it would have looked different if the whole effect had been an artifact of the pipeline that produced it.
Here is the question, and it takes about ten seconds to ask. If the thing we are claiming were not true, which run in this study would have told us? Point at it. Name the number it produced and the number it would have produced under the other hypothesis. If nobody on the team can point at a run, the study does not support the sentence. Not because the sentence is false, and not because anyone did anything sloppy, but because the sentence was never at risk. A number that was never at risk carries no information about the world, however carefully it was computed.
This lands hardest on teams who are not cutting corners. The code is clean, the split was honest, the metric is the right metric, and the number is real. The exposure is that the same number would have appeared for six other reasons, and the first serious reader who asks "what would this have looked like if the model had learned nothing" gets silence from the document. In a program review, that silence is the finding. Choosing the comparison arms is a separate discipline, covered in choosing a baseline you can defend. This piece is about the other run.
The test that separates a control from a formality
Before the run happens, write down the outcome that would stop you from making the claim. Not a vague one. A number, an inequality, a threshold. "If the permuted-label runs land above 0.71 accuracy, we do not report the 0.74 as a finding." Then run it. Whatever comes back, the study has learned something, because both outcomes were live before the button was pressed.
Apply that test to the runs in a typical report and most of them fail it. A control that could not have stopped the sentence is not a control. It is decoration that happened to run. An ablation where a component is removed and the score drops a little, in the expected direction, by an amount nobody pre-committed to, describes the system rather than testing it. Worth including, but it will not answer the reader who thinks the whole effect is leakage.
Controls come in two directions, and they catch opposite failures. A negative control is a run where the honest answer is "nothing." Shuffle the labels, blank the input, ask the retrieval system for documents that do not exist. If the pipeline still produces a strong score, the score was never about the signal. A positive control is a run where the honest answer is "something," planted by you at a size you chose. Degrade the model on purpose, seed a known effect, hand the judge an answer you know is wrong. If the harness reports no difference, the harness cannot detect differences, and every "no significant difference" it has ever produced is unreadable. Most teams run neither. Teams that run one almost always run the first.
The federal record already runs on controls
None of this is a research-culture preference imported into procurement. Federal instruments that predate the current AI conversation by decades already require this structure, and a report organized around them speaks a language the customer's technical staff already reads.
| Instrument | What it requires | What it means for a technical report |
|---|---|---|
| ICH E10, Choice of Control Group and Related Issues in Clinical Trials (Step 4, 20 July 2000) | Control groups have "one major purpose: to allow discrimination of patient outcomes ... caused by the test treatment from outcomes caused by other factors, such as the natural progression of the disease, observer or patient expectations, or other treatment." Placebo, no-treatment, dose-response, active and external controls are each treated as a design decision that determines what the trial can conclude. | The control is not there to make the result look better. It is there to strip out the alternative explanations, and choosing it is part of the design rather than a step after the modeling. |
| ICH E10, assay sensitivity | For a finding of non-inferiority to count as evidence of efficacy, "the trial needs to have had the ability to distinguish effective from less effective or ineffective treatments." | The single most under-used idea in machine-learning reporting. A study that could not have detected a failure cannot report a success either. This is the argument for positive controls, stated by a regulator in 2000. |
| 42 CFR 493.1256, Standard: Control procedures (CLIA) | At least once each day patient specimens are tested, a laboratory must include, for each qualitative procedure, "a negative and positive control material." Molecular amplification procedures require two control materials, and where reaction inhibition is a significant source of false negatives, "a control material capable of detecting the inhibition." | Federal law requires a negative control every single day a clinical test is run, on the reasoning that an instrument silently drifts. A model evaluated once at delivery gets less scrutiny than a strep test. |
| 10 U.S.C. § 4171, Operational test and evaluation of defense acquisition programs | The Director of Operational Test and Evaluation approves the test plan in writing before operational testing begins, and afterward reports whether the test and evaluation performed "were adequate" and whether the results confirm the items tested are effective and suitable for combat. Employees of the contractor for the system may not take part in the operational test. | The plan is fixed before the result exists, and the party with the claim does not run the test that could refute it. Both are procedural, both are cheap, and both are usually missing from a vendor evaluation. |
| 10 U.S.C. § 4172, survivability and lethality testing | A covered system may not proceed beyond low-rate initial production until realistic survivability testing is complete, meaning testing for vulnerability in combat by firing munitions likely to be encountered in combat at the system configured for combat. | A system is tested against the condition that could break it, in the configuration that will be fielded. A demo on curated inputs is the opposite posture. |
| GAO-21-519SP, Artificial Intelligence: An Accountability Framework for Federal Agencies and Other Entities (June 30, 2021) | Organizes accountability around governance, data, performance and monitoring, with audit questions for each that entities, auditors and third-party assessors are expected to answer. | An auditor arrives with questions, not with your framing. What was tested, and what the test could have shown, is the artifact they ask for. |
Assay sensitivity deserves a second pass because it inverts the usual worry. Teams fear reporting a false positive. The quieter failure is a study with no power to detect anything, which then reports either an artifact or a null result that means nothing. Both come from one defect: nobody checked that the instrument could see. In a laboratory that check is a positive control material and it happens daily. In a machine-learning evaluation it is a two-hour run almost nobody schedules.
Five controls that can refute a machine-learning result
These are the runs worth budgeting for. Each targets a specific alternative explanation, each has a defined outcome that would stop a claim, and none needs a methods committee to approve.
| Control | The run | What a failure tells you |
|---|---|---|
| Permuted labels | Randomly shuffle the outcome labels and rerun the entire pipeline end to end, including feature selection and preprocessing. Repeat enough times to get a distribution. | If the permuted runs score near your reported number, the pipeline manufactures scores from structure unrelated to the outcome. This is the most informative negative control available, and it catches leakage no significance test will. |
| Corrupted or removed input | Blank the region that is supposed to carry the signal, drop the modality you say is doing the work, or turn the retrieval step off and answer from the model alone. | If performance barely moves, the claimed mechanism is not the mechanism, and the component you propose to build, buy or ship is not producing the number. |
| Negative control outcome | Predict or estimate an effect on an outcome that the mechanism could not plausibly influence, but that shares the same confounding pathways as the real outcome. | A strong association where none can exist is direct evidence of confounding or bias in the design. Lipsitch, Tchetgen Tchetgen and Cohen set this out in Epidemiology in 2010, and it transfers cleanly to any model trained on operational data nobody randomized. |
| Planted effect (positive control) | Inject a known degradation of known size into one arm, or seed a set of records whose correct answer you constructed, then run the harness blind to which is which. | If the harness cannot recover the effect you planted, it cannot detect the one you are looking for, and any null finding it produced is uninterpretable. This is assay sensitivity, measured rather than assumed. |
| Randomized instrument | Run the evaluation machinery against a deliberately meaningless subject: an untrained model, a model with randomized weights, two identical arms in an A/B split, a judge scoring an answer known to be wrong. | If the instrument reports a difference between two identical things, or produces confident output for a random model, the instrument is generating the signal. Adebayo and colleagues used this construction in 2018 and found that some widely used saliency methods are independent both of the model and of the data generating process. |
Why the permutation control is the cheapest insurance in the study
The reason to run it is a result that is now almost a decade old and still not fully absorbed into practice. Zhang, Bengio, Hardt, Recht and Vinyals showed that standard convolutional networks trained with stochastic gradient methods "easily fit a random labeling of the training data," and that the same holds when the true images are replaced by unstructured random noise. The capacity is there to memorize anything. It follows that the fact your model fit your data is not, on its own, evidence that there was anything in the data to fit.
The permutation control converts that from a worry into a measurement. Ojala and Garriga set out the construction in the Journal of Machine Learning Research in 2010: permuting the class labels tests whether the classifier has found real class structure, while permuting features within classes tests whether the classifier is exploiting dependency between features. Run the first one and you obtain the null distribution of your own pipeline, on your own data, at your own sample size, with your own preprocessing in place. Your reported score is then a position in that distribution rather than a floating number.
What makes it valuable is coverage. A p-value on a coefficient tests one modeling assumption. A permutation of the labels through the full pipeline tests everything at once: the imputation fit before the split, the feature selection that peeked at the whole dataset, the duplicate records straddling the boundary, the group structure a random split ignored, the hyperparameter search that ran forty times against the same evaluation set. Every one of those inflates the permuted runs too, which is the point. If your real score does not clear its own shuffled twin, no amount of modeling sophistication will rescue the claim.
The honest cost note: full permutation is expensive on large models, because a proper null needs many refits. Two compromises hold up under review. Run the permutation on a subsample and report that it is a subsample. Or freeze the expensive representation and permute only the supervised head, saying plainly that the control covers the classifier and not the representation. Both are defensible. Skipping it and saying nothing is not.
The positive control is the half that gets skipped
A negative control protects against claiming an effect that is not there. A positive control protects against the opposite failure, which is the one that quietly wrecks acceptance testing. A team runs a comparison, finds no significant difference, and concludes the systems are equivalent. That conclusion is only available if the test could have found a difference had one existed, and almost nobody checks.
Checking is a half-day. Take the arm you already measured, degrade it by a known amount, and rerun the harness. Drop a tenth of the retrieved passages. Corrupt one field in every twentieth record. Swap in a smaller model. Then confirm the harness reports the degradation, at roughly the size introduced, with an interval that excludes zero. If it does not, you have found a defect in the measurement system before it cost anyone a decision, and that finding is worth more than the comparison you were trying to run.
The same logic applies with force when the evaluator is itself a model. Zheng and colleagues, in the work behind MT-Bench and Chatbot Arena, reported that strong judges reached over eighty percent agreement with human preferences, the same level humans reach with each other, and in the same work identified position, verbosity and self-enhancement biases along with limited reasoning ability. Both halves matter: the judge is good enough to use and biased enough to need controls. The cheap ones are to score the same pair in both orders and measure how often the verdict flips, submit answers constructed to be wrong and confirm they are marked wrong, and keep a fixed anchor set so the judge's drift stays visible over time.
The order the runs have to happen in
The ordering carries the weight. Steps three and four before step five is what makes them controls. The same runs performed after the headline number exists are robustness checks, worth having but answering a weaker question, because the analyst now knows which answer keeps the finding alive. That is not a comment on anyone's integrity. It is why the Director of Operational Test and Evaluation approves a test plan in writing before testing starts rather than after.
What the control looks like in each kind of system
The abstraction is easy to nod at and hard to apply, so here is the concrete run for the systems that come up most often.
- Retrieval and RAG — answer the evaluation questions with retrieval off, then with retrieval pointed at an unrelated corpus. If the scores hold, the model's own parameters are answering and retrieval is not earning its cost.
- Document extraction — feed documents that contain none of the target fields, and documents with the fields removed. Count how often the extractor still emits a value. That number is the false-extraction rate the acceptance criteria should actually be written against.
- Forecasting — shift the target forward by an interval where no relationship can exist and confirm the skill disappears. Skill that survives a nonsense horizon is leakage from a feature computed over the whole period.
- Tabular classification — permute the labels through the full pipeline, then separately train on the identifier columns alone. A model that predicts the outcome from a record ID or a facility code found the collection process, not the phenomenon.
- Computer vision — occlude the region that carries the signal and retrain. In a 2020 methodological study, Maguolo and Nanni blacked out the center of chest X-ray scans, removing most of the lungs, trained on the outer part only, and obtained results comparable to those published for COVID-19 detection.
- Model-as-judge evaluation — swap answer order and measure verdict flips, plant known-bad answers, and re-score a fixed anchor set every run so judge drift stays separable from system change.
- Observational and causal work — pick a negative control outcome the intervention cannot affect but that shares the confounders, and estimate the effect on it. A nonzero estimate is a measurement of your bias.
- A/B and online experiments — run identical arms against each other before the real test. A platform that reports a significant difference between two copies of one system is miscalibrated, and every earlier result from it is suspect.
What a report owes the reader
First: the sentence that would have stopped the claim, written before the runs. Second: the controls executed, with their numbers, including any that came out badly. Third: the controls considered and not run, with the reason. That third sentence costs a supplier nothing when the work is sound, and it is the fastest way for a reviewer to tell a careful team from a lucky one.
What to do when the control refutes the claim
It happens, and the first move is diagnosis rather than damage control, because three very different situations produce the same failed run.
There is no signal. The permuted runs match the real one, and so does the corrupted-input run. The honest report says the data as collected does not support the prediction, and the useful part is why: the label is noisier than assumed, the outcome depends on information nobody records, the population is too heterogeneous at this sample size. Each is a specific finding about the customer's data, and each saves more than a marginal model would have earned.
There is signal, and it is the wrong signal. The corrupted-input control keeps its score, so something real is being learned, just not the thing on the label. Site identifiers, scanner settings, the order records were entered, a timestamp tracking a policy change. Finding this is a good day: it points at a data-collection fix that raises the ceiling for every future model, and it is the failure that would otherwise show up months later as unexplained collapse in production.
The instrument is broken. The positive control did not recover the planted effect. Nothing about the model has been learned yet, and no comparison run through this harness can be believed. Fix the harness first. Our notes on evaluation harnesses that survive a review cover what that repair usually involves.
A supplier who ships the failed control has shown that their evaluation was capable of producing a negative result, which is the one property no score demonstrates on its own. Buyers who have not yet lived through a deployment where the demo number failed in production should read the red flags in an AI benchmark before the next vendor meeting.
Bottom line
Every claim takes its shape from what could have refuted it. Baselines set the size of a result, controls establish that there is one, and a report needs both because reviewers ask both questions. The negative control is a day of compute against the possibility that the finding is an artifact. The positive control is a half-day against the possibility that the instrument cannot see. Both have to be specified before the headline number exists, or they answer a softer question than the one the reader has. Regulators settled this for clinical trials in 2000, and Congress wrote a version of it into how weapon systems are tested. The engineering version is not harder. It is just usually skipped.
Common objections
Permutation testing is too expensive for a model this size.
Then run it on a subsample, or freeze the representation and permute only the supervised head, and say in the report exactly which part of the pipeline the control covers. A control with a stated boundary is evidence. A missing control with a cost explanation is an open question, and the reviewer will answer it unfavorably.
We already ran ablations. Is that not the same thing?
An ablation attributes a gain to a component. A control tests whether the gain exists. The distinction is the pre-commitment: an ablation has an expected direction and no stopping rule, while a control has a written outcome that would have ended the claim. If your ablation carried such a rule before it ran, it was doing control duty.
Our data is operational, not experimental, so controls do not really apply.
Observational data is where controls do the most work, because none of the assignment was randomized and the confounding is unmeasured by construction. That is the setting the negative control outcome was developed for. Pick an outcome the mechanism cannot affect but that shares the confounders, estimate the effect on it, and you have a direct measurement of the bias in your design rather than an argument about it.
Frequently asked questions
A baseline is a rival system measured on the same data, and it tells the reader how large the improvement is. A control is a run designed so that a specific wrong explanation of the result would have shown up in it, and it tells the reader whether the result exists at all.
A run where the correct answer is "no signal," constructed by breaking the link the model is supposed to use. Shuffling the labels and rerunning the whole pipeline is the general-purpose version. Blanking the input region that carries the signal, or turning off the component you claim is doing the work, are the targeted versions. If performance survives the break, the performance was not coming from where you said.
Because it establishes that the measurement could have detected a failure, which is what makes a success interpretable. ICH E10 makes this explicit for clinical trials: a non-inferiority finding only counts as evidence of efficacy if the trial could have distinguished effective from ineffective treatments. The same reasoning applies to any acceptance test that might report no significant difference between two systems.
Enough that the position of your real score in the null distribution is stable across reruns, and enough to support the resolution you want to report. Give the number you ran, the distribution you obtained, and where your score fell in it. A reviewer can price the claim from that; they cannot price a bare statement that a permutation test was performed.
Yes, and the clause is short. Name the controls to be run, require the pass or fail threshold to be recorded before execution, and require delivery of results for every control performed regardless of outcome. Pair it with delivery of the evaluation harness separately from the modeling code, so the customer can rerun the controls after handover.