# ML Conference Paper: [Paper title stating the method or finding]

> Machine learning conference paper template: abstract, introduction,
> related work, method, experiments, results, limitations, broader
> impact, reproducibility statement, references, appendix and a paper
> checklist aligned with the NeurIPS 2026 Paper Checklist (16 items), with
> a mapping note for the ACL Rolling Review Responsible NLP Research
> checklist. Replace every `[bracketed]` value and every row marked
> *Example*. Always follow the current call for papers, author handbook
> and style files of your venue, which take precedence over this template.

<!--
Guidance: How to use this template
- Write the paper in Markdown to plan and review it, then move the text
  into the venue's LaTeX style file for submission. Keep this file as the
  team's working copy.
- Draft in this order: contributions list (section 1.3), experiments
  (section 4), results (section 5), method (section 3), introduction, then
  abstract and title last.
- Fill the paper checklist (section 12) while running experiments, not on
  the night of the deadline. Each "Yes" must point to a section.
- Anonymise for double-blind review: no author names, no acknowledgements,
  no identifying links, self-citations in the third person.
- Delete the Document control, Revision history and Contents sections
  before submission; they are for the author team. Replace the H1 with
  the paper title only.
- For the full reproducibility audit of the study design, use the ML
  Reproducibility and Validity Checklist (`ai-data/ml-reproducibility-checklist`).
-->

## Document control

<!-- Guidance: Internal tracking for the author team. Copy the venue's limits here so nobody has to look them up again. Remove before submission. -->

| Field | Value |
|---|---|
| Paper ID | [PAPER-2026-001] |
| Target venue and track | [*Example:* NeurIPS 2026, Main Track] |
| Content page limit | [*Example:* 9 pages at submission; references, appendix and checklist excluded; check the handbook] |
| Abstract and paper deadlines | [YYYY-MM-DD AoE / YYYY-MM-DD AoE] |
| Review model | [Double-blind / Single-blind] |
| Required checklist | [NeurIPS Paper Checklist / ARR Responsible NLP checklist / venue form] |
| Style file version | [*Example:* neurips_2026.sty] |
| Version | [0.1] |
| Status | [Draft / Internal review / Submitted / Rebuttal / Camera-ready] |
| Owner (lead author) | [@lead-author] |
| Approvers / reviewers | [@senior-author], [@co-authors] |
| Last updated | YYYY-MM-DD |
| Classification | [Confidential until submission / Public after acceptance] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Lead author | [@name] | [Ready to submit] | YYYY-MM-DD |
| Senior author | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| All co-authors | [Names] | [Approved final version and author list] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record drafting rounds, the submitted version, rebuttal changes and the camera-ready version. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Contributions, experiments plan and figure list |
| 0.5 | YYYY-MM-DD | [@name] | *Example:* Full draft with main results table |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Submitted version |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Camera-ready with extra page and reviewer-requested ablation |

## Contents

<!-- Guidance: Keep aligned with the headings below. -->

1. [Abstract](#abstract)
2. [1. Introduction](#1-introduction)
3. [2. Related work](#2-related-work)
4. [3. Method](#3-method)
5. [4. Experimental setup](#4-experimental-setup)
6. [5. Results](#5-results)
7. [6. Limitations](#6-limitations)
8. [7. Broader impact](#7-broader-impact)
9. [8. Conclusion](#8-conclusion)
10. [9. Reproducibility statement](#9-reproducibility-statement)
11. [10. References](#10-references)
12. [11. Appendix](#11-appendix)
13. [12. Paper checklist](#12-paper-checklist)
14. [Standard and licence note](#standard-and-licence-note)

## Abstract

<!-- Guidance: One paragraph, about 150 to 250 words. Answer: what problem, why it matters, what you did, what you found (with one or two headline numbers), and what it means. Pitfall: claims in the abstract that the experiments do not support, which checklist item 1 asks about directly. -->

[Context: one sentence on the problem and why it matters.] [Gap: what
current methods cannot do.] [Approach: what you propose, in one or two
sentences.] [Results: the main finding with numbers and the setting.]
[Implication: what this enables.]

*Example:* Retrieval-augmented language models often cite passages that
do not support their answers. We introduce [Method], a training objective
that rewards answers whose claims are entailed by the cited passage.
Across three open-domain question answering benchmarks, [Method] raises
citation precision from 71.2% to 84.5% at equal answer accuracy, and the
gain holds for models from 1B to 13B parameters. We release code,
trained checkpoints and an evaluation set of 2,000 human-verified
citations.

## 1. Introduction

<!-- Guidance: About one page. Move from problem to gap to contribution quickly. End with an explicit, numbered list of contributions that the rest of the paper proves. Pitfall: contributions phrased as activities ("we study") rather than results ("we show"). -->

### 1.1 Problem and motivation

[Describe the problem, a concrete failure example and why it matters in
practice or for science. Cite the most relevant prior work.]

### 1.2 Gap

[State precisely what existing approaches cannot do and why. Refer to
section 2 for the detailed comparison.]

### 1.3 Contributions

1. [Method or theory contribution.] *Example:* A training objective that
   rewards citation entailment, with a variance-reduced estimator.
2. [Empirical contribution.] *Example:* Experiments on three benchmarks and
   four model sizes showing consistent gains in citation precision.
3. [Resource contribution.] *Example:* A human-verified evaluation set of
   2,000 citations, released under CC BY 4.0.
4. [Analysis contribution.] *Example:* An analysis of failure cases showing
   where the objective does not help.

Figure 1 *(Example)*: an overview diagram placed at the top of page 2
showing the pipeline and where the new component fits.

## 2. Related work

<!-- Guidance: Group prior work by idea, not by paper. For each group, say what it does and how your work differs. Pitfall: listing papers without stating the difference, or omitting the strongest competing method. -->

**[Theme 1, for example retrieval-augmented generation].** [Two to four
sentences summarising the line of work and the key citations, then one
sentence on how this paper differs.]

**[Theme 2, for example attribution and faithfulness evaluation].**
[Summary and difference.]

**[Theme 3, for example learning from automated feedback].** [Summary and
difference.]

**Concurrent work.** [Note papers that appeared close to the submission
date and how they relate, if any.]

## 3. Method

<!-- Guidance: Give enough detail that an expert could reimplement the method from this section and the appendix. Define notation once. State assumptions explicitly; checklist item 3 asks for them. Pitfall: a method section that describes only the final variant and hides choices that the ablations later show matter. -->

### 3.1 Problem setup and notation

[Define inputs, outputs, the model and the objective.] *Example:* Given a
question $q$ and a set of retrieved passages $P$, the model produces an
answer $a$ with citations $c \subseteq P$.

### 3.2 Approach

[Describe the method step by step. Use an algorithm box in the final
LaTeX version if the procedure has more than three steps.]

*Example:* The training objective combines the standard likelihood with
an entailment reward weighted by $\lambda$:

$$
\mathcal{L}(\theta) = \mathcal{L}_{\text{NLL}}(\theta) - \lambda \, \mathbb{E}_{a \sim \pi_\theta}\left[ r_{\text{ent}}(a, c) \right]
$$

### 3.3 Theoretical results

[State each theorem or proposition with all its assumptions. Give a
proof sketch here and the full proof in the appendix. If the paper has
no theory, delete this subsection and answer checklist item 3 with N/A.]

### 3.4 Design choices

| Choice | Options considered | Selected | Reason | Ablation |
|---|---|---|---|---|
| *Example:* Entailment scorer | NLI model, LLM judge | NLI model | Cheaper, more stable rewards | Table 3, row 2 |
| *Example:* Reward weight $\lambda$ | 0.1, 0.3, 1.0 | 0.3 | Best validation trade-off | Figure 4 |
| [Choice] | [Options] | [Selected] | [Reason] | [Location] |

## 4. Experimental setup

<!-- Guidance: Report datasets, splits, baselines, metrics, hyperparameter selection and compute here or in the appendix with a pointer. Checklist items 4, 6 and 8 depend on this section. Pitfall: tuning your method more than the baselines. -->

### 4.1 Datasets

| Dataset | Task | Train / val / test | Licence | Notes |
|---|---|---|---|---|
| *Example:* [Dataset A] | Open-domain QA | 79k / 8.7k / 3.6k | [Licence] | Standard split |
| *Example:* [New evaluation set] | Citation verification | 0 / 500 / 1,500 | CC BY 4.0 | Released with this paper |
| [Dataset] | [Task] | [Sizes] | [Licence] | [Notes] |

### 4.2 Baselines

[List each baseline, its source, and how it was tuned. Use the same
tuning budget for baselines and the proposed method, or explain why
not.]

### 4.3 Metrics

[Define each metric, how it is computed and why it fits the claim. For
human evaluation, describe raters, instructions and agreement.]

### 4.4 Implementation and hyperparameters

[Framework and versions, optimiser, learning rate schedule, batch size,
number of seeds, hyperparameter search space and selection rule. Put the
full table in Appendix B.]

### 4.5 Compute

| Experiment | Hardware | Time per run | Runs | Total |
|---|---|---|---|---|
| *Example:* Main training, 7B model | 8 x [GPU model], 80 GB | 14 h | 3 seeds | 336 GPU-hours |
| *Example:* Ablations | 8 x [GPU model] | 6 h | 12 | 576 GPU-hours |
| *Example:* Preliminary and failed runs | Same | Various | Various | about 900 GPU-hours (estimate) |
| [Experiment] | [Hardware] | [Time] | [Runs] | [Total] |

## 5. Results

<!-- Guidance: Lead each subsection with the claim, then the evidence. Report variability (error bars, confidence intervals or tests) and say what it captures. Pitfall: bold numbers that are within the noise of the baseline. -->

### 5.1 Main results

Table 1 *(Example)*: citation precision and answer accuracy, mean and
standard deviation over 3 seeds.

| Method | Citation precision (%) | Answer accuracy (%) |
|---|---|---|
| *Example:* Baseline A | 71.2 ± 0.6 | 58.4 ± 0.4 |
| *Example:* Baseline B | 74.0 ± 0.9 | 58.1 ± 0.5 |
| *Example:* [Method] | 84.5 ± 0.7 | 58.6 ± 0.3 |

[State the main finding in one or two sentences, with the comparison and
the variability.] State what the error bars capture (for example seeds,
data splits or bootstrap over test items), how they were computed, and
whether they are standard deviation, standard error or a confidence
interval.

### 5.2 Ablations

[Remove or replace each component and report the effect. Link each row
to the design choices table in section 3.4.]

### 5.3 Analysis

[Scaling behaviour, robustness to distribution shift, qualitative
examples, error analysis. Show at least one example where the method
fails.]

## 6. Limitations

<!-- Guidance: Be specific: assumptions that may not hold, settings not tested, sensitivity to choices, computational cost, and failure modes. Reviewers usually reward honest limitations. Pitfall: a generic paragraph that could fit any paper. -->

- [Assumption and where it may fail.] *Example:* The entailment scorer is
  trained on English; gains in other languages are untested.
- [Scope of evaluation.] *Example:* All benchmarks use Wikipedia passages;
  domains with conflicting sources may behave differently.
- [Cost.] *Example:* Training is 1.4 times slower than the baseline because
  of reward computation.
- [Other limitation.]

## 7. Broader impact

<!-- Guidance: Consider effects when the method works as intended, when it fails, and when it is misused. Describe mitigations and any safeguards for released assets. Pitfall: claiming no possible negative impact for a method that generates text or images. -->

**Positive impacts:** [*Example:* Better-supported citations help users
verify answers.]

**Potential negative impacts:** [*Example:* Higher citation precision may
increase user trust in answers that are still wrong when retrieved
sources are wrong.]

**Mitigations and safeguards:** [*Example:* The released model card
states the scorer's language limits; checkpoints are released under a
licence with acceptable-use terms.]

## 8. Conclusion

<!-- Guidance: Restate the contribution and the main evidence in a few sentences, then one or two directions for future work. Pitfall: introducing new claims or results here. -->

[Summarise what the paper showed, the evidence for it, and what remains
open.]

## 9. Reproducibility statement

<!-- Guidance: Tell readers exactly where to find everything needed to reproduce the main results. Use anonymous links at submission. Pitfall: promising "code will be released" with no plan or licence. -->

| Artifact | Location | Licence | Status at submission |
|---|---|---|---|
| Code | [Anonymous repository URL or supplementary ZIP] | [*Example:* Apache-2.0] | [Included / Anonymous link / On acceptance] |
| Trained models | [Location] | [Licence] | [Status] |
| New data | [Location] | [*Example:* CC BY 4.0] | [Status] |
| Exact commands | [README section] | Not applicable | [Status] |
| Environment | [*Example:* Lock file and container image digest] | Not applicable | [Status] |
| Seeds and evaluation outputs | [Location] | Not applicable | [Status] |

[One paragraph pointing to the method details (section 3), hyperparameters
(Appendix B), compute (section 4.5) and proofs (Appendix A).]

## 10. References

<!-- Guidance: Use the venue's reference style. Cite the published version of a paper when one exists, cite datasets and software, and check every reference resolves. -->

[1] [Author, A., Author, B. (Year). Title. Venue.]

[2] [Author, C. (Year). Dataset name, version. Repository. DOI.]

[3] [Software name, version. URL.]

## 11. Appendix

<!-- Guidance: The appendix supports, never replaces, the main paper. Every main claim must be understandable without it. Pitfall: moving essential setup details out of the main text to save space. -->

### 11.1 Appendix A: Proofs

[Full proofs of the results in section 3.3, with all assumptions.]

### 11.2 Appendix B: Hyperparameters and training details

| Hyperparameter | Search space | Selected | Selection criterion |
|---|---|---|---|
| *Example:* Learning rate | 1e-5, 3e-5, 1e-4 | 3e-5 | Validation citation precision |
| *Example:* Batch size | 64, 128 | 128 | Throughput at equal accuracy |
| [Name] | [Space] | [Value] | [Criterion] |

### 11.3 Appendix C: Additional results

[Per-dataset breakdowns, extra seeds, further ablations, qualitative
examples.]

### 11.4 Appendix D: Human evaluation and data documentation

[Full rater instructions, interface screenshots, compensation, consent
process and ethics approval if human participants were involved.
Documentation for new datasets, for example a datasheet; see Datasheet
for Datasets (`ai-data/datasheet-for-datasets`) and Model Card
(`ai-data/model-card`).]

## 12. Paper checklist

<!-- Guidance: NeurIPS requires the checklist at the end of the submission PDF, after references and appendices; it does not count toward the page limit, and papers without it are desk rejected. Answer Yes, No or N/A for each item with a short justification; for Yes, point to the section. Answering No or N/A is not by itself grounds for rejection when justified. The items below paraphrase the NeurIPS 2026 checklist topics in original words; copy the official wording from the style file when submitting. -->

### 12.1 NeurIPS 2026 Paper Checklist (paraphrased)

| # | Topic | What the item asks (paraphrased) | Answer | Justification and section |
|---|---|---|---|---|
| 1 | Claims | Do the abstract and introduction state claims that match what the paper actually shows, including its scope? | [Yes / No / N/A] | *Example:* Yes: claims in section 1.3 map to Table 1, Table 3 and section 5.3 |
| 2 | Limitations | Does the paper discuss its limitations, such as strong assumptions, robustness and the scope of the evidence? | [Answer] | *Example:* Yes: section 6 |
| 3 | Theory, assumptions and proofs | Does each theorem come with its full list of assumptions and a proof that is complete and sound? | [Answer] | *Example:* Yes: section 3.3 and Appendix A |
| 4 | Experimental result reproducibility | Does the paper give enough information to reproduce or verify the main results, whether or not code is released? | [Answer] | *Example:* Yes: sections 3, 4 and Appendix B |
| 5 | Open access to data and code | Can readers get the code and data, together with run instructions good enough to regenerate the main results? | [Answer] | *Example:* Yes: anonymous repository, section 9 |
| 6 | Experimental setting and details | Are splits, hyperparameters, their selection and other training and test details specified? | [Answer] | *Example:* Yes: section 4.4 and Appendix B |
| 7 | Statistical significance | Are error bars, confidence intervals or significance tests reported for the main claims, with what they capture and how they were computed? | [Answer] | *Example:* Yes: Table 1 caption and section 5.1 |
| 8 | Compute resources | For each experiment, are the compute type, memory and run time reported, along with whether the whole project used more compute than reported? | [Answer] | *Example:* Yes: section 4.5, including failed runs |
| 9 | Code of ethics | Has the team checked the work against the NeurIPS Code of Ethics and found it consistent with it? | [Answer] | [Justification] |
| 10 | Broader impacts | Are both the beneficial and the harmful ways the work could affect society discussed? | [Answer] | *Example:* Yes: section 7 |
| 11 | Safeguards | When released models or data could readily be misused, are the protective measures around their release explained? | [Answer] | [Justification] |
| 12 | Licences for existing assets | Does the paper name who made the existing code, data and models it uses, and state and follow their licences and terms? | [Answer] | *Example:* Yes: section 4.1 table |
| 13 | New assets | Do newly released assets ship with their own documentation, covering consent and anonymisation where these matter? | [Answer] | *Example:* Yes: Appendix D |
| 14 | Crowdsourcing and human subjects | For work with crowd workers or participants, are full instructions, screenshots where relevant and compensation details included? | [Answer] | [Justification] |
| 15 | IRB approvals | Are risks to participants described, and was ethics board (or equivalent) approval obtained and disclosed where required? | [Answer] | [Justification] |
| 16 | Declaration of LLM usage | If an LLM is an important, original or non-standard part of the core method, is its use described? Writing and editing help need not be declared. | [Answer] | [Justification] |

### 12.2 Note on the ACL Responsible NLP Research checklist

Papers submitted through ACL Rolling Review complete the Responsible NLP
Research checklist in the submission form instead. It covers the same
ground in five parts, summarised here in original words:

| Part | Topic | Where this template covers it |
|---|---|---|
| A | Limitations and potential risks of the work (every submission) | Sections 6 and 7 |
| B | Use and creation of scientific artifacts: citation, licences, intended use, personal or offensive content checks, documentation, data statistics | Sections 4.1, 9 and Appendix D |
| C | Computational experiments: model size and compute, setup and hyperparameters, descriptive statistics, settings of existing packages | Sections 4.4, 4.5, 5.1 and Appendix B |
| D | Human annotators or participants: instructions, recruitment and pay, consent, ethics review, demographics | Appendix D |
| E | Use of AI assistants in the research or writing | Acknowledgements (camera-ready) and section 4 if part of the method |

Check the current ARR checklist page before each cycle; it is revised
between cycles.

## Standard and licence note

Structure aligned with the NeurIPS 2026 Paper Checklist and Main Track
Handbook (neurips.cc), and with the ACL Rolling Review Responsible NLP
Research checklist. Checklist items are paraphrased in original words
and are not the official wording; copy the official items from the
venue's current style file or submission form when submitting. All
other text and examples are original, and example numbers are
illustrative. Check the current call for papers, handbook and checklist
of your venue before use. Template licence: MIT.