Comprehensive guide for writing systems papers targeting OSDI, SOSP, ASPLOS, NSDI, and EuroSys. Provides paragraph-level structural blueprints, writing patterns, venue-specific checklists, reviewer guidelines, LaTeX templates, and conference deadlines. Use this skill for all systems conference paper writing.
Comprehensive guide for writing systems papers targeting OSDI, SOSP, ASPLOS, NSDI, and EuroSys. Provides paragraph-level structural blueprints, writing patterns, venue-specific checklists, reviewer guidelines, LaTeX templates, and conference deadlines. Use this skill for all systems conference paper writing.
version
1.1.0
author
Orchestra Research
license
MIT
tags
["Systems Paper Writing","OSDI","SOSP","ASPLOS","NSDI","EuroSys","Structural Blueprint","Academic Writing","LaTeX"]
Systems Paper Writing: 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
Scenario
Use This Skill
Use ml-paper-writing Instead
Structuring a 12-page OSDI/SOSP paper
✅
Page budget and paragraph planning
✅
Systems-specific evaluation structure
✅
General ML paper writing philosophy
✅
Citation verification workflow
✅
LaTeX templates and formatting
✅
NeurIPS/ICML/ICLR paper structure
✅
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:
Levin & Redell — "How (and How Not) to Write a Good Systems Paper" (SOSP'83 PC Chairs, USENIX/ACM SIGOPS)
Irene Zhang (MSR/UW) — "Hints on how to write an SOSP paper" (SOSP/OSDI PC)
Submission: 12 pages strict (USENIX) / 11 pages (ACM ASPLOS). Camera-ready: up to 14 pages (USENIX) / 13 pages (ACM). Ranges above span submission through camera-ready. Target 12 pages for initial submission. References unlimited.
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:
Problem statement (~0.5 page) — Establish the domain and why it matters. Use concrete numbers (cluster sizes, workload statistics, latency requirements).
Gap analysis (~0.5 page) — Enumerate specific gaps G1–Gn in existing systems. Each gap is one sentence with evidence.
Key insight (1 paragraph) — The thesis statement: "X is better for applications Y running in environment Z." (Irene Zhang formula)
Contributions (~0.5 page) — Numbered list of 3–5 concrete contributions. Each contribution is testable and maps to a section.
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:
Technical background (~0.5 page) — Define terms and systems the reader needs. Follow Gernot Heiser's "define-before-use" principle.
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:
System architecture overview (~0.5 page) — Architecture diagram first (Yi Ding: "draw a picture first"). One-paragraph walkthrough of major components and data flow.
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.
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)
Prototype description — Language, framework, LOC, integration with existing systems.
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."
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.
Venue
Format
Submission Limit
Camera-Ready
References
OSDI
USENIX
12 pages
14 pages
Unlimited
NSDI
USENIX
12 pages
14 pages
Unlimited
SOSP
ACM SIGOPS
12 pages (tech content)
—
Unlimited
ASPLOS
ACM SIGPLAN
11 pages
13 pages
Unlimited
EuroSys
ACM
12 pages
—
Unlimited
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
Issue
Solution
Paper feels like a "feature list"
Restructure around thesis formula: X better for Y in Z
Evaluation lacks depth
Add ablation experiments isolating each design decision
Reviewers say "incremental"
Strengthen gap analysis: make G1–Gn crisper with evidence
Design section too long
Move implementation details to S4, keep S3 at design level
Motivation feels weak
Add production observations with concrete numbers
Related work reads like a bibliography
Group by approach, add explicit differentiation
References
Writing Guidance
references/section-blueprints.md — Detailed per-section paragraph templates with authoritative source quotes and best-paper structural examples
