Iclr writing style

ICLR Writing Style

Use this to turn a technically correct draft into an ICLR-readable paper. The style should make the learning-representation contribution easy to evaluate under public review.

ICLR framing

• State the representation, learning problem, or model-behavior insight in the first page.
• Make clear whether the contribution is method, theory, benchmark, analysis, dataset, evaluation, systems support, or application-driven ML.
• Explain why the result changes how the community should train, evaluate, understand, or deploy learning systems.
• Avoid hiding the core idea behind implementation detail or benchmark trivia.
• Connect limitations to real deployment, robustness, safety, fairness, or data constraints when those issues are relevant.

Reviewer navigation

• Give reviewers a short "what to verify" path: main theorem, key ablation, benchmark setting, reproducibility artifact, or appendix section.
• Use figure captions as mini-arguments, not labels.
• Keep notation local and consistent; ICLR reviewers span subfields.
• Use the appendix to answer predictable objections, but do not move decisive evidence out of the main narrative.
• Write the abstract and introduction so the paper still makes sense when read through OpenReview snippets and search.

Framing that survives public skimming

On OpenReview a reader meets your paper as a title, a TL;DR, and an abstract snippet before opening the PDF, and the discussion thread is attached forever. The first page must carry the representation insight unaided.

Prose risk	ICLR-tuned rewrite	Why it matters under public review
Insight hidden behind setup	Lead with what changes about representations	Snippet readers never reach page 3
Vague contribution type	Name it: method/theory/analysis/benchmark	Reviewers route papers by type
Overclaimed generality	Scope to the tested regime	Public thread will surface the gap
Caption as label	Caption as a mini-argument	Reviewers read figures before text

Worked vignette

A draft on a new optimizer opens with three paragraphs of background before stating that the method reduces gradient variance in deep nets. Rewritten, the first sentence names the phenomenon and the fix, the introduction labels the contribution as "optimization analysis plus method," and a "what to verify" line points reviewers to the variance-reduction ablation in Section 4. The abstract is trimmed so its first 40 words stand alone as an OpenReview TL;DR.

Reviewer-pushback patterns

• "I cannot find the contribution." Put the representation insight in sentence one of the abstract.
• "Claim is broader than the evidence." Scope the wording; the public thread punishes overclaims.
• "Notation is inconsistent." Keep it local; ICLR reviewers span subfields and will flag drift.

Output format

[ICLR fit sentence] <one sentence>
[First-page problem] <what is hard or missing>
[Contribution type] method / theory / benchmark / analysis / data / systems / application
[Navigation fixes] <intro, figures, claims, appendix map>
[Risky prose] <overclaim, unclear novelty, unsupported generalization>