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)
Gernot Heiser (UNSW, seL4) — Style Guide + Paper Writing Talk
Timothy Roscoe (ETH Zürich) — "Writing reviews for systems conferences"
Mike Dahlin (UT Austin/Google) — "Giving a Conference Talk"
Yi Ding — "How to write good systems papers?"
hzwer & DingXiaoH — WritingAIPaper (GitHub 1.3k+ stars)

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

12-Page Systems Paper Blueprint

Overview: Page Allocation

| Section | Pages | Purpose | |---------|-------|---------| | Abstract | ~0.25 | 150–250 words, 5-sentence structure | | S1 Introduction | 1.5–2 | Problem → Gap → Insight → Contributions | | S2 Background & Motivation | 1–1.5 | Terms + Production observations | | S3 Design | 3–4 | Architecture + Module details + Alternatives | | S4 Implementation | 0.5–1 | Prototype details, LOC, key engineering | | S5 Evaluation | 3–4 | Setup + End-to-end + Microbenchmarks + Scalability | | S6 Related Work | 1 | Grouped by methodology, explicit comparison | | S7 Conclusion | 0.5 | 3-sentence summary | | Total | ~12 | 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.

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:

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

Experimental setup (~0.5 page) — Hardware, baselines, workloads, metrics. Enough detail to reproduce.
End-to-end comparison (~1–1.5 pages) — X vs baselines for application Y on environment Z. Main performance results.
Microbenchmarks / Ablation (~1–1.5 pages) — Isolate each design decision's contribution. Ablation experiments decompose the gains.
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):

The hypothesis / problem addressed
The solution approach
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.

| 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
references/writing-patterns.md — Four writing patterns with concrete paper examples

Venue-Specific

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

LaTeX Templates

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)

Systems Paper Writing: Paragraph-Level Structural Blueprint

When to Use This Skill

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)
Gernot Heiser (UNSW, seL4) — Style Guide + Paper Writing Talk
Timothy Roscoe (ETH Zürich) — "Writing reviews for systems conferences"
Mike Dahlin (UT Austin/Google) — "Giving a Conference Talk"
Yi Ding — "How to write good systems papers?"
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

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.

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

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.

S4 Implementation (0.5–1 page)

Prototype description — Language, framework, LOC, integration with existing systems.
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:

Experimental setup (~0.5 page) — Hardware, baselines, workloads, metrics. Enough detail to reproduce.
End-to-end comparison (~1–1.5 pages) — X vs baselines for application Y on environment Z. Main performance results.
Microbenchmarks / Ablation (~1–1.5 pages) — Isolate each design decision's contribution. Ablation experiments decompose the gains.
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):

The hypothesis / problem addressed
The solution approach
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)

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

Writing Guidance

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

Venue-Specific

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

LaTeX Templates

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)

Adoption

Orchestra-Research/systems-paper-writing

$ install --global

Security Scan Results

SKILL.md

Systems Paper Writing: Paragraph-Level Structural Blueprint

When to Use This Skill

Authoritative Sources

12-Page Systems Paper Blueprint

Overview: Page Allocation

Abstract (150–250 words, 5 sentences)

S1 Introduction (1.5–2 pages)

S2 Background & Motivation (1–1.5 pages)

S3 Design (3–4 pages)

S4 Implementation (0.5–1 page)

S5 Evaluation (3–4 pages)

S6 Related Work (1 page)

S7 Conclusion (0.5 page)

Writing Patterns

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

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

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

Pattern 4: Thesis Formula (Irene Zhang)

Conference Differences

Writing Philosophy

Manage Reader State (Gernot Heiser)

Six-Dimensional Quality (Levin & Redell)

Page-One Figure (hzwer)

Academic Integrity Requirements

Citation Discipline

Prohibition of Fabrication

LLM Disclosure

Attribution

Temporal Validity

Workflow: Structuring a New Systems Paper

Quick Checklist

Common Issues and Solutions

References

Writing Guidance

Venue-Specific

LaTeX Templates

Related Skills

Orchestra-Research/ara-rigor-reviewer

Orchestra-Research/ara-research-manager

Orchestra-Research/ara-compiler

Orchestra-Research/evolving-ai-agents

Orchestra-Research/systems-paper-writing

$ install --global

Security Scan Results

SKILL.md

Systems Paper Writing: Paragraph-Level Structural Blueprint

When to Use This Skill

Authoritative Sources

12-Page Systems Paper Blueprint

Overview: Page Allocation

Abstract (150–250 words, 5 sentences)

S1 Introduction (1.5–2 pages)

S2 Background & Motivation (1–1.5 pages)

S3 Design (3–4 pages)

S4 Implementation (0.5–1 page)

S5 Evaluation (3–4 pages)

S6 Related Work (1 page)

S7 Conclusion (0.5 page)

Writing Patterns

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

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

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

Pattern 4: Thesis Formula (Irene Zhang)

Conference Differences

Writing Philosophy

Manage Reader State (Gernot Heiser)

Six-Dimensional Quality (Levin & Redell)

Page-One Figure (hzwer)

Academic Integrity Requirements

Citation Discipline

Prohibition of Fabrication

LLM Disclosure

Attribution

Temporal Validity

Workflow: Structuring a New Systems Paper