CS/AI paper submission readiness in 2026: a field checklist

dateModified: 2026-09-27

The Complete Guide to Writing and Submitting an Academic Paper

*Subtitle: A field manual for CS/AI researchers targeting top venues — NeurIPS, ICLR, ICML, ACL Rolling Review, CVPR*

• Version: 1.0 · RULESET_VERSION: 2026-09-27
• Scope: conference-style papers in computer science / AI (typically 8–10 pages + unlimited references and appendices). Journal variants are noted where they differ.
• Language note: every rule below is deterministic — it can be checked by a machine against your draft. Nothing here depends on a language model's opinion.

**Honesty note.** This guide cannot and does not promise acceptance. No tool, template or checklist controls whether reviewers judge your work novel and sound. What it does control is the large share of losses that come from *avoidable* defects: missed deadlines, missing baselines, unquantified claims, unreproducible details, un-verified references, and rebuttals that answer the wrong question. Fix those and you compete on the science rather than losing on the packaging. Every statistic below carries a source link and a "verify" flag where the number moves each cycle.

---

Part 0 · Why papers fail in 2026 (read this before you write)

Rejection is normal, and the volume curve explains why. Four verified facts shape your strategy:

|---|---|---|---|---|---|

Four consequences you should design around:

• Desk rejection is a real, mechanical failure mode. ICLR 2026 desk-rejected 779 submissions for procedural and content violations, including papers whose citations were hallucinated — the program chairs ran automated reference checking and every flagged case was manually confirmed before rejection [ref:iclr2026]. A bibliography mistake that used to annoy a reviewer now removes your paper before review. → See Appendix B, Reference Integrity.
• Reviewer capacity is now rationed. ACL adopted a sustainable reviewing policy applying from October 2026: submissions are only *guaranteed* review when they bring a qualified service contributor, with caps of 20 submissions for any single author and 5 as first/co-first author; all authors must hold OpenReview profiles with accurate affiliation, ORCID, DBLP and ACL Anthology links — non-compliance can lead to desk rejection [ref:arrcfp]. Practical read: your author line is now part of your submission strategy, not an afterthought.
• LLM use is disclosed and policed. ICLR's 2026 policy required disclosure of any LLM use and treated violations as a code-of-ethics matter; it also ran two LLM detectors over all 76,139 reviews [ref:iclr2026]. Venues permit polishing, not authorship. Keep your own record of how you used assistance and disclose it in the correct field.
• Preprints carry a quality signal too. arXiv requires first-time posters in a subject area to be endorsed by a qualified arXiv author in that field, and since October 2025 does not accept computer-science review or position papers that have not passed peer review [ref:arxivmoderation]. A preprint is no longer a free proof of existence.

The strategy implied: treat submission as an engineering pipeline with gates, not as a writing sprint. Parts 1–7 below are those gates.

---

Part 1 · Paper structure, section by section

The thirty-second version

|---|---|---|

1.1 Title

Purpose. The title is a routing signal (which area chair / reviewer gets the paper) and a memory hook. It is also the first claim you make, so it must be defensible.

Rules:

• Include the method name or the mechanism and the task/domain. Pattern: `[Method]: [what it does] for [task/domain]`.
• 10–15 words. Over 18 words is rarely defensible.
• Avoid unexplained acronyms except field-standard ones (NLP, GAN, MoE, RLHF).
• Avoid unsupported adjectives: "Novel", "Efficient", "Robust", "Superior" are claims, not descriptions. Either the numbers support them or remove them.

Common failure modes with fixes:

|---|---|---|

Checklist: ≤15 words · contains the mechanism · contains the task · no unsupported adjective · every acronym either expanded or standard · reads correctly in one breath.

1.2 Abstract

Purpose. A standalone unit of currency. Abstracts are read (scraped, indexed, skimmed by chairs) far more often than the paper. It is also the first thing that can get you into a bad-fit reviewer pool.

Use four sentences, each doing one job:

• Context/motivation (1 sentence): the concrete problem and why it matters now.
• Gap (1 sentence): what existing approaches fail to do, stated as a limitation and not as an attack.
• This work (1–2 sentences): what you introduce, with the mechanism named.
• Result (1–2 sentences): the headline numbers against the strongest baseline, plus the most important secondary result (efficiency, robustness, or a negative result).

Rules:

• Quantify. "Significantly improves" is not information. "Raises BLEU by 3.2 over X under identical decoding settings" is.
• Do not paste a compressed Introduction: no citations, no undefined acronyms, no "we propose" three times.
• Stay inside the word limit (usually 150–250 words for conferences; check the CFP).
• Every number in the abstract must appear in the same form somewhere in the body. Reviewers check this.

Common errors: no numbers; numbers without units or baselines ("improves by 12%" — 12% of what?); pasting results from a different experimental setting than the headline table; writing in future tense ("we will show").

1.3 Introduction

Structure: a funnel, then a claim ledger.

Paragraphs 1–2 — Funnel: broad context → the concrete problem → why it is hard, not merely why it is unsolved. Name prior attempts; conclude with the specific missing capability.

Paragraph 3 — Gap and motivation: what breaks today. Be concrete (cost, latency, instability, data requirement). This is where you earn the right to propose anything.

Paragraph 4 — What we do: one paragraph overview, ideally with the difference from previous work stated in one sentence.

After that — Contributions, as 3–4 bullets. Each bullet must be atomic, verifiable and non-overlapping:

Our contributions are:
1. A method: X, which replaces the greedy decode step with constrained decoding over a type lattice.
2. An analysis: we show that beam-reranking failures concentrate on spans longer than 8 tokens (Figure 3), which explains 61% of residual errors.
3. Evidence: +4.7 Recall@100 and 2.3x faster inference than <strong baseline>, reproduced across three seeds and two corpora.
4. Artifacts: code, trained checkpoints, and a 12k-case labelled evaluation set released at <URL> (anonymous link for review).

Rules:

• Each contribution bullet should be checkable in 10 seconds. "We propose a novel framework" is not a contribution; "a module that removes step X, reducing operation count from O(n²) to O(n log n) measured on three tasks" is.
• Do not oversell. If two bullets describe the same thing, merge them.
• If you include a figure in the Introduction, make it the "why this is hard" figure, not the architecture overview (that belongs in Method).

1.4 Related work

Purpose. Prove you know the neighbourhood and place yourself inside it. Reviewers here are frequently the authors you forgot.

Organisation:

• Group by theme, never chronologically. Three-to-five groups, 3–5 representative papers each.
• Within a group, organise by the dimension you care about (assumption, data regime, objective), then state what the group as a whole does not solve.
• End with a short paragraph or a comparison table that explicitly contrasts your setting with each group. A one-row-per-prior-work table with columns *(setting, assumptions, key limitation, how we differ)* is worth more than a page of prose.

Rules:

• Cite primary sources, not "e.g. [1,2,3] studied X". Each cited work needs a verb describing what it did.
• Cover recent work (last 24 months in fast fields) and include arXiv preprints where relevant — with arXiv IDs and dates, since presenting someone's preprint as unknown to you is worse than citing it.
• Include the closest competitor *even if it hurts*. Reviewers test exactly this.
• Do not write a survey: every cited paper must connect to your positioning sentence.

1.5 Method

Purpose. Reproducibility and credibility. This section either makes your method reimplementable or makes reviewer doubt rational.

Order:

• Overview figure first. A pipeline/architecture figure with numbered stages, referenced from the text. Without it, readers build a wrong mental model and blame you.
• Problem formulation. Notation table (symbol, shape/type, meaning). Every symbol used later appears here.
• Components, macro to micro, each with motivation → mechanism → cost.
• Complexity / properties (optional but strong): formal statement about what the design guarantees.
• Implementation-relevant details — unless your venue wants them in Experiments (see Part 3).

Rules:

• Notation consistency. One symbol, one meaning, throughout: not `x` in §3 and `X` in §4. Keep a single notation table and grep for duplicates before submission.
• Number key equations and refer to them by number, not "the equation above".
• State what is fixed versus learned; state the loss and why each term exists.
• Every claim about the mechanism needs either a derivation, a citation, or an experiment — never pure assertion.
• Avoid implying generality you do not have ("works for any sequence model" when you tested two Transformers).

Common errors with fixes:

|---|---|---|

1.6 Experiments

Purpose: convert the claims in the Introduction into evidence. Every contribution bullet must map to at least one result; every result must map to a claim. Build a coverage matrix as you write (Appendix A).

Required blocks:

|---|---|---|

See Part 3 for the reporting standard.

1.7 Conclusion, limitations, and the required statements

• Conclusion: half a page max. Restate the contribution in past tense, but never introduce new results or new citations here.
• Limitations: required at many venues (ACL 2026 required a Limitations section; most venues now require it or a broad-impact/ethics statement — check the CFP). Write it honestly and specifically; vague limitations read as evasion. A precise limitation ("we assume access to gold spans at training time") doubles as protection when a reviewer raises the same point.
• Ethics / broader impacts: state the likely misuse concretely. Boilerplate ("dual use in surveillance") is transparently useless; one sentence naming your actual downstream application is better.
• Reproducibility: code, data, hyperparameter search budget, hardware, and total compute. Several venues (including CVPR) now run reporting mechanisms around compute.
• Acknowledgements with LLM disclosure: polished by a language model is disclosure-worthy; generated content is authorship territory. Follow your venue's field, not opinions online.

---

Part 2 · Literature review as a repeatable process

A survey written once is stale in three months. Build a query set + alert pipeline, then write from a table, not from memory.

2.1 Six-step retrieval protocol

1. Define 3-5 synonym groups for the core concept (including the *old* term for it).
   Example: "hallucinated citation"  |  "fabricated reference"  |  "bibliographic error"  |  "citation accuracy"
2. Search each group on Google Scholar, Semantic Scholar and DBLP (DBLP for exact author/venue disambiguation).
3. Sort by citations, take the top ~20 within your sub-area, not the whole field.
4. Backward snowball: harvest each paper's Related Work for the older canon.
5. Forward snowball: use "Cited by" on Semantic Scholar / OpenAlex to find later work that corrects, extends
   or refutes those 20 papers. This is where you find the method you will be compared against.
6. Recency sweep: check the last 6 months (arXiv daily listings for cs.LG / cs.CL / cs.CV; venue homepages).

2.2 Screening criteria

|---|---|

2.3 From pile to prose

Build a evidence grid before writing. Columns: work | setting | method family | data | results | your delta | must-cite?.

• Cluster rows into 3–5 themes; the themes become your subsections.
• Inside each theme, order by the dimension that reveals progression (assumption relaxed → data regime widened → objective refined).
• Write a comparison table for the 5–10 closest works (this table is often the most-read item in the section).
• Close each subsection with the unsolved part that your paper addresses.

2.4 Keeping it current (30 minutes a month)

• arXiv daily listing for your category (cs.CL, cs.LG, cs.CV, cs.AI) — scan titles only, save to your manager.
• A tool-driven alert (ResearchRabbit / Semantic Scholar alerts / Connected Papers) seeded with your 5 anchor papers. New hits go into the grid, not into the manuscript.
• Before each submission, re-run step 6 (recency sweep) and add anything that appeared while you were writing. This single habit prevents the most common Related-Work rejection: "the authors missed X, which solves half of this".

---

FAQ

References (verified 2026-09-27)

• NeurIPS 2025 review reflections
• ICLR 2026 review retrospective
• CVPR 2026 technical program news
• ACL Rolling Review CFP
• ACL Rolling Review dates
• arXiv moderation policy