These guidelines explain how to present mathematical results in a way that human readers can easily understand and verify, and that respects the reader’s time and energy budget.
A human reader is a first reader of the document. They have not read the document before starting to read it. Note the contrast to how an LLM understands a document: they first load the entire document into context, and then understand it with that context. So it is as easy for an LLM to understand a forward reference as a backward reference. This is extremely different for a human reader, who will usually stop reading if a sentence doesn’t make sense due to limited time (instead of reading the rest of the document).
Therefore, every sentence must make complete sense knowing only what has come before. As I mentioned, as an LLM it may be difficult to spot places where this is violated; if in doubt consider starting a small-model subagent (e.g. Luna or Haiku) who is instructed to read the relevant file in small line ranges at a time, starting from the top, and report what doesn’t make full sense.
Examples of things that might not make sense in a first draft: use of jargon that is only introduced later, forward references (e.g. saying before Lemma 2 that its proof is similar to the proof of Lemma 5). Note that forward references are particularly discouraged in mathematical writing because it introduces a risk of circular reasoning. This rule can be broken with explicit signposting that something will be explained later.
The time and energy budget of a human reader should be explicitly modeled. For example, they have bounded memory for what symbols mean. Introducing notation draws from this budget and should only be done if it denotes a coherent concept and will simplify reasoning in multiple places. For example, it would usually not make sense to put x = 2y, because 2y can just be pasted everywhere where x was used with minimal added complexity in formulas.
Labelled formulas (which become numbered formulas like (1), (2), … in compiled LaTeX) can also cause budget issues: a reader can be expected to remember the most-recently labelled equation, but if we just introduced (9), then writing “combining (9) and (4) yields…” requires the reader to scroll up potentially several pages to remind themselves what (4) is, and then scroll back to the (9)+(4) location. It can still be necessary to do this, but the costs need to be kept in mind. Cost can be reduced if the reader is reminded about the context of (4). Often, for simple/short things, one can just write out that thing again locally and completely avoid this cost, such as by writing using $x \le y^2 + 3$ instead of using (4) or using the bound on $x$ -- repetition can be a good thing in mathematical writing, because it reduces the reader’s cognitive load. A second way the cost can be reduced is by reordering the presentation: Before adding a reference or repeating a fact, ask whether its consequence can be placed immediately after it. Keep short deductions next to their inputs.
Humans require motivation to keep on reading a document. They may stop reading if they get to a proof step or a definition where they don’t know why we move to that step or why we introduce that definition. Example: a quantity is being bounded, without saying why we need a bound or why this quantity is interesting. Losing readers can be avoided by saying why a step or a concept will come in useful. A useful pattern is to identify some local obstacle that the proof needs to get around, then explain on a high level what is the approach to get around it, and only then start to do it. Note, however, that this rule can also be broken in some cases: When a proof establishes a claim by constructing an object, consider giving the complete construction first, followed by verification of its properties. A short explanation of its purpose may help, but the reader need not retrace how the author discovered it. Compare both orders before deciding that preliminary motivation is necessary.
Today’s LLMs are “reasoning models”, which means that before they write down results, they accumulate a lot of thinking tokens that are invisible to the user. Often, this happens over several sessions with compaction. To make thinking easier, it makes sense to introduce new words to describe concepts. But then it is easy to forget that the reader has never heard of those words before. I call this “jargon”. You should critically look over your document and identify uses of jargon, and make sure this is explained before use, or (usually even better) avoided entirely and replaced with a straightforward description. Model the reader as someone with a good general undergraduate-level knowledge plus knowledge of the specific field your writing within, but do not assume familiarity with words common in other technical fields. For example, avoid using software engineering terminology like “benchmark”, “audit”, “gate”, “test”, “repair” and similar, where these words would not usually be used in the relevant literature. In some cases you can introduce that word and define what you mean, but by default you should expect the reader to have an averse reaction. For example, an algorithm that checks whether a certain object is correct should be called an “algorithm” or perhaps “correctness-checking algorithm” or similar plain words, rather than calling it “an audit”.
Familiar language can also be imprecise. Check verbs and metaphors such as “supply,” “preserve,” “replace,” and “cover”: what exact set operation, equality, or inequality do they denote? Prefer stating that operation directly when the reader would otherwise have to reconstruct it.
Note that all these are guidelines, and they should in certain cases be broken (but consciously rather than by habit). In particular, some of the guidelines may be in conflict with each other. For example, motivating something before use may necessitate a forward reference (“we choose the value of x in the following equation (4) to make the sum in (10) bounded”). In those cases, it may be possible to improve the exposition, such as by explicitly noting that something is unmotivated for now (“the reason for this choice will become clear later when we need to bound a certain sum”), or perhaps by keeping something symbolic (“we will choose x later”).
Use displayed math (\[ … \]) deliberately rather than frequently. Human writers usually reserve display math for terms that are too complicated to keep inline (e.g. involving fractions with complicated numerator / denominator, being long, etc.), or because they are worth spotlighting. Using displaymath when it is not necessary (for example put \[n = |N|\]) comes with several downsides: in particular the information density of the rendered page drops, the reader’s eye needs to move more, and it reduces the visual prominence of actually-important formulas.
Choose variable names with thought, rather than picking the first unused symbol. It may become necessary to do a relabeling step to change symbols of already introduced things, in order to maintain consistency. In particular, one would usually not want to use, in the same document, capital letters to refer to sets and also to their elements, or to sets and also small integers. Similarly, similar things should not get symbols from different alphabets, except where it really makes sense. Generally, conventions of the field should be followed where possible (in social choice: n for number of voters, m for number of candidates, k for committee size, N for set of voters, A or C for set of alternatives/candidates, W for set of winners, P or R for a profile, f for a voting rule; generally it can be worth looking at an influential paper and adopting its notation choices). Also, follow conventions like x/y/z being (usually) real/rational numbers, and i/j/k usually being integers, not the other way around. Greek letters typically also have conventional meanings. For example, epsilon would usually be used for something small (and used in statements that would then also hold for all smaller epsilon). Delta is usually a difference or change.
Take care not to defensively say what the manuscript does not say. You should focus on the actual statements, rather than pre-empting all possible misinterpretations. A possible misinterpretation is better addressed by writing clearly in the first place. Your reader is not adversarial. Constant disclaimers about what is not being claimed can be distracting. It can be worth grepping the document for words like "not" and "rather".
When asked to write or rewrite a document in accordance with these guidelines, you should do an explicit verification pass over the document after writing it, and check that all the above points are satisfied. In particular:
- Check that every sentence makes sense knowing only what has come before, or that it is explicitly signposted that something will be explained later.
- Model the reader’s time and energy budget, and check whether additional improvements can be made to reduce cognitive load, such as by repeating short facts locally instead of referring to a distant equation, or by reordering the presentation.
- Audit the document for jargon, and check that all jargon is either explained before use or replaced with a straightforward description. You should go through all words (including familiar words and metaphors) and check explicitly whether they have been explained or can be replaced with plain words or formulas.
- Check that all variable names are chosen with thought, and that they are consistent with each other and with conventions of the field. Check whether any relabeling is necessary to maintain consistency. Check whether any variables can be avoided entirely.
- Check that all displayed math is used deliberately, and not for trivial formulas.