systems-paper-writing

Sentence 1: Problem context and importance
Sentence 2: Gap in existing approaches
Sentence 3: Key insight or thesis ("X is better for Y in environment Z")
Sentence 4: Summary of approach and key results
Sentence 5: Broader impact or availability

Source: Levin & Redell — "Can you state the new idea concisely? Use them in the abstract." Irene Zhang — "The abstract is harder to write because you cannot use terms or concepts you introduced in the paper."

Paragraph structure:

1. Problem statement (~0.5 page) — Establish the domain and why it matters. Use concrete numbers (cluster sizes, workload statistics, latency requirements).
2. Gap analysis (~0.5 page) — Enumerate specific gaps G1–Gn in existing systems. Each gap is one sentence with evidence.
3. Key insight (1 paragraph) — The thesis statement: "X is better for applications Y running in environment Z." (Irene Zhang formula)
4. Contributions (~0.5 page) — Numbered list of 3–5 concrete contributions. Each contribution is testable and maps to a section.

Writing pattern: hzwer Move 1 (Establish territory) → Move 2 (Find niche) → Move 3 (Occupy niche).

Source: Irene Zhang — "clearly state your target environment (Z) and application (Y)" + "clearly state why previous systems do not meet the needs"; Levin & Redell — "What exactly is the problem being solved?"

Paragraph structure:

1. Technical background (~0.5 page) — Define terms and systems the reader needs. Follow Gernot Heiser's "define-before-use" principle.
2. Production observations (~0.5–1 page) — Present Observation 1, 2, 3 from real data or measurements. Each observation leads to a design insight.

Source: Irene Zhang — "clearly motivate Y and Z. Why is application Y important?"; Gernot Heiser — "define-before-use."

Paragraph structure:

1. System architecture overview (~0.5 page) — Architecture diagram first (Yi Ding: "draw a picture first"). One-paragraph walkthrough of major components and data flow.
2. Module-by-module design (~2–2.5 pages) — Each subsection: what the module does, the design choice made, alternatives considered, and why this choice wins.
3. Design alternatives and trade-offs (~0.5–1 page) — For each major decision, explicitly discuss what was not chosen and why.

Source: Irene Zhang — "Every design choice made in X should be discussed with alternatives and the reasons for the choice"; Levin & Redell — "What were the alternatives considered at various points, and why were the choices made?"

1. Prototype description — Language, framework, LOC, integration with existing systems.
2. Key engineering decisions — Non-obvious implementation choices worth documenting.

Source: Levin & Redell — "Does the paper describe something that has actually been implemented?"; Irene Zhang — "explain how you constructed a prototype to test your hypothesis."

Paragraph structure:

1. Experimental setup (~0.5 page) — Hardware, baselines, workloads, metrics. Enough detail to reproduce.
2. End-to-end comparison (~1–1.5 pages) — X vs baselines for application Y on environment Z. Main performance results.
3. Microbenchmarks / Ablation (~1–1.5 pages) — Isolate each design decision's contribution. Ablation experiments decompose the gains.
4. Scalability (~0.5 page) — Show behavior as problem size, cluster size, or load increases.

Critical rule (Irene Zhang): State every experimental conclusion three times:

• Section opening: hypothesis ("We expect X to outperform Y because...")
• Section closing: conclusion ("Results show X outperforms Y by Z%")
• Figure caption: evidence ("Figure N shows X achieves Z% better throughput than Y")

Two experiment types:

• Type 1: X vs baselines for Y on Z (end-to-end comparison)
• Type 2: Ablation — remove each design component to measure its individual impact

• Group by methodology or approach, not by individual papers.
• For each group: what they do, what limitation remains, how your work differs.
• Use a comparison table when comparing 4+ systems on specific dimensions.

Source: Levin & Redell — "Are comparisons with previous work clear and explicit?"; Irene Zhang — use comparison tables.

Three sentences (Irene Zhang formula):

1. The hypothesis / problem addressed
2. The solution approach
3. The key result

Enumerate gaps G1–Gn in Introduction → map to answers A1–An in Design. Creates a clear contract with the reader.

Present production observations (O1–O3) in Motivation → derive design insights → build system around insights. Effective when you have real workload data.

Numbered contributions in Introduction, each mapping to a section. Readers (and reviewers) can track claims through the paper.

Structure the entire paper around: "X is better for applications Y running in environment Z." Introduction states it, Design explains how, Evaluation proves it.

Treat the reader's cognitive load like an OS managing process state. Never introduce a concept without context. Never reference something defined later without a forward pointer.

Self-check against: Original Ideas, Reality (is it built?), Lessons (what did you learn?), Choices (alternatives discussed?), Context (related work fair?), Presentation (clear writing?).

Include a figure on the first page that captures the core idea. Reviewers form first impressions from the title, abstract, and page-one figure.

• Never generate citations from memory. Use ml-paper-writing's citation verification workflow (Semantic Scholar / DBLP / CrossRef APIs).
• Mark unverified references as [CITATION NEEDED].

• Do NOT fabricate production observations, traces, deployment experiences, or experimental results.
• Do NOT generate fake venue rules, paper metadata, or best-paper claims.
• Do NOT copy paragraph-level text from reference papers. This blueprint provides structural guidance, not copy-paste templates.

• Some venues require disclosure of substantial LLM use in writing or ideation. Check each venue's AI policy in the current CFP.

• When structures are inspired by specific papers (e.g., Lucid's gap-analysis pattern), cite the inspiration.
• Cross-repository references (e.g., ARIS paper-slides structure) are attributed, not copied.

• Venue rules (page limits, format, AI policies) change annually. All venue information in this skill is based on 2025/2026 CFPs. Always verify against the current year's CFP.

• Thesis statement follows "X is better for Y in Z" formula
• Introduction has numbered contributions (3–5)
• Each contribution maps to a paper section
• Design discusses alternatives for every major choice
• Every eval conclusion stated 3 times (hypothesis, result, caption)
• Related work grouped by methodology, not individual papers
• Page budget within venue limits
• All citations verified programmatically (no hallucinated references)

• references/section-blueprints.md — Detailed per-section paragraph templates with authoritative source quotes and best-paper structural examples
• references/writing-patterns.md — Four writing patterns with concrete paper examples

• references/checklist.md — 7-stage pre-submission checklist covering structure, writing quality, evaluation rigor, design quality, academic integrity, venue-specific requirements (OSDI/NSDI/ASPLOS/SOSP/EuroSys), and final pass
• references/systems-conferences.md — Conference overview, deadlines, track descriptions, formatting requirements, submission rules, and format conversion guides
• references/reviewer-guidelines.md — How systems conference reviewers evaluate papers, with venue-specific criteria and common concerns

• templates/osdi2026/ — OSDI 2026 (USENIX format)
• templates/nsdi2027/ — NSDI 2027 (USENIX format)
• templates/asplos2027/ — ASPLOS 2027 (ACM SIGPLAN format)
• templates/sosp2026/ — SOSP 2026 (ACM SIGPLAN format)