Writing Systems Papers

Writing Systems Papers: Paragraph-Level Structural Blueprint

Fine-grained structural guidance for writing 10–12 page systems papers targeting top systems venues: OSDI, SOSP, ASPLOS, NSDI, and EuroSys. This skill provides page allocation per section, paragraph-level blueprints, and writing patterns distilled from authoritative guides and best-paper analysis.

When to Use This Skill

Boundary: ml-paper-writing provides general writing philosophy, multi-venue templates, and citation verification. This skill focuses exclusively on paragraph-level structural blueprints for systems conferences.

---

Authoritative Sources

This blueprint synthesizes guidance from established systems researchers:

1. Levin & Redell — "How (and How Not) to Write a Good Systems Paper" (SOSP'83 PC Chairs, USENIX/ACM SIGOPS) 2. Irene Zhang (MSR/UW) — "Hints on how to write an SOSP paper" (SOSP/OSDI PC) 3. Gernot Heiser (UNSW, seL4) — Style Guide + Paper Writing Talk 4. Timothy Roscoe (ETH Zürich) — "Writing reviews for systems conferences" 5. Mike Dahlin (UT Austin/Google) — "Giving a Conference Talk" 6. Yi Ding — "How to write good systems papers?" 7. hzwer & DingXiaoH — WritingAIPaper (GitHub 1.3k+ stars)

Full citations and URLs: see references/section-blueprints.md.

---

12-Page Systems Paper Blueprint

Overview: Page Allocation

Abstract (150–250 words, 5 sentences)

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."

S1 Introduction (1.5–2 pages)

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?"

S2 Background & Motivation (1–1.5 pages)

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."

S3 Design (3–4 pages)

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?"

S4 Implementation (0.5–1 page)

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."

S5 Evaluation (3–4 pages)

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

S6 Related Work (1 page)

• 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.

S7 Conclusion (0.5 page)

Three sentences (Irene Zhang formula): 1. The hypothesis / problem addressed 2. The solution approach 3. The key result

---

Writing Patterns

Four reusable patterns for structuring systems papers. See references/writing-patterns.md for detailed examples.

Pattern 1: Gap Analysis (Lucid, ASPLOS'23)

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

Pattern 2: Observation-Driven (GFS, arXiv 2025)

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

Pattern 3: Contribution List (Blox, EuroSys'24; Sia, SOSP'23)

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

Pattern 4: Thesis Formula (Irene Zhang)

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

---

Conference Differences

Warning: Venue rules change yearly. Always verify against the current year's CFP before submission.

Based on 2025/2026 CFPs. Verify current limits before submission.

---

Writing Philosophy

Manage Reader State (Gernot Heiser)

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.

Six-Dimensional Quality (Levin & Redell)

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

Page-One Figure (hzwer)

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

---

Academic Integrity Requirements

Citation Discipline

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

Prohibition of Fabrication

• 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.

LLM Disclosure

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

Attribution

• 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.

Temporal Validity

• 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.

---

Workflow: Structuring a New Systems Paper

Step 1: Read this SKILL.md for page allocation overview
Step 2: Read references/section-blueprints.md for per-section paragraph templates
Step 3: Choose a writing pattern from references/writing-patterns.md
Step 4: Draft section by section following the blueprint
Step 5: Run the checklist from references/checklist.md before submission
Step 6: Use ml-paper-writing for citation verification and LaTeX formatting

Quick Checklist

• [ ] 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)

---

Common Issues and Solutions

---

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 — Pre-submission checklist combining community resources and academic integrity verification

Pre-Submission Checklist for Systems Papers

Comprehensive self-check before submitting to OSDI, SOSP, ASPLOS, NSDI, and EuroSys. Combines community best practices (MLNLP-World/Paper-Writing-Tips, RU-System/Paper_Writing_Tips) with systems-specific and academic integrity checks.

---

Stage 1: Structural Completeness

Thesis & Contributions

• [ ] Paper has a clear thesis statement: "X is better for Y in Z"
• [ ] Thesis appears in Abstract (sentence 3), Introduction, and Conclusion
• [ ] Introduction lists 3–5 numbered, testable contributions
• [ ] Each contribution cross-references a paper section (§N)
• [ ] Each contribution is verified by an experiment in §5

Section Presence

• [ ] Abstract: 150–250 words, self-contained (no undefined terms)
• [ ] Introduction: Problem → Gap → Insight → Contributions
• [ ] Background/Motivation: Technical terms defined before use
• [ ] Design: Architecture figure + module details + alternatives
• [ ] Implementation: Language, LOC, framework, key decisions
• [ ] Evaluation: Setup + end-to-end + ablation + scalability
• [ ] Related Work: Grouped by approach, explicit differentiation
• [ ] Conclusion: 3-sentence summary (problem, solution, result)

Page Budget

• [ ] Total pages within venue limit (see venue table in SKILL.md)
• [ ] Design section: 3–4 pages (not overlong)
• [ ] Evaluation section: 3–4 pages (not underweight)
• [ ] Related Work: ~1 page (not a bibliography dump)
• [ ] Implementation: 0.5–1 page (concise)

---

Stage 2: Writing Quality

Clarity (Gernot Heiser)

• [ ] No forward references without explicit pointers ("as we show in §N")
• [ ] Every acronym defined on first use
• [ ] No orphan terminology — every technical term defined before use
• [ ] Consistent naming: system name capitalized uniformly throughout
• [ ] Active voice preferred over passive where possible

Figures & Tables (MLNLP-World/Paper-Writing-Tips)

• [ ] Every figure/table referenced in text before it appears
• [ ] Figure captions are self-contained (readable without text)
• [ ] Evaluation figure captions include the key finding
• [ ] Architecture figure appears within first 3 pages
• [ ] Fonts in figures ≥ 8pt (readable when printed)
• [ ] Colors distinguishable in grayscale (for B&W printing)
• [ ] Consistent plot styles across all evaluation figures

LaTeX Quality

• [ ] All code blocks have language tags (``python, ``bash, etc.)
• [ ] Non-breaking spaces before references: Section~\ref{...}
• [ ] Consistent citation format: \cite{...} not mixed with [N]
• [ ] No overfull hbox warnings in LaTeX log
• [ ] Bibliography entries have complete metadata (authors, title, venue, year)

Prose Quality (RU-System/Paper_Writing_Tips)

• [ ] No hedging without evidence ("we believe", "it seems")
• [ ] Quantitative claims have numbers ("significantly better" → "37% better")
• [ ] No first-person unless venue style requires it
• [ ] Contributions are specific, not vague ("novel" without explanation)
• [ ] Related work comparisons are fair and accurate

---

Stage 3: Evaluation Rigor

Experimental Methodology

• [ ] Baselines are state-of-the-art (not straw men)
• [ ] Baselines configured optimally (not default/untuned)
• [ ] Hardware, software versions, and configurations fully specified
• [ ] Workloads described in sufficient detail to reproduce
• [ ] Statistical significance: error bars, multiple runs, or confidence intervals
• [ ] Warmup runs excluded from measurements

Result Presentation

• [ ] Every conclusion stated 3 times: hypothesis (§ opening), result (§ closing), caption (figure)
• [ ] Ablation study isolates each design component
• [ ] Scalability experiments show behavior at increasing scale
• [ ] Both favorable and unfavorable results discussed honestly
• [ ] Performance numbers are absolute (not only relative percentages)

Reproducibility

• [ ] Source code availability stated (or planned)
• [ ] Key hyperparameters and configuration values listed
• [ ] Workload generation described or traces cited
• [ ] Enough detail for an independent team to reproduce within ~2 weeks

---

Stage 4: Design Quality

Alternatives Discussion (Irene Zhang)

• [ ] Every major design decision discusses at least one alternative
• [ ] Alternatives are genuinely considered (not straw men)
• [ ] Trade-offs for each alternative explicitly stated
• [ ] Reasons for rejection are technical (not "it was harder to implement")

Correctness Arguments

• [ ] System handles failure cases (discussed or evaluated)
• [ ] Edge cases acknowledged (even if not fully solved)
• [ ] Threat model or assumptions section present (if applicable)
• [ ] Limitations stated honestly (not hidden)

---

Stage 5: Academic Integrity

Citation Discipline

• [ ] Every citation verified programmatically (Semantic Scholar / DBLP / CrossRef)
• [ ] No citations generated from memory or LLM output
• [ ] Unverified citations marked as [CITATION NEEDED]
• [ ] All BibTeX entries have: authors, title, venue, year, pages/DOI
• [ ] No fabricated paper titles, authors, or venues
• [ ] Self-citations are relevant (not padding)

Data Integrity

• [ ] Production observations are from real data (not fabricated)
• [ ] Experimental results are from actual runs (not interpolated/extrapolated)
• [ ] Traces cited with source (public dataset or anonymized description)
• [ ] No results cherry-picked without disclosing selection criteria

LLM Disclosure

• [ ] Check venue's AI/LLM use policy in current CFP
• [ ] If LLM used for substantial writing: disclose as required
• [ ] If LLM used for code generation: disclose as required
• [ ] Confirm all LLM-assisted content reviewed by human authors

Originality

• [ ] No paragraph-level text copied from other papers
• [ ] Structural patterns inspired by other papers are attributed
• [ ] Cross-repository content (if any) is attributed, not copied
• [ ] Related work descriptions are original paraphrases, not copy-paste

---

Stage 6: Venue-Specific Checks

Verify against the current year's CFP — rules change annually.

USENIX Venues (OSDI, NSDI)

• [ ] USENIX LaTeX template used (correct version for submission year)
• [ ] Page limit: 12 pages (submission), 14 pages (camera-ready)
• [ ] Double-blind: author names and affiliations removed
• [ ] No self-identifying references in blind submission
• [ ] Supplementary material policy followed (if applicable)

ACM SIGOPS (SOSP)

• [ ] ACM SIGOPS template used
• [ ] Page limit: 12 pages of technical content
• [ ] Double-blind formatting
• [ ] ACM copyright/license block included (camera-ready only)

ACM SIGPLAN (ASPLOS)

• [ ] ACM SIGPLAN template used
• [ ] Page limit: 11 pages (submission), 13 pages (camera-ready)
• [ ] Double-blind formatting
• [ ] Artifact evaluation appendix (if applicable)

ACM (EuroSys)

• [ ] ACM template used
• [ ] Page limit: 12 pages
• [ ] Double-blind formatting
• [ ] Artifact evaluation encouraged

---

Stage 7: Final Pass

Before Clicking Submit

• [ ] PDF renders correctly (no missing fonts, broken figures)
• [ ] All TODO/FIXME comments removed from source
• [ ] [CITATION NEEDED] markers resolved or removed
• [ ] Author names correct (camera-ready) or removed (blind)
• [ ] Acknowledgements removed for blind submission
• [ ] Supplementary material properly anonymized
• [ ] File size within submission system limits
• [ ] Paper title matches submission system entry
• [ ] Abstract in submission system matches paper abstract
• [ ] Correct track/topic area selected in submission system

One-Sentence Self-Test (Levin & Redell Six Dimensions)

For each dimension, answer in one sentence: 1. Original Ideas: What is genuinely new? 2. Reality: Is the system built and tested? 3. Lessons: What did we learn that others can use? 4. Choices: Did we discuss alternatives for every major decision? 5. Context: Is the related work fair and complete? 6. Presentation: Would a non-expert in this subfield understand the paper?

If any answer is weak, revise that aspect before submitting.

Section-by-Section Blueprints for Systems Papers

Detailed paragraph-level templates for each section of a 10–12 page systems paper. Each subsection includes authoritative source quotes and structural examples from best papers.

---

Authoritative Source References

---

Abstract Blueprint (150–250 words)

Structure: 5 Sentences

S1 — Context: What broad problem area is this work in? Why does it matter?
     (e.g., "Large-scale ML training clusters waste 30–50% of GPU cycles due to...")
S2 — Gap: What specific limitation of current approaches does this work address?
     (e.g., "Existing schedulers cannot adapt to ... because ...")
S3 — Thesis: What is your key insight/approach?
     (e.g., "We present X, which uses [technique] to achieve [property] for [workload] in [environment]")
S4 — Results: What are the headline numbers?
     (e.g., "Evaluation on [N]-GPU cluster shows X improves [metric] by [Y]% over [baselines]")
S5 — Impact: Broader significance or availability.
     (e.g., "X is open-sourced at [URL] and has been deployed at [organization]")

Guidance from Sources

• Levin & Redell: "Can you state the new idea concisely? [...] Use them in the abstract and introduction."
• Irene Zhang: "The abstract is probably the hardest section to write because you cannot use any terms or concepts that you introduced in the paper."
• Gernot Heiser: The abstract must be self-contained — no forward references, no undefined jargon.

Structural Examples

Blox (EuroSys'24): Abstract states 7 scheduling abstractions, names the system, lists concrete metrics.

Sia (SOSP'23): Abstract follows problem → insight → approach → results structure in exactly 5 sentences.

---

S1 Introduction Blueprint (1.5–2 pages)

Paragraph-by-Paragraph Structure

Para 1–2: Problem Statement (~0.5 page)

Purpose: Establish the domain and its importance with concrete, quantitative evidence.

Template:

[Domain] is critical for [reason]. [Concrete statistic about scale/impact].
However, [specific challenge] leads to [quantified inefficiency].
For example, [real-world scenario with numbers].

Guidance:

• Levin & Redell: "What exactly is the problem being solved? Is it a real problem?"
• Irene Zhang: "clearly state your target environment (Z) and application (Y)"
• Use production numbers when available (cluster size, throughput, cost)

Para 3–4: Gap Analysis (~0.5 page)

Purpose: Show that existing approaches fall short. Each gap is specific and evidence-backed.

Template:

Existing systems address [aspect] through [approaches], but they fall short in [N] ways:

G1: [First gap] — [existing system] assumes [assumption], which breaks when [condition]. [Evidence].
G2: [Second gap] — [existing approach] cannot handle [scenario] because [reason]. [Evidence].
G3: [Third gap] — ...

Guidance:

• Irene Zhang: "clearly state why previous systems do not meet the needs of applications Y in environment Z"
• Each gap should be falsifiable — a reviewer can verify the claim
• Lucid (ASPLOS'23) exemplifies this: G1–G5 mapped precisely to A1–A5

Para 5: Key Insight (1 paragraph)

Purpose: The core thesis statement — the one sentence that captures your contribution.

Template:

Our key insight is that [observation about the problem] enables [new approach].
Based on this insight, we present [System Name], a [one-line description]
that [key differentiator] for [target applications] in [target environment].

Guidance:

• Irene Zhang's thesis formula: "X is better for applications Y running in environment Z"
• Levin & Redell: "What are the key ideas? Can you state them concisely?"
• This paragraph should be quotable by reviewers in their recommendation

Para 6–7: Contributions (~0.5 page)

Purpose: Numbered list of 3–5 testable claims, each linked to a paper section.

Template:

This paper makes the following contributions:
1. [Insight/Analysis] — We identify [N observations] about [domain] (§2).
2. [Design] — We design [component], which [key property] (§3).
3. [System] — We implement [System Name] in [LOC] lines of [language] (§4).
4. [Evaluation] — We evaluate [System Name] on [workload], showing [headline result] (§5).

Structural Examples:

• Blox (EuroSys'24): 7 contributions covering abstractions + simulator + case studies
• Sia (SOSP'23): 5 primary contributions with section cross-references
• Lucid (ASPLOS'23): Contributions mirror the G1–G5 gap structure

---

S2 Background & Motivation Blueprint (1–1.5 pages)

Para 1–3: Technical Background (~0.5 page)

Purpose: Define terms and describe the system environment the reader needs to understand.

Template:

[Brief description of the domain/system being studied].
[Key Term 1] refers to [definition]. [Key Term 2] refers to [definition].
Figure [N] shows the [architecture/workflow] of [system being studied].

Guidance:

• Gernot Heiser: "define-before-use" — every term must be defined before first substantive use
• Only include background necessary for understanding this paper's contribution
• If background exceeds 0.5 page, the reader may not be in your target audience

Para 4–6: Production Observations (~0.5–1 page)

Purpose: Present data-driven observations that motivate the design.

Template:

To understand [aspect], we analyze [data source] from [environment].

Observation 1: [Finding]. Figure [N] shows that [evidence]. This implies [design insight].
Observation 2: [Finding]. Table [N] shows that [evidence]. This suggests [design direction].
Observation 3: [Finding]. [Evidence]. Combined with O1 and O2, this motivates [approach].

Guidance:

• Irene Zhang: "clearly motivate Y and Z. Why is application Y important?"
• Each observation should logically lead to a design decision in §3
• Use figures/tables to present data — reviewers trust visualizations over prose claims

Structural Examples:

• GFS (arXiv 2025): 3 production observations → 3 design insights → 3 system components
• Lucid (ASPLOS'23): 5 cluster characteristic analyses from Azure/Alibaba traces

---

S3 Design Blueprint (3–4 pages)

Para 1–2: System Architecture Overview (~0.5 page)

Purpose: Architecture diagram + walkthrough. This is the "page-one figure" equivalent for the design section.

Template:

Figure [N] shows the architecture of [System Name]. [System Name] consists of [N] components:
(1) [Component A], which [function];
(2) [Component B], which [function];
(3) [Component C], which [function].

A typical request flows as follows: [step-by-step walkthrough of data/control flow].

Guidance:

• Yi Ding: "Draw a picture first" — the architecture diagram anchors the entire design section
• Gernot Heiser: "Maintaining user state" — the reader should hold the architecture in mind while reading subsections

Subsections: Module-by-Module Design (~2–2.5 pages)

For each module/subsection:

§3.X [Module Name]

[What problem this module solves — 1 sentence].

[Design choice]: We use [approach] because [reason].
[Alternative 1]: [description] was considered but rejected because [trade-off].
[Alternative 2]: [description] does not work because [limitation].

[Detailed mechanism — 1–3 paragraphs explaining how it works].
[Pseudocode or algorithm if applicable — Algorithm [N]].

Guidance:

• 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?"
• Reviewers use alternatives discussion to judge design maturity

Design Alternatives Summary (~0.5–1 page)

For complex systems, a summary table of design decisions is highly effective:

| Decision | Our Choice | Alternative | Why Not |
|----------|-----------|-------------|---------|
| Scheduling policy | [X] | [Y] | [reason] |
| Communication | [X] | [Y] | [reason] |
| Fault tolerance | [X] | [Y] | [reason] |

Structural Examples:

• Blox (EuroSys'24): 7 abstraction modules each with dedicated subsection
• Sia (SOSP'23): 3-phase scheduling design with alternatives per phase

---

S4 Implementation Blueprint (0.5–1 page)

Structure

Para 1: System overview — [Language], [LOC], built on top of [framework/library].
         We implement [System Name] as [deployment model: library/service/kernel module].

Para 2: Key engineering decisions — [Non-obvious choices]:
         - [Decision 1]: We chose [X] over [Y] because [reason].
         - [Decision 2]: [Integration detail with existing system].
         - [Decision 3]: [Performance-critical optimization].

Para 3 (optional): Deployment experience — [If applicable, brief deployment notes].

Guidance:

• Levin & Redell: "Does the paper describe something that has actually been implemented, or is it merely a proposal? Are the lessons drawn from experience or from thought experiment?"
• Keep this section concise — reviewers care about design and evaluation, not engineering diaries

---

S5 Evaluation Blueprint (3–4 pages)

Para 1–2: Experimental Setup (~0.5 page)

**Testbed**: [Hardware description — GPUs, CPUs, network, storage].
**Baselines**: [System A] ([citation]), [System B] ([citation]), [System C] ([citation]).
**Workloads**: [Workload 1 — description], [Workload 2 — description].
**Metrics**: [Primary metric] (higher is better), [Secondary metric].
**Configuration**: [Key parameter settings for all systems].

Subsection: End-to-End Comparison (~1–1.5 pages)

Per experiment block:

§5.X [Experiment Name]

Hypothesis: We expect [System Name] to [outperform/match] [baseline] on [metric]
because [design rationale linking back to §3].

[Results description with figure/table references].
Figure [N] shows [key finding]. [System Name] achieves [X]% improvement over [baseline]
on [workload] because [explanation linking to design].

Conclusion: [System Name] [outperforms/matches] [baseline] by [X]% on [metric],
confirming that [design choice from §3] is effective for [workload].

Critical: Irene Zhang's three-statement rule: 1. Hypothesis at subsection start 2. Conclusion at subsection end 3. Caption on the figure/table

Subsection: Microbenchmarks / Ablation (~1–1.5 pages)

§5.Y Ablation Study

To understand the contribution of each component, we disable them individually:
- [System Name] w/o [Component A]: [result] — [Component A] contributes [X]%.
- [System Name] w/o [Component B]: [result] — [Component B] contributes [Y]%.
- [System Name] w/o [Component C]: [result] — [Component C] contributes [Z]%.

Table [N] summarizes the ablation results. [Key takeaway about which components matter most].

Subsection: Scalability (~0.5 page)

§5.Z Scalability

Figure [N] shows [metric] as [scale dimension] increases from [min] to [max].
[System Name] scales [linearly/sub-linearly] because [reason].
At [max scale], [System Name] achieves [result], compared to [baseline] at [result].

Structural Examples:

• Sia (SOSP'23): Evaluation on 4 workload mixes × 3 cluster sizes, ablation of 3 components
• Blox (EuroSys'24): 7 case studies each with dedicated evaluation subsection

---

S6 Related Work Blueprint (1 page)

Structure: Group by Methodology

**[Category 1: e.g., Heuristic Schedulers].**
[System A] [citation] uses [approach] for [goal].
[System B] [citation] extends this with [technique].
Unlike these systems, [our system] [key difference].

**[Category 2: e.g., Learning-Based Schedulers].**
[System C] [citation] applies [ML technique] to [problem].
[System D] [citation] uses [approach] but requires [limitation].
[Our system] differs by [key distinction].

**[Category 3: e.g., Cluster Management].**
...

Guidance:

• Levin & Redell: "Are comparisons with previous work clear and explicit?"
• Never just list papers — always state how your work differs
• Irene Zhang: Use a comparison table when comparing 4+ systems

Optional: Comparison Table

| System | [Dim 1] | [Dim 2] | [Dim 3] | [Dim 4] |
|--------|---------|---------|---------|---------|
| [A]    | ✓       | ✗       | ✓       | ✗       |
| [B]    | ✗       | ✓       | ✗       | ✓       |
| Ours   | ✓       | ✓       | ✓       | ✓       |

---

S7 Conclusion Blueprint (0.5 page)

Structure: 3 Sentences + Optional Future Work

Para 1 (3 sentences):
  S1: [Problem restated — what challenge this paper addressed].
  S2: [Solution — what [System Name] does and how].
  S3: [Key result — headline evaluation numbers].

Para 2 (optional, 2–3 sentences):
  [Future directions — what extensions or open problems remain].

Guidance:

• Irene Zhang: "summarize your paper in 3 sentences: hypothesis, solution, result"
• Do not introduce new information in the conclusion
• Keep it under half a page

---

Structural Exemplar Analysis

Note: Papers below are selected as structural exemplars for their writing quality and organization. Those verified as official best paper award winners are marked with (Best Paper Award). Venue and year information has been verified against official conference websites. Papers without the award marker are included for their exemplary structure, not as best-paper claims.

OSDI/NSDI (USENIX Format)

ASPLOS/SOSP (ACM Format)

Common Structural Traits in Exemplar Papers

1. Clear thesis in abstract sentence 3 — every best paper has a quotable thesis 2. Numbered contributions with section maps — reviewers can trace claims 3. Architecture figure within first 3 pages — visual anchor for the design 4. Alternatives discussed for every major decision — shows design maturity 5. Ablation experiments present — isolate each component's contribution

Writing Patterns for Systems Papers

Four reusable structural patterns for organizing systems papers, with concrete examples from published work.

---

Pattern 1: Gap Analysis

When to use: You have identified specific, enumerable shortcomings in existing systems that your work addresses one-by-one.

Structure:

Introduction:
  G1: [Existing systems assume X, but workloads show Y]
  G2: [Existing approach cannot handle scenario Z]
  G3: [No existing system provides property W]
  ...
  "We present [System], which addresses G1–Gn through A1–An."

Design:
  A1 → addresses G1: [Design component with rationale]
  A2 → addresses G2: [Design component with rationale]
  A3 → addresses G3: [Design component with rationale]
  ...

Evaluation:
  Experiment for G1/A1: [Metric showing A1 fixes G1]
  Experiment for G2/A2: [Metric showing A2 fixes G2]
  ...

Key property: Creates a traceable contract — reviewers can verify that every claimed gap has a corresponding solution and evaluation.

Example: Lucid (ASPLOS'23)

Lucid identifies five gaps (G1–G5) in existing GPU cluster schedulers:

Structural traits:

• Each gap is stated with evidence from production traces (Azure, Alibaba)
• Each answer maps to a design subsection
• Evaluation mirrors the gap structure: one experiment per G→A pair

How to Apply This Pattern

1. List all limitations of existing work as G1–Gn (typically 3–5) 2. For each Gi, design an answering component Ai 3. In the contribution list, state: "We identify G1–Gn and address them through A1–An" 4. In evaluation, explicitly test each Gi→Ai mapping 5. Use a summary table in Introduction or Related Work showing the gap-answer mapping

---

Pattern 2: Observation-Driven

When to use: You have access to production data, workload traces, or empirical measurements that reveal surprising properties motivating your design.

Structure:

Background & Motivation:
  Observation 1: [Data finding with figure/table]
    → Insight 1: [What this means for design]
  Observation 2: [Data finding with figure/table]
    → Insight 2: [What this means for design]
  Observation 3: [Data finding with figure/table]
    → Insight 3: [What this means for design]

Design:
  Insight 1 → Component A: [Design driven by O1]
  Insight 2 → Component B: [Design driven by O2]
  Insight 3 → Component C: [Design driven by O3]

Evaluation:
  Show system handles the patterns identified in O1–O3

Key property: Ground-truth data makes the motivation irrefutable — reviewers cannot argue the problem does not exist if you show production evidence.

Example: GFS (arXiv 2025 preprint)

GFS presents three observations from production GPU cluster traces:

Structural traits:

• Each observation backed by figures from real traces
• Clear arrow from observation → insight → design component
• Evaluation workloads reproduce the observed patterns

How to Apply This Pattern

1. Analyze your production data or traces for 2–4 surprising findings 2. Present each as "Observation N" with supporting figure/table 3. Below each observation, state the design insight it implies 4. In Design, reference back: "Motivated by O1 (§2), we design..." 5. In Evaluation, use workloads that exhibit the observed patterns

---

Pattern 3: Contribution List

When to use: Your system has multiple distinct contributions that span different technical areas (new abstraction + new algorithm + new implementation + new evaluation methodology).

Structure:

Introduction:
  "This paper makes the following contributions:
  1. [Contribution type]: [Description] (§N)
  2. [Contribution type]: [Description] (§M)
  3. [Contribution type]: [Description] (§P)
  4. [Contribution type]: [Description] (§Q)"

Each section directly addresses one or more numbered contributions.

Evaluation:
  Each experiment validates a specific contribution.

Key property: Reviewers can count and verify contributions. Clear section cross-references make the paper navigable.

Example: Blox (EuroSys'24)

Blox lists 7 contributions covering the full system:

Example: Sia (SOSP'23)

Sia lists 5 primary contributions:

How to Apply This Pattern

1. List contributions as numbered items (3–7 is typical) 2. Tag each with a type: Analysis, Design, Algorithm, System, Evaluation 3. Cross-reference sections: "(§N)" 4. Ensure each contribution is testable — a reviewer should be able to verify it from the paper 5. In evaluation, map experiments back to contribution numbers

---

Pattern 4: Thesis Formula

When to use: Your paper has a single, strong central claim that can be expressed as a comparative statement.

Structure (Irene Zhang's formula):

Thesis: "X is better for applications Y running in environment Z"

Introduction: State the thesis clearly
Background: Define Y and Z, explain why they matter
Design: Explain how X achieves its advantage
Evaluation: Prove X is better for Y in Z
  - Show X beats baselines on Y
  - Show X works in environment Z
  - Show X's advantage comes from its design choices (ablation)

Key property: The entire paper serves a single, memorable claim. Reviewers can assess the paper by checking if the thesis is adequately supported.

How to Apply This Pattern

1. Distill your contribution to one sentence: "[System] is better for [application] in [environment] because [insight]" 2. In Abstract (sentence 3): state this thesis verbatim 3. In Introduction: use it as the culmination of the gap analysis 4. In Design: show how each component serves the thesis 5. In Evaluation: directly test the thesis with appropriate baselines and workloads 6. In Conclusion: restate the thesis with evidence from evaluation

Combining the Thesis Formula with Other Patterns

The thesis formula is compositional — it works as the top-level structure while other patterns fill in the details:

• Thesis + Gap Analysis: "X is better for Y in Z because it addresses G1–Gn"
• Thesis + Observation-Driven: "X is better for Y in Z; we discovered this through O1–O3"
• Thesis + Contribution List: "X is better for Y in Z; our contributions include C1–Cn"

---

Pattern Selection Guide

---

Anti-Patterns to Avoid

Anti-Pattern 1: Feature Dump

Listing system features without connecting them to problems or claims. Fix: use Gap Analysis or Thesis Formula to give every feature a purpose.

Anti-Pattern 2: Solution Looking for a Problem

Presenting the design before establishing why it is needed. Fix: use Observation-Driven to ground the design in real data.

Anti-Pattern 3: Vague Contributions

"We propose a novel system for X" — not testable, not verifiable. Fix: use Contribution List with specific, measurable claims.

Anti-Pattern 4: Missing Alternatives

Presenting design choices as the only option. Fix: for every major decision, discuss at least one alternative and why it was rejected (Irene Zhang's rule).