Writing the ML Methods Section of a Physics Paper

September 9, 2026 · 5 min read

Reviewers are not your enemy, but they have seen enough vague methods sections to be skeptical. If yours says "we trained a neural network on simulated data," expect a list of referee questions longer than the section itself. Writing the ML methods section of a physics paper is a distinct skill — not because the physics is hard to explain, but because the ML community and the HEP community have different defaults for what counts as "sufficient detail." This guide helps you satisfy both.

Know What the Reviewer Is Actually Asking

When a referee asks for more detail about your machine learning paper physics analysis, they are usually chasing one of three things:

1. Reproducibility — Could another group retrain your model and get the same result?
2. Validity — Did you avoid obvious pitfalls like data leakage or overtraining?
3. Scope — Do the conclusions generalise beyond your specific training set?

Structure your methods section to answer these three questions directly, even if no one has asked them yet. Reviewers will not tell you which concern motivated their comment; they will just ask for "more detail." Front-loading the right information saves a full round of revision.

What to Include

The Task Formulation

State clearly what you are asking the model to do. Is it a binary classifier — signal versus background? A regression over a kinematic observable? A generative model for fast simulation? One sentence of task formulation prevents the most common confusion: a reader assuming you did something you did not.

The Architecture and Its Rationale

Name the model family (BDT, fully connected network, graph neural network, transformer) and the key hyperparameters that define its capacity — number of layers, hidden units per layer, depth of trees, or whatever is equivalent for your architecture. You do not need to justify every choice as theoretically optimal, but a brief phrase connecting the architecture to the problem helps enormously. For example, noting that you used a graph network because your event representation is naturally a point cloud tells the reviewer you made an informed choice rather than a default one.

Input Features

List the observables you fed to the model. In the writing ML methods section context, this is the step most authors under-describe. Physics reviewers want to know whether the inputs carry detector-level artefacts, whether they are correlated with nuisance parameters, and whether they were already used to define the event selection. A bulleted list with a one-phrase description of each feature is rarely too much.

Training Dataset and Labels

Describe where the training data came from — Monte Carlo generator, data-driven sideband, real collision data, or a mixture. State how signal and background labels were assigned and whether any reweighting was applied. If you trained on simulation and applied the model to data, say so explicitly and point to the section where you discuss the associated systematic uncertainty.

Training Procedure

Mention the loss function, optimizer, learning rate schedule (even just "constant" or "with early stopping"), and batch size. These are the inputs a reader would need to rerun your training. If you used early stopping based on a validation set, say what fraction of your training sample was held out and how stopping was determined. This is the ML equivalent of stating your fit convergence criterion.

Overtraining Check

Overtraining in a classifier is conceptually the same as overfitting a chi-square with too many free parameters — the model describes statistical fluctuations in the training sample rather than genuine structure. Describe how you checked for it: a comparison of training and validation loss curves, a Kolmogorov–Smirnov test on the score distribution across folds, or a dedicated held-out test set that was never used during model selection. Referees who have seen post-hoc overtraining discoveries will look for this immediately.

Performance Metric

Report the metric that governs your physics conclusion — usually a ROC curve or its integral, translated into physics language as efficiency versus background rejection. If your analysis optimises a significance estimate, say which one and how you connected model output to that quantity. Avoid reporting only a single working-point accuracy without context.

What to Skip

You do not need to derive backpropagation, explain what a decision tree is, or reproduce the original paper for your architecture. Reviewers are physicists, not ML students. If a concept requires explanation, link to a public reference or note that details appear in an appendix. The full HEP ML course is a useful pointer for readers who want the conceptual foundations without derailing the methods section.

How to Structure the Section

A reliable ordering: task → inputs → model → training → validation → performance. Each subsection can be a single dense paragraph. Bullet lists work well for feature tables. Avoid mixing uncertainty discussion into the methods section — give systematics their own subsection so the methods stay readable.

If your analysis has multiple models (a classifier plus a generative model for background estimation, for example), give each its own sub-section following the same template.

A Note on Code and Reproducibility

Consider depositing your training code and configuration file in a public repository and citing it. This single step answers the reproducibility question before it is asked, and it is increasingly expected in the field.

A well-written ML methods section does one thing: it lets a careful reader assess your result without having to guess what you did.