sosp-writing-style

name	sosp-writing-style
description	Use when drafting or revising SOSP prose — leading with a design principle rather than a feature list, building the intro's problem-to-insight arc, budgeting 12 dense two-column pages across design and evaluation, writing figures that argue, and keeping claims inside what the measurements support.

SOSP Writing Style

Use this at drafting and revision time for a SOSP paper. The format constants (2026 cycle, checked 2026-07-08 against the official author guidelines): at most 12 pages of technical content in submission, 10-point font on 12-point leading, a 7 x 9 inch text block in two columns, references uncounted. Those pages are read first by a skeptical fast pass and later defended live at a PC meeting — the prose must arm an advocate, not just inform a reader.

Lead with the principle, not the artifact

The recurring identity question at this venue is "what is the principle?" A SOSP paper is remembered as an idea with a system attached, not a system with features attached. Concretely:

• Somewhere on page one, a sentence must exist that survives extraction: the insight, stated so a PC member can repeat it at the meeting without the paper open ("crash consistency can be delegated to the allocation layer because ...").
• Feature-list intros ("we present X, which supports A, B, and C") read as workshop papers. Replace the list with the tension the design resolves.
• If the honest one-sentence version is "we engineered X to be faster", the routing question comes before the writing question (see sosp-topic-selection).

The first-page arc

Move	Job	Symptom when missing
Problem, concrete	Reader can picture the failing scenario	Intro opens with a market-size claim
Why existing systems fail	The gap is structural, not un-tried	Related work reads as the real intro
Insight	The extractable principle	Reviewers summarize the paper differently from you
Embodiment	The system, named, one paragraph	Insight floats with no evidence anchor
Headline evidence	2-3 measured numbers with baselines named	"Extensive experiments show"
Honest scope	One clause on what the design gives up	The meeting discovers the limitation for you

Budgeting twelve dense pages

A workable allocation for a design-plus-evaluation SOSP paper; deviate deliberately:

Intro + motivation          1.5 pp   the arc above, plus the motivating measurement
Design                      4.0 pp   principle -> mechanisms; invariants stated inline
Implementation              1.0 pp   what was built, LoC, what is borrowed vs new
Evaluation                  4.0 pp   claims mapped to experiments (see sosp-experiments)
Related work                0.75 pp  positioning, not survey (see sosp-related-work)
Discussion + conclusion     0.75 pp  limitations owned, generality argued
(references                 uncounted — never starve them)

When over length, cut prose before leading or figures: geometry tampering is a desk-reject at this venue, and shrunken figures cost more reviewer goodwill than a trimmed subsection. Move depth (full proofs, extra sweeps) to the supplement, never review-critical evidence (see sosp-supplementary).

Figures that argue

Systems reviewers read figures before prose on the fast pass. Each figure earns its column-inches by making a claim on its own:

• Caption states the takeaway ("Recovery replays only the log tail; time is flat in log size"), not the axes ("Recovery time vs. log size").
• Baselines appear in the figure, labeled with the same names the text uses.
• Distributions for tail claims: a p99 bar with no spread is an invitation to a soundness attack.

Register and claim discipline

• Present tense, active voice, the system as subject: "Foo batches acknowledgments" beats "acknowledgments are batched by our approach."
• Every superlative is a target at the PC meeting. "Fast" is free; "faster than Bar on write-heavy YCSB by 2.1x" is defensible; "optimal" had better come with a proof.
• Anonymized self-reference in third person throughout — the double-blind rules reach into style ("the Foo paper showed", not "we previously showed").
• Define each invariant once, name it (I1, I2 ...), and cite the name thereafter; the response phase will need those anchors when a review misstates one.

# Weasel-word and overclaim sweep before the freeze
pdftotext main.pdf - | grep -inE 'significant(ly)? (improve|outperform)|extensive experiments|novel(ty)? |clearly|obviously|optimal' | head -20

Revision protocol

1. Extract the paper skeleton: first sentence of every paragraph, read in order. If the skeleton does not carry the argument, restructure before polishing.
2. Give the draft to a systems reader for a strict 15-minute pass — abstract, intro, figures, conclusion — and ask them to state the principle. Wrong answer means a page-one problem, whatever they say about section 4.
3. Only then line-edit for density: merge stub paragraphs, collapse enumerations that repeat their lead-in, delete signposting that restates section titles.

Output format

[Principle] extractable one-liner found on page one? <quote it>
[Arc audit] problem / gap / insight / embodiment / evidence / scope — which missing
[Budget] section page allocation vs the 12-page plan
[Figures] each figure's caption-claim; baselines in-figure?
[Claim sweep] overclaims found -> defensible rewrite
[Skeleton verdict] argument carries on first sentences alone? <yes/no>