Structure, visual design and revision

This chapter provides editorial design guidance. Apply the official template for your conference and year; the example structures below are not compulsory headings or page allocations.

Choose an outline that matches the contribution

Contribution	A useful argument sequence	Keep in the main text
New method	Problem → key observation → mechanism → controlled evaluation → limits	Defining mechanism, essential objective, principal evidence and interpretation
Theory	Question → definitions → assumptions → main result → proof intuition → implications	The actual theorem, its scope and the reason it matters
Empirical discovery	Question → measurement design → phenomenon → alternative explanations → robustness	Protocol validity, central finding and meaningful counterexamples
Dataset / benchmark	Measurement gap → construction → validation → baseline study → access and limits	Target capability, data/split provenance and threats to validity
System	Workload → design constraints → architecture → implementation → performance and failures	Operating assumptions and a reproducible comparison contract

Related work can appear early when the gap is hard to understand without it, or later when it would interrupt the mechanism. Whichever location you choose, place indispensable comparisons where the relevant claim is made. Do not use a late related-work section to hide the closest baseline.

Plan the visual argument before polishing artwork

Write one question above every planned figure. If the figure cannot answer it without several paragraphs of surrounding explanation, simplify its scope or improve its labels.

Visual purpose	Suitable form	What must remain visible
Explain a new architecture	Data-flow diagram with a worked example	Inputs/outputs, frozen/trainable modules, training/inference difference, proposed change
Explain an algorithm	Short original pseudocode + state transition	Initialization, loop, update, stopping condition, required inputs
Compare performance	Exact table or justified plot	Dataset, metric, direction, protocol, uncertainty, baseline identity
Explain a theorem	Dependency/assumption diagram + precise statement	Conditions, conclusion, exclusions and logical rather than merely visual arrows
Show a failure	Paired example or error breakdown	Selection policy, ground truth/reference, failure definition and scale
Explain a benchmark	Sampling/split/annotation pipeline	Unit of observation, exclusions, leakage controls and evaluation target

An architecture figure should expose the changed computation

Use the spatial arrangement to answer four questions:

1. Where does each input enter, and what information is available?
2. What operation changes compared with the closest baseline?
3. Which signals supervise which components during training?
4. What remains at inference?

Label arrows with the tensors, states or supervision they carry when this is not obvious. Use a consistent shape or border for frozen versus trainable components. A loss node is not an inference output. A dashed arrow needs a legend. Reused backbones should not visually overshadow a small but important novel operation.

For a teacher–student system, a training/inference divider can be more informative than two similarly styled model boxes. For a retrieval system, distinguish indexing, retrieval and answer generation. For flow or diffusion methods, distinguish a training objective from the numerical sampling trajectory.

Caption as a compact explanation

A caption should identify what is shown, how to read it, the relevant setting and the main supported observation. Define uncommon abbreviations and symbols locally. Clarify whether a diagram is conceptual, a sampled example or an exact experimental result.

Do not put a new major claim only in a caption. Do not use the caption to compensate for unreadable text. A reader viewing the figure at the paper’s normal scale should understand the labels without enlarging it several times.

Tables should protect comparisons

Make the table’s unit and comparison groups explicit. Separate results with different data access, parameter scales or evaluation protocols. A single bold “best” cell can be misleading if the neighboring methods were trained on different data.

An original table-planning template:

Method / variant	Training access	Test-time inputs	Metric and direction	Uncertainty	Cost / protocol note
Closest baseline	Specify	Specify	Verified value	Define statistic	Same comparison contract
Proposed method	Specify	Specify	Verified value	Define statistic	List changed resources
Controlled ablation	Same unless stated	Same unless stated	Verified value	Define statistic	Isolates one hypothesis

This is a planning shell, not measured data. Replace it with a compact table suited to the experiment; do not invent uncertainty if the study did not measure it.

Before publication:

• Define whether an interval is a confidence interval, standard deviation, standard error or another quantity.
• State the number and unit of repetitions. Repeated seeds and independent patient cohorts answer different questions.
• Distinguish percentage points from percentage improvement.
• Preserve units and metric direction; use consistent numeric precision supported by the measurement.
• Explain unavailable entries, adapted baselines and results taken from another publication.
• Check row/column alignment against source results after every layout change.
• Keep all necessary caveats in the caption or table note, not only in distant appendix prose.

Plots should reveal the comparison, not exaggerate it

Choose an axis that matches the scientific question. A resource–quality trade-off needs both axes; a single quality bar chart cannot establish efficiency. State whether costs include preprocessing, retrieval, teacher calls, sampling or model loading.

Use log scales only when appropriate and label them. Preserve consistent scales across panels when readers will compare slopes or gaps. Explain any truncated axis. Show variability when available, and use distinguishable markers or line patterns so color is not the only encoding.

For qualitative examples, report how examples were selected. Include representative failures when they qualify the claim. A pleasing image grid is not a substitute for a controlled evaluation, and a heatmap is not by itself evidence of faithful explanation.

Make equations readable arguments

Introduce each mathematical object before using it. State the dimensions or domains when ambiguity matters. Explain what is optimized, what is fixed, and what each term contributes.

Keep notation stable between text, diagrams, pseudocode and the appendix. A method using a teacher distribution, a student distribution and a target label should not silently reuse one symbol for all three. Mark expectations, sampled approximations and stopped gradients explicitly when they change the algorithm.

Follow a substantial equation with its role in the argument. Do not restate every symbol if a concise explanation of the operation is more helpful. Derivation detail can move to an appendix only if the main text still makes the claim and its assumptions intelligible.

Use the appendix as an audit trail

An appendix is not a warehouse of unlabeled additional results. Give it an index and stable section labels that the main text can cite precisely.

Appendix module	Contents	Main-text link should answer
Definitions and proofs	Assumptions, lemmas, proof dependencies, edge cases	Where can the central guarantee be checked?
Experimental setup	Data versions, splits, preprocessing, model/configuration, seeds and hardware	Could someone reproduce this comparison?
Additional evidence	Full per-task results, sensitivity, controlled ablations, failures	Does the main finding survive alternative settings?
Resource construction	Annotation instructions, filtering, provenance, access and license constraints	How was the measurement/data created?
Prompts and evaluation	Exact prompt templates, scoring, parsing, judges and leakage controls	What exactly was the model asked and how was it scored?
Artifact map	Code revision, commands, configurations and output-to-table mapping	Which released artifact produces each reported result?

Do not move essential validity conditions, the only description of the proposed method or the central evidence out of the main paper merely to make the story look cleaner. At ICLR 2026, reviewers were not obliged to read appendices; check the corresponding policy for another edition.

Write reproducibility as navigation

An effective reproducibility statement points to the relevant methods, proof sections, configurations and artifacts. “Code will be released” does not specify the split, environment or experiment commands. A released repository also does not prove that its current revision matches the paper.

Keep a release manifest containing exact versions, artifact access conditions, restricted components, representative commands and expected outputs. If patient data, proprietary models or licensed assets cannot be released, describe the boundary honestly and provide a lawful verification path where possible.

Sentence-level clarity and style

Prefer a concrete subject and verb: “The student predicts the teacher’s normalized features” is easier to inspect than “Feature-level knowledge transfer is enabled through the utilization of…”. Use active voice when the actor matters, and passive voice when the operation or object is the useful focus. Neither is a universal rule.

Define acronyms only when they save meaningful repetition. Keep names consistent. Use parallel grammar in contribution lists. Distinguish a result (“we observed”) from a hypothesis (“we propose that”) and a guarantee (“under assumptions…”).

Avoid unsupported priority claims such as “the first” unless you can defend the literature scope. Avoid treating a model’s fluent answer as evidence of understanding without an operational test. Replace “obviously” and “clearly” with the missing reasoning when the step is substantive.

Final preflight

Scientific integrity

Every headline claim has identifiable evidence. All figures/tables agree with their source results. Negative results and limitations qualify the relevant claims. Citations point to the works they actually support. Human authors have checked AI-assisted content and complied with the edition’s disclosure policy.

Document integrity

Use the unmodified official style. Check the actual uploaded PDF for page count, clipping, fonts, equation breaks, figure labels, embedded links and bibliography completeness. Inspect at normal size and in grayscale. Compile from a clean source checkout so missing local files do not remain hidden.

Submission integrity

Confirm the correct conference, year, track and stage. Check anonymity, author metadata, supplements, artifact permissions, declarations and deadlines against official instructions. Do not assume the camera-ready formatting mode is valid for initial review.

Independent reader test

Give a colleague the title, abstract, main figure and principal table. Ask them to state the contribution, mechanism, evidence and limitation. Then ask a second reader to locate one reproducibility detail using the main text’s appendix pointers. Use their failures as revision signals, not as a reason to add more unexplained prose.