Work nobody can follow has not landed

A result nobody can follow does not count, and in practice most readers see the title, the abstract and the figures and nothing else. This section is about writing for that: a structure that gets the contribution across early, figures that carry the argument rather than decorate it, precision about what was shown as against what is merely suggested, and stating the limitations yourself before a reviewer states them for you.

Most readers read three things#

Title, abstract, figures. Write as though that is all anyone will see, because for most readers it is. If the contribution is not clear from those three, it will not be clear at all.

The consequence for the title is the one people resist. A title is not a label for a topic; it is the only sentence most people will ever read of your work, so it should be the claim. Three titles for the same paper, in increasing order of how much they do:

weak     On Chunking Strategies for Retrieval-Augmented Generation

better   A Comparison of Six Chunking Strategies for Retrieval-Augmented
         Generation

strong   Chunk Boundaries Matter More Than Chunk Size

The usual objection is that a claim as a title overstates. It does not, if the claim is the one your experiment supports; what overstates is a claim broader than the evidence, which is a separate problem with a separate fix, below. A title that names the finding also does something quietly useful for you: if you cannot write one, you do not yet know what you found, and that is better discovered before the deadline than after.

Structure#

1. 1.What problem, and why it matters.
2. 2.What has been tried, and what is missing.
3. 3.What you did.
4. 4.What happened, with numbers.
5. 5.What it means, and what it does not.

Each of those has a one-line test, and running the five tests is faster than re-reading the draft. Can a reader say who is worse off because this problem is unsolved? Does the second part name a specific thing that was tried and what it failed at, rather than listing citations? Could a competent stranger reimplement the third? Does the fourth contain a number with an uncertainty attached to it? Does the fifth name a condition under which the result would not hold? A draft that fails one of these fails it in a specific place, which is much easier to fix than a draft that merely feels unclear.

The order matters more than it looks, because it is the order in which a reader grants you credit. A reader who does not accept that the problem is real reads your method as effort spent on nothing. One who accepts the problem but not the gap assumes you have not read the literature. Each part is a precondition for the next being read at all, which is why a paper that is strong in the middle and weak at the start reads as weak throughout.

Figures#

A figure should make its point without the caption, and the caption should make it without the body text. Label axes with units, show variance, and do not truncate an axis to make a difference look larger than it is.

Before any of that comes a harder question: which figure. Most papers have one figure that carries the argument and several that document things, and they are usually given the same size and the same care. Decide which one is load-bearing by asking what a reader would have to see in order to believe your central claim. Make that one first, put it on the first page if the format allows, and design the others to support it rather than compete with it.

Axis truncation deserves a concrete example, because it is usually done innocently. Two methods score 0.71 and 0.78. Plotted from zero, the bars differ visibly and the difference looks like what it is, about a tenth. Plotted from 0.70, the second bar is eight times the height of the first, and a reader skimming carries away an impression of a transformation rather than of seven points. Nothing in the figure is false and the axis is labelled. It is still misleading, and a reviewer who notices will apply that suspicion to every other number you report.

Be precise about the claim#

Overclaimed:  "Our method improves reasoning."

Precise:      "Our method improves accuracy by 3.2 points on
               GSM8K with a 7B model, averaged over five seeds.
               We did not test other model sizes or benchmarks."

Those two are not a pair of options, they are the ends of a ladder, and the job is to find the highest rung your evidence actually reaches and stand on it. Here is one experiment claimed at five strengths, with what each rung would require.

5  "Our method improves reasoning."
     would need several reasoning benchmarks, several model families and
     more than one scale. You ran none of that.

4  "Our method improves mathematical reasoning in language models."
     would need several maths benchmarks and at least two model families.

3  "Our method improves GSM8K accuracy for 7B models."
     would need several different 7B models, and a reason to think the
     parameter count is the thing that matters.

2  "Our method improves GSM8K accuracy for Llama-3-8B by 3.2 points,
    averaged over five seeds (sd 0.6)."
     needs exactly what you ran. This is your rung.

1  "Our method scored 3.2 points higher than the baseline on our run."
     needs nothing, and is too weak: it declines to generalise at all,
     so a reader cannot use it for anything.

The failure that costs most is not writing rung five instead of rung two. It is writing rung five in the abstract and rung two in the results, which most papers with an overclaim actually do. A reviewer reads both, notices the paper contradicting itself, and now has to decide which version the authors believe. That is a much worse position than having claimed too much consistently, because it looks like the broad claim was chosen knowing it was not supported.

That only works if the limitations are real. A limitations paragraph is the easiest place in a paper to perform rigour without having any, and reviewers read hundreds of them, so the generic ones are recognised instantly. Three that appear constantly, and what each becomes when it is meant:

empty   "Our results may not generalise to all settings."
real    "All four collections are English technical documentation.
         We expect the gain to shrink on prose without headings,
         because the method keys on section boundaries."

empty   "Future work could explore larger models."
real    "We tested 7B and 8B models only. The mechanism we propose
         predicts a smaller gain at larger scale, since stronger
         models recover more from a bad chunk; we could not test
         this."

empty   "Our evaluation has some limitations."
real    "Answers were graded by one model-based judge, validated
         against 200 human labels at kappa 0.71. Disagreements were
         concentrated in multi-hop questions, so the multi-hop
         numbers in Table 3 are the least reliable in the paper."

The test for a limitation is whether it costs you something to write. If naming it does not narrow any claim you made, it is decoration. The three above each give something away: the first restricts the domain, the second concedes that the effect may be an artefact of scale, and the third tells a reader which table to trust least. That is why they buy credibility, and why the empty versions buy none.

The same discipline at work#

This transfers directly to engineering. A design document that states the problem, the options, the choice and its limitations is persuasive for the same reasons, and technical influence largely runs through writing.

The mapping is close enough to write down. A design document is the same five parts with different names, and it has the same failure mode: most of them are written as advocacy for a decision already made, which senior readers detect and discount.

paper                          design document

problem, and why it matters    what is broken now, and what it costs
                               per week in money, incidents or hours

what has been tried            what we do today, and the specific
                               thing it cannot do

what you did                   the proposal, concrete enough to
                               estimate

what happened, with numbers    the evidence: a prototype, a
                               measurement, a load test, a cost model

what it means and does not     what this does not fix, what we are
                               betting on, and what would make us
                               reverse it

The other borrowing worth making is the alternatives section. A paper that does not say why the obvious approach fails reads as unaware of it; a design document that does not say why the boring option was rejected reads as someone who wanted to build the interesting one. Write the two or three alternatives you did not choose, with one sentence each on the condition under which each would have been right. A reader who agrees with one of those conditions will now tell you, which is the entire point of circulating the document before building anything.