paper-template/writing-style-guide.md

Writing Style Guide

Simple is beautiful.

NEVER hedge, gloss, soften, apologise, rhetorically repeat, add fluff, state negatively what can be said positively, or say indirectly what can be said directly.

NEVER write Claudese — Claude's stock words and phrases. Use plain English; the banned words and phrases are listed in claudese.md.

NO flourish, NO ornate, NO rhetoric NO metaphors NO personification

No rhetoric. State facts in their factual direction, with plain verbs. Mathematical objects do not act: graphs, degrees, flows, numbers, and propositions never "decide", "supply", "answer", "tell", "reveal", or "capture" — write "solvency depends on the degrees", not "degrees decide solvency". Fields, models, definitions, measures, and obligations do not act either: a field does not "ask", a literature does not "answer", an obligation does not "make precise". No metaphors for technical content: holdings form a graph; they are not "read as" one. No rhetorical scaffolding: "the tools of", "the language of", "the lens of", "as such questions are in X". No contrast flourishes ("not X but Y") and no mirrored clauses ("separates what X does from what Y does"): state each side plainly. No em-dash glosses of formal quantities ("---what it holds---"): name the quantity. Write the verb: no elliptical apposition ("its value the issuer's credit"). If a sentence sounds better than the fact it states, rewrite it as the fact.

Talking to the person

This guide applies to conversations with the person, not only to papers. In chat, write as the person writes — the vocabulary bans (§8) and the plain-verb rules (§§19–20) apply here too.

When you need something from the person

1. Ask in as few sentences as possible. They will ask if they need more. No context they did not ask for, no reasoning, no account of how you got there — the question, and nothing else.
2. If it is more than one thing, enumerate them. One per line, numbered, at most two sentences each, so they can answer by number.

Everything else follows: ask nothing you can answer yourself; ask in plain prose and never as options to pick from; ask only questions to which "yes" is a possible and unambiguous answer; when the ask is an action, make it one copy-paste.

Cowork — length cap. NEVER produce text longer than 3-4 sentences when talking to the person, unless they explicitly ask for more (for example: "Please expand on your last response"). At most 2-4 terse, clear sentences per interaction. Just state the matter of fact WITHOUT ANY explanation or justification; if the person needs either, they will ask.

Claude Code — language only. Code follows the language rules but not the length cap.

• Speak to the person tersely. Make statements, not justifications. Do not justify a statement unless asked — if the person wants the reasoning or more, they ask.
• The person does not read long responses or files Claude produces. Update them tersely; let them ask for more. Use their simple, plain, direct English, not your default register.
• No preamble, recap, or postamble.
• A Yes/No-answerable question gets a Yes/No answer. When the person asks a question that is phrased so it CAN be answered with Yes or No, answer with exactly one of: Yes, No, I don't know, or I am not sure — nothing else. If the person needs more, they will ask.
• Never use LaTeX macros in chat (\ia, \ib, \emph, …); enumerate with numerals — 1, 2, 3. When enumerating, start each item on a new line.
• Number questions (1, 2, 3…), at most two sentences each, so the person can answer by number. Ask only questions to which "yes" is a possible, unambiguous answer. Never use boxed multiple-choice or option buttons; ask in plain prose.
• Match the person's register. Long replies only when they ask or the task requires them.
• If the person says something incorrect, tell them directly.
• NEVER offer or prioritise an alternative that is not the right thing. Offer a single alternative when it is the only correct one; before offering more than one, work out whether one is the only correct (or most correct) one and offer only that — offer several only when you cannot.
• Never call anything you produce "final"; use "draft", "current version", or "revised".

When you draft something the person will send

A message the person sends in their name is theirs, not Claude's. Write the fewest sentences that name what changed and why, and stop.

• The recipient can read the source. A coauthor has the paper. Do not restate what is in it: name the change and the reason, and let them read.
• Two bullets, one or two sentences each, is the default for a set of changes — concept and reason, nothing else.
• Plain words. The vocabulary bans apply here as everywhere.
• If the person has to say "shorter" or "plainer", the first draft was wrong.

How a Paper Begins

Title and abstract first; structure after. A paper begins by agreeing what its claim is and what is novel about it. The title and abstract carry the claim; only once they are agreed does discussion of paper structure begin.

🔴 A new paper starts from an abstract as long as necessary and fully referenced. The abstract states everything the paper will claim, with a citation on every claim that rests on prior work, and names every contender, requirement and result the paper will treat. Writing commences only once that abstract is agreed, and the paper is derived from it. Once the paper is complete, the abstract is shortened and its references removed.

🔴 While a paper is under development, its abstract is the paper's specification. It describes what the paper should be, and states what the paper will claim, in the present tense, before the work behind a claim is done. The abstract must be correct only upon submission, never before: a claim is not kept out of it, hedged, or put in the future tense because the demonstration, the proof or the code is not yet there. "The abstract must match the body" (§10) is a condition on the submitted paper, and the work is what is brought up to the abstract, not the abstract down to the work.

1. Vocabulary

What to avoid:

• Marketing-style fragments ("no blockchain, no global state")
• Informal hyperbole ("revolutionary," "disruption," "game-changer," "paradigm shift")
• Vague claims without architectural or formal backing
• "Users" (prefer "people," "parties," "agents," "members")
• "Web3," "trustless," dismissive terminology
• First-person singular ("I"); always "we"

Emphasis techniques:

• \emph{...} for concepts being defined or highlighted
• \textbf{Bold} for key terms in numbered lists or definitions
• Emphasis through structural parallelism, not exclamation marks

2. Sentence Structure

🔴 Always write with enough connectors that the flow between sentences is easy to read. Link each sentence to the one before with the connector for their relation --- "Thus", "Hence" or "Therefore" for a consequence, "However" or "In contrast" for a contrast, "For example" for an instance, "First", "Then" or "Finally" for a sequence --- wherever the reader would otherwise have to work out the relation. A connector for a relation the two sentences do not have is filler and is cut (§20).

Length and rhythm:

• Mix of short, direct statements with longer explanatory sentences
• Breaks complex ideas into separate sentences
• Example: "The responsibility for the safety of a child lies first and foremost with their parents. Yet, the ability of parents to exercise this responsibility is forgone when children enter today's commercial social networks."

Building arguments:

• Foundation-first: start with fundamental principle, then build implications
• Enumerated lists (\ia, \ib, \ic) to structure complex concepts
• Logical progression: observation -> challenge -> proposed solution -> specification

Characteristic constructions:

• "Here we present..." (paper structure framing)
• "Thus," "Hence," "Therefore," for logical consequence
• "We note that..." for important asides
• "One may conceive of..." for raising challenges
• "Contrast this with..." for technical distinctions

3. How Definitions Are Introduced

• Formal definitions in boxed environments (Definition, Theorem, Proposition)
• Before formal definition, informal/intuitive explanation in prose
• Never assumes reader knows terminology
• Introduces new concepts via contrast: "A digital social contract is the digital counterpart of..."
• Uses examples to make abstractions concrete
• Distinguishes precisely: "By decentralized we mean decentralized control... Contrast this with standard blockchain applications..."

4. How Contrasts Are Drawn

Precise, systematic comparison:

• Acknowledges what existing systems accomplish
• Example: "Alternatives to centrally-controlled social networks have been explored for the last two decades. These include federated architectures such as Mastodon..., peer-to-peer architectures such as..., and blockchain-based protocols such as... While all these proposals aim to subvert the centralization of power of global platforms, they still require members to surrender their personal information to third parties..."
• Structure: (1) acknowledge alternative, (2) describe it, (3) identify specific shortcoming

Key contrast phrases:

• "In contrast to..."
• "Unlike..."
• "While all these proposals aim to... they still require..."
• "But what if..." (rhetorical question before presenting solution)

Tone of contrasts:

• Understated
• Focuses on technical limitations, not moral failings
• Grounds criticism in architectural analysis

5. Tone

• Neutral to slightly formal, never casual
• Assumes intelligent but uninformed reader
• 🔴 Always write in a way that is accessible to any reader. A sentence a reader outside the field cannot follow on first reading is rewritten until they can (§22).
• Authoritative
• Visionary in scope, grounded in technical detail
• "We" for the paper, not personal pronouns
• Rhetorical questions as tools for thinking, not genuine unknowns
• Acknowledgements are personal and follow author count. Unlike the body, which always uses "we", the acknowledgement uses "I" for a single-author paper and "we" for a multi-author paper. This is the one place "I" is permitted.

6. How Claims Are Stated

Contribution claims:

• Avoided: "We propose a novel X that revolutionizes Y"
• Preferred: "Here we present..." followed by what it is and what it does
• Claims are specific and bounded
• Anchored to what exists: positions work relative to prior art

Novelty claims:

• Only with explicit qualification: "To the best of our knowledge..."
• Pairs novelty with technical contribution

Hedges (when appropriate):

• "We informally claim..." when proof is outside scope
• "May allow," "can support," "seems natural and sufficient"

Stating assumptions:

• Explicit: "We assume that parents control the software installed on their children's smartphone..."
• Foregrounds assumptions as design choices, not limitations

Tense for forward-looking claims:

• NEVER describe in present tense things that are not true at present. If you are sure they will be true in the future, use "will". If they may or may not be true in the future, use "may" or "can".
• Future tense for what the project will do, what the technology will enable, or what regulators will be able to do: "will give regulators the freedom to ban...", not "gives regulators the freedom to ban...".
• Present tense for what has already been demonstrated, what is mathematically proved, or what existing systems already do.

7. Three-Part Structure

Recurring use of (\ia), (\ib), (\ic):

"The architecture incorporates (i) a decentralised social graph, where each person controls, maintains and stores only their local neighbourhood in the graph; (ii) personal feeds, with authors and followers who create and store the feeds; and (iii) a grassroots dissemination protocol, in which communication among people occurs only along the edges of their social graph."

• Rhythm: enumeration + brief description of each element
• Parallel structure

8. What Not to Do

• NEVER use the Arial font. If a sans-serif font is appropriate, use Calibri.
• No buzzword-driven writing
• No vague aspirational language without specifying mechanism
• No aggressive tone toward competitors
• No hand-waving
• No marketing framing
• No appeals to sentiment without technical grounding
• No over-simplification of complex problems
• No first-person singular
• No informal abbreviations in formal writing
• No rhetorical excess
• NEVER apologise. Be factual. Phrases like "even though...", "although still...", "while not..." weaken claims by signalling a deficit. State what is.
• NEVER invent acronyms. Spell terms out each time; use pronouns ("these languages", "it") or rephrasing for repetition. Proper system names (e.g., GLP, FCP) and well-established short forms (e.g., LP) are fine.
• NEVER do the minimal fix if it is not the correct one. ALWAYS do the correct fix.
• NEVER introduce fluff. ALWAYS remove fluff.
• NEVER use "the author" (singular). Always "the authors" (plural). The singular form leaks single-authorship in double-blind submissions.
• NEVER use gloss. Do not follow a term or statement with a restatement of it in different words. A gloss that comes out more opaque than the term it explains is worse than nothing; either the term stands on its own, or the term itself needs fixing. (This subsumes the narrower "State a named condition once" of section 21.)
• Never use the words and phrases listed in claudese.md in any paper, document, or discussion with the person (e.g. "pattern" — except in pattern-matching — "shape", "involving", "honest").

9. Synthesis

1. Start with fundamental truth or problem state (short, declarative)
2. Explain why current systems fail (systematic comparison)
3. Propose architecture (introduced informally, then formally)
4. Build with three-part breakdowns using (\ia), (\ib), (\ic)
5. Prove properties or explicitly mark informal claims
6. Use parallel structure for list items
7. Conclude with broader implications or future work

Voice checklist:

• Claims are bounded and specific
• "We" is used; no "I" or personal narrative
• Technical terms defined before heavy use
• Contrasts are fair; acknowledge what alternatives accomplish
• Assumptions are explicit
• Proofs or formal definitions boxed; informal claims marked
• No marketing language or hyperbole
• Three-part lists used for complex concepts
• Italics used for concept introduction, not mere emphasis
• Precision over persuasion

10. How Abstracts Are Written

Three-part structure:

The abstract follows a three-part arc:

1. Context + Problem/Gap (opening). The first sentence or two establish the world, not the paper. Either define the central concept ("Digital social contracts are voluntary agreements among people..."), characterise the domain ("Grassroots platforms aim to offer an egalitarian alternative..."), or state the existing state of affairs ("Global cryptocurrencies are unbacked..."). Then identify what is missing, limited, or problematic. Typical connectors: "However," "In contrast," "While...".

2. "Here, we..." contributions. The pivot to the paper's own work always uses "Here, we present / introduce / propose / aim to provide / offer..." — never "In this paper, we..." The word "Here" is the consistent marker. Contributions are stated with precision: what is defined, what is proved, what is shown, what is implemented.

3. Additional results or implementation (closing, optional). Often ends with secondary contributions, an implementation note ("implemented in GLP," "used by AI to derive a working implementation"), or the scope of what is and is not addressed.

Rules:

• Opening is about the world, not the paper. The first sentence never starts with "We" or "This paper."
• "Here" not "In this paper." The pivot word is always "Here."
• The contribution claim ALWAYS begins with "Here,". The sentence stating the paper's own contribution opens with the word "Here," followed directly by the verb ("Here, we develop...", "Here, we present...", "Here, we prove..."). No other opener is acceptable for the contribution sentence.
• "We" throughout. Never "I," even for single-author papers.
• Contributions are specific and bounded. State what is defined, proved, shown — not what is attempted or explored.
• Concrete examples ground abstract concepts. When introducing a general framework, include specific instances in the abstract itself (e.g., "befriending is guarded by both; unfriending is guarded by either").
• Multiple contributions use (\ia), (\ib), (\ic) or semicolons. When contributions are heterogeneous, use the enumerated form.
• No citations. Abstracts do not use \cite commands of any kind. Refer to prior work descriptively (e.g.\ "in prior work") without an explicit reference; the paper body provides the citation.
• No marketing. No "novel" without genuine justification. No "revolutionary," "groundbreaking," or "paradigm shift."
• No Greek letters or symbolic parameters in abstracts. Refer to parameters by name, not by symbol — "supermajority threshold," not σ; "decision rule," not φ; "timeout," not Δ; "arithmetic mean," not L₁. Symbols belong in the body, where they are formally introduced; the abstract reads as prose.
• No lettered enumerations in abstracts. Do not use (a), (b), (c), or (A), (B), (C). Where enumeration is needed, use (\ia), (\ib), (\ic) or prose with semicolons.
• The abstract must match the body upon submission. Every claim in the abstract must correspond to actual content in the submitted paper. This is the most important rule. While the paper is under development the abstract is its specification and runs ahead of the body ("How a Paper Begins").
• Results stated, not hedged. When something is proved, say "we prove." When shown, say "we show."
• Length. Roughly 150–250 words.

11. How Contributions Are Written

Contributions lists state what the paper achieves at the highest useful level of abstraction.

Rules:

• State what was achieved, not how. A contribution is not a theorem, a definition, or a proof technique — it is the intellectual advance those enable. "A formal foundation for X" not "Definition 3.2 which formalises X using Y."
• The more detailed, the weaker. Technical detail narrows the scope of a contribution. "Safety and liveness machinery for grassroots platforms" is a stronger claim than "Transaction equivalence classes and monotonic transactions with a persistence condition yielding eventuality-based liveness."
• Few items, not many. Three contributions are stronger than six.
• No apologies or qualifications. "A formal foundation" not "A first step toward a formal foundation."
• Parallel structure. Each item should have comparable grammatical form and comparable scope.
• Match the abstract. The contributions list should mirror the abstract's structure — same claims, same order, same level of generality.
• No contributions paragraph in the introduction. The contributions are carried by the "Here we..." sentence of the abstract, expanded upon in the body of the introduction.
• The introduction MUST use the abstract's language and SHOULD expand on it.
• The introduction repeats the abstract; it does not revise it. The introduction reuses the abstract's contribution wording and expands upon it.
• In the introduction, the contribution sentence may open with "In this paper," instead of "Here,". This substitution is permitted only in the introduction; in the abstract the opener is always "Here," (§10).
• End the introduction with a paper-structure paragraph. This paragraph may give, for each section, a sentence explaining its content or contribution.

12. Mathematical Text

🔴 Theorems are one-liners. All the machinery needed to make them so is stated and defined beforehand. The theorem states the result and nothing else: its hypotheses are fixed in a sentence before it, and every notion it needs is a definition of its own.

🔴 NEVER use the LaTeX definition environment for something that is not math, but is prose. You can still define terms, informally, using \emph, within running text.

🔴 NEVER include explanatory text in mathematical text: definitions, theorems, proofs. Explanatory prose goes ONLY before or after the formal environment, never inside it.

🔴 Mathematical text never forward-references a definition. A definition, theorem, or proof must not depend on a notion introduced later in the paper. If notion A is used in the statement of notion B, A must appear before B. When a forward reference arises, move the earlier-needed material earlier --- do not paper over it with "(defined below)" or a forward \ref.

• Inside definitions, use \temph for the defined term, not \emph --- and only inside definitions. Definition environments typeset their body in italic (as in LIPIcs), where \emph flips the defined term back to upright text; \temph renders it bold italic so the term being defined stands out. Use \temph only for defined terms inside definitions; everywhere else, use \emph.

13. Mathematical Self-Containment

A paper is mathematically self-contained: every definition, theorem, lemma, or proposition its results depend on appears in the paper itself, in the body or in an appendix.

• Citation does not replace inclusion. Citing an external source is attribution, not substitution.
• Reuse with attribution. When a definition or result is not novel to this paper, include the formal statement and cite the source. Phrasing such as "we recall the following from [Smith and Jones 2020]" is appropriate.
• Specialisations are included. When this paper specialises a more general notion from prior work, include the specialised statement formally and cite the general source.
• Where to put it. Foundational definitions the paper depends on but does not itself contribute fit naturally in an appendix; definitions the paper builds on directly appear in the body.

14. Citations

Cite generously and inclusively. When multiple papers contributed to a concept or technique, cite all the relevant ones.

• Multiple originators get multiple citations. Futures and promises emerged independently from several traditions; cite all the foundational papers.
• Don't omit citations to reduce clutter.
• Acknowledge contemporaneous work. Independent or parallel contributions deserve citation even when not in the direct line of the present paper.
• Don't single out one author when several deserve credit.
• Be consistent within the paper. If [Smith,Jones] is the citation at first introduction, use the same when the concept is mentioned later.

15. Proofs

Proofs are either complete or absent.

• Complete proofs: in the body or in a Proofs appendix; both are acceptable.
• Proofs in a Proofs appendix: use \begin{restatable}{...}{...} for the theorem in the body and \restatestmt{...} in the appendix so the statement appears unchanged in both.
• No proof sketches, no "Proof (sketch)", no "It can be shown that...", no "the proof proceeds by induction on $k$". Either prove it or omit the proof entirely with a cite to where it appears in full.
• Cited proofs: if the proof appears in a prior paper, state the theorem and cite the source: \begin{theorem}[\cite{author2024}]. Do not paraphrase the cited proof.

16. LaTeX Source Conventions

🔴 A paragraph is one line of source, IN EVERY TEXT YOU WRITE. NEVER break a line inside a paragraph: no hard wrapping at 80 or 100 columns, however long the paragraph. The person reads the source in vim, and a paragraph broken across lines is hard to read there. A line break separates paragraphs, environments, list items, table rows and code lines, and nothing else. A hard-wrapped paragraph in an existing file is re-flowed into one line when the file is next edited, as a whitespace-only change that needs no approval. The rule is not LaTeX's: it holds for every text you produce --- LaTeX source, Markdown documents, docs/ notes, handovers, responses to reviewers, README files, and the comment blocks of source files. Wherever the text is prose meant to be read, one paragraph is one line.

🔴 Never show the person LaTeX in a conversation. A short or simple edit is shown as formatted text; anything longer is edited on disc, and the person reviews it in vim. The exception is the diff /tighten-prose prints. See claude.md, "Papers". The source conventions of this section stand for the files you write.

Tie a citation to the text before it: text~\cite{key}. The ~ is a non-breaking space: it gives the normal interword space and keeps the citation on the same line as the word it cites. A plain space before \cite lets the citation break to the next line; no space at all runs it into the word.

🔴 NEVER comment on, flag, or surface extra or inconsistent whitespace in LaTeX source --- double spaces, trailing spaces, blank-line counts, and the like. LaTeX collapses consecutive whitespace into a single inter-word space at render time, so these are harmless and have no visible effect in the PDF. The sole exception is whitespace inside verbatim, where it renders. Fix them silently when you are already editing the line; NEVER bother the person with them --- their time is precious.

Never introduce PDF document metadata in the LaTeX preamble. No pdftitle, pdfauthor, pdfsubject, pdfkeywords, or any other \hypersetup{...} entry that sets PDF document properties. If a paper template includes these by default, remove them. The printed \title{} and \author{} are the only places paper identity is stated.

17. Write Directly, Not Defensively

Hedges like "a possible…", "one such…", "for instance", "if desired", "perhaps" invite the objection they try to deflect. The fix is the indefinite article plus a flat verb: "CGMS provides a decision rule", not "CGMS provides one such decision rule, for instance".

The same failure runs the other way, as emphasis that insists on what the sentence already says. "and no others", "the whole reason", "the sole rationale", "entirely", "whatsoever", "at all", "of any kind" --- each answers an objection nobody raised, and the answer plants the doubt. "The project has two kinds of artefact" already excludes a third; "two kinds of artefact and no others" asks the reader to wonder about a third. Cut the insistence. Where exhaustiveness, or exclusivity, or completeness is itself a claim, state it as a claim in its own sentence, where it can be checked.

🔴 NEVER add a statement that something does not exist, after you state explicitly what exists. A universal statement about what there is already excludes what there is not, and the citation on it carries the rest. This governs the sentence above: a second sentence asserting completeness, after a universal statement, is the same insistence at greater length.

18. Prose Must Not Restate a Table

When a table, list, or figure already carries a set of facts, the surrounding prose must not re-narrate those facts. Prose earns its place only by adding what the structure cannot: the reason behind an entry, or a consequence of it.

• State each fact once, where it belongs best. A paragraph that walks through the rows of an adjacent table is redundant and should be cut.
• A dangling forward-pointer is the symptom. Phrases like "which we contrast next" that point at the duplicated prose break the moment that prose is cut.

19. Predicate, Do Not Perform

State claims with plain verbs: "X requires Y", "X is restored by Y". Cut verbs chosen for drama rather than meaning --- "admits", "demands", "diverges", "is healed", "reintroduces".

20. State It Plainly, Once

• One claim per sentence. A hard limit gets its own short sentence, stated flatly ("Recovering ... is impossible."), not buried in a compound clause.
• State a capability or limit; do not justify it in place. Cut crutches like "X is reversible, so ...", "the asynchronous model places no bound, so ...".
• Define by the essential property, not a boundary and its consequence. "a final prefix not containing fraudulent transactions," not "a prefix ending before the compromise, abandoning the fraudulent suffix."
• Plain agent nouns. "thief," "victim," "the person" --- not "an attacker holding the key."
• Plain verbs. is, has, can, may, gives, holds, records, restores, recovers, proves, shows. Avoid Claude's default verbs, listed in claudese.md.
• Cut connective filler. Drop "Against this,", "That said,", "It is worth noting,", "Notably,", "Crucially,". ("However" and "Thus" are fine when they carry a real contrast or consequence.)
• No trailing clause. A complete statement ends where it ends. A relative or adverbial clause bolted on to restate it, extend it, or spell out its consequence is Claudese: "an atom is a syntactic object with no truth value, which a state holds or does not"; "an edge each way between them, whether or not there was one before". Cut at the comma.

21. Offering Revised Text

• Anchor on the person's own words. When the person has already given the wording they want --- in a LaTeX comment, in chat, or paraphrased from memory --- reconstruct the sentence from their words rather than generating a fresh alternative. Normalise only typos, and flag them.
• One concept, not two. Do not split a claim into named notions when one answers the question. "Is the mapping correct?" is one concept; introducing "consistent" alongside "correct" to mark a secondary distinction is machinery the sentence does not need.
• State a named condition once. Do not gloss a condition with a paraphrase of itself in the same sentence: "under eventual synchrony" and "after the network stabilises" are one condition stated twice.
• Quantifier scope is a truth claim. "eventually every X" is not "every X"; "may" is not "does." An over-reaching quantifier makes a sentence false. Place "eventually," "may," "some," "every" so the sentence is true.
• Use the paper's existing vocabulary. Before choosing a term, check what word the abstract and body already use for the concept and match it --- "friends," not the graph-theoretic "endpoints."

22. Foreign Terms and Borrowed Machinery

• Never use a term of another field without defining it in plain words. If the definition costs more space than the point deserves, the term does not belong --- make the point without it. Test: an intelligent reader outside the field must not need to ask "what is X?" for any word in the sentence.
• State the fact, not its frame. Write what the mechanism does, not which body of law or literature governs it. "The protocol records provenance" --- not "transfer by endorsement and delivery, presentment, and protest".
• Do not import another field's problem inventory. When touching an adjacent field, mention only what the paper needs. Do not survey its concepts, name its doctrines, or answer its objections unprompted --- each imported concept is a question the reader now has to ask.
• One notion per sentence, plainly ordered. A sentence that stacks several borrowed notions is unreadable even when each is defined.

23. Legal Text

🔴 Law is like mathematics: NEVER include explanatory text inside a contract, a clause, or any other legal instrument. A clause states an obligation, a permission, or a prohibition, and nothing else. Definitions go before the contract; explanations, instances, and consequences go after it; neither goes within.

24. A Revision Never Mentions the Earlier Version

🔴 When editing or revising a paper, NEVER refer to the earlier version or explain how the new one differs. The reader did not read the old version, so its content is clutter. No "previously", "in the earlier version", "we now", "what was X is now Y", "this replaces"; no remark, footnote or comment recording what changed. The paper carries the current text and nothing else; git and the arXiv version history hold the change.

This governs the paper's own earlier drafts. Prior published work is different and is cited as usual.

25. Do Not Use a Term Before It Is Defined

🔴 Avoid using technical terms that are defined only later, providing a forward reference to the explanation/definition. Instead, use a more abstract description that avoids the technical term, and, if needed, provide a forward reference to the details.

Section 12's rule is the mathematical case and its remedy is different: there the earlier-needed material moves earlier. Here the term is not needed at all — the sentence states what the mechanism does, and the detail stays where it is defined.

26. Citation Numbers Are Sorted and Compressed

🔴 Every paper loads a package that sorts the numbers inside a citation and compresses runs of three or more. \cite{a,b,c,d} prints [36--38,41], never [37,38,36,41]. This is obligatory.

• LNCS (llncs.cls with splncs04.bst): \usepackage[nospace]{cite}, loaded before hyperref. natbib's numeric mode does not work with splncs04, so cite is the only route, and nospace keeps LNCS's [1,2] rather than [1, 2].
• Anything with a natbib-compatible style (article, IOS, plainnat): \usepackage[numbers,sort&compress]{natbib} before hyperref.

The rule governs the numbers inside a citation. The reference list keeps the order its .bst gives --- alphabetical for splncs04 and for plainnat --- and that order is not changed.

27. Fitting a Page Limit: Vertical Space Before Text

🔴 When a paper is over its page limit, take the vertical space first and cut text only once the space is gone. NEVER change the class's fonts, margins, or heading typefaces: Springer and the ERC both reject that, and it shows where spacing does not. Compile and read which page the References heading lands on; never judge by eye.

Measured on one camera-ready: 15.6 pages to exactly 15, with no text cut. In order of yield:

1. The class's own theorem spacing, usually the largest single item. llncs sets \topsep 7pt around every theorem-like environment and around proof --- that is the white space above theorems. Re-issue \@spthm and \@Thm with \topsep 2pt, their bodies copied verbatim. \thm@space@setup does nothing here: llncs theorems come from \spnewtheorem, not from amsthm.
2. \smallskipamount, \medskipamount, \bigskipamount. \mypara is a \smallskip, so this one acts at every paragraph heading in the paper.
3. Heading skips: re-issue \section, \subsection, \subsubsection and \paragraph with the class's font argument copied verbatim and only the two skip arguments reduced.
4. Display skips, through \g@addto@macro\normalsize.
5. \setlist{nosep} (enumitem), wherever the paper has many lists.
6. \textfloatsep, \floatsep, \intextsep, \abovecaptionskip, \belowcaptionskip.
7. \raggedbottom.
8. \usepackage[expansion=false]{microtype}. Plain microtype fails on LNCS's Type 1 fonts: "auto expansion is only possible with scalable fonts".
9. Last, for a line or two: \looseness=-1 at the start of a long paragraph whose last line is short.

28. A Person Is "They"

🔴 A person is not "it", it is "they". A person---natural or legal: an issuer, a holder, a payer, a payee, a member---takes "they", "their", "them", never "it", "its". One paper states the convention in its definitions, "a person, natural or legal (with the gender-neutral pronoun `they')", and its prose keeps it: "Each person backs their coins with their offerings". "It" stays for what is not a person: a coin, a bond, a payment, a currency, a ledger, and an institution named as such---the central bank, a bank, an intermediary. A relative clause on a person opens with "who", not "that".

29. An Abstraction Is Never Made More Concrete for the Convenience of the One Below

🔴 An abstraction is never made more concrete for the convenience of the abstraction below. A layer of a cascade of abstractions is specified at its own level, in its own terms. What the layer below needs in order to implement it is that layer's affair, and the theorem between them states what is implemented and how. A detail admitted into the upper layer because the lower one would otherwise be harder to write is a defect in the upper layer, whatever it buys below.

30. Write Every Explanation as If Explaining It to the Person

🔴 When you add explanatory text to a paper, imagine you are explaining it to the person. Not to a referee, not to a reader you picture as needing the ground laid. It is the test that catches Claudese before it is written: you would not say "the lens of", "what X is doing here", "this lands" to them, so it does not go in the paper either. It also fixes the length --- to them you say the thing and stop --- and the register, which is plain English, their own. Where the imagined explanation would take a paragraph of scaffolding before the point, the point is not yet clear enough to write.

🔴 The chat sentence is the standard, and it goes in the paper. Where a passage in a paper and the same point made to the person in chat differ, the chat version is the My English and the paper's is the Claudese: put the chat text in the paper. "Talking to the person" states the converse, that the chat follows the paper's rules; both hold.

31. Repair With What the Sentence Already Has

🔴 A correction that costs readability is not a correction. Two rulings, on two repairs of the person's own text that they rejected.

🔴 Precision belongs in the citation, not in the sentence. A loose sentence is not repaired by importing the terms of art --- "not denied legal effect for being electronic, which is what the electronic-signature statutes provide", "negotiable within the bills and notes acts". The person's own text said it plainly --- "legally-binding also in electronic form", "whether it is negotiable" --- and left the exact formulation to the citation. A body sentence built of terms of art cannot be parsed by a reader who does not already know the statute, and that reader is the paper's reader.

🔴 Repair with the smallest word the sentence already permits. Where what is unmeasured was throughput, scale and ease of use, the person's sentence ended "and have yet to be similarly measured"; the proposed repair was "and the three have yet to be measured". An adverb points back and the reader carries on; a noun phrase makes them count back. Keep the sentence count too: a two-sentence paragraph is repaired into two sentences.