@r1z4x/tezgah 1.0.0

package/skills/ai-research/20-ml-paper-writing/systems-paper-writing/references/section-blueprints.md

@@ -0,0 +1,400 @@
+<!-- vendored from orchestra-research/AI-research-SKILLs@773a52944ba4747a18bd4ae9ade53fff041adcbc 20-ml-paper-writing/systems-paper-writing/references/section-blueprints.md; MIT (c) Orchestra Research -->
+# 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
+
+| # | Author(s) | Title | Affiliation / Context | URL |
+|---|-----------|-------|----------------------|-----|
+| 1 | Roy Levin & David D. Redell | "How (and How Not) to Write a Good Systems Paper" | SOSP'83 PC Chairs, USENIX/ACM SIGOPS | https://www.usenix.org/conferences/author-resources/how-and-how-not-write-good-systems-paper |
+| 2 | Irene Zhang | "Hints on how to write an SOSP paper" | MSR/UW, SOSP/OSDI PC | https://irenezhang.net/blog/2021/06/05/hints.html |
+| 3 | Gernot Heiser | Style Guide + Paper Writing Talk | UNSW, seL4 author | https://gernot-heiser.org/style-guide.html |
+| 4 | Timothy Roscoe | "Writing reviews for systems conferences" | ETH Zürich | https://people.inf.ethz.ch/troscoe/pubs/review-writing.pdf |
+| 5 | Yi Ding | "How to write good systems papers?" | — | https://counterfac.medium.com/how-to-write-good-systems-papers-b6ef3b7043ff |
+| 6 | hzwer & DingXiaoH | WritingAIPaper | GitHub (1.3k+ stars) | https://github.com/hzwer/WritingAIPaper |
+| 7 | MLNLP-World | Paper-Writing-Tips | GitHub (4.4k stars) | https://github.com/MLNLP-World/Paper-Writing-Tips |
+| 8 | RU-System-Software-and-Security | Paper_Writing_Tips | GitHub | https://github.com/RU-System-Software-and-Security/Paper_Writing_Tips |
+
+---
+
+## Abstract Blueprint (150–250 words)
+
+### Structure: 5 Sentences
+
+```text
+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**:
+```text
+[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**:
+```text
+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**:
+```text
+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**:
+```text
+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**:
+```text
+[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**:
+```text
+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**:
+```text
+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**:
+
+```text
+§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:
+
+```text
+| 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
+
+```text
+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)
+
+```text
+**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**:
+```text
+§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)
+
+```text
+§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)
+
+```text
+§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
+
+```text
+**[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
+
+```text
+| System | [Dim 1] | [Dim 2] | [Dim 3] | [Dim 4] |
+|--------|---------|---------|---------|---------|
+| [A]    | ✓       | ✗       | ✓       | ✗       |
+| [B]    | ✗       | ✓       | ✗       | ✓       |
+| Ours   | ✓       | ✓       | ✓       | ✓       |
+```
+
+---
+
+## S7 Conclusion Blueprint (0.5 page)
+
+### Structure: 3 Sentences + Optional Future Work
+
+```text
+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)
+
+| Year | Paper | Structural Pattern | Key Takeaway |
+|------|-------|--------------------|--------------|
+| 2025 | Basilisk (OSDI) (Best Paper Award) | Formal verification | Theorem-proof structure in design section |
+| 2024 | Anvil (OSDI) (Best Paper Award) | Cluster management verification | Liveness property decomposition |
+| 2024 | ChameleonAPI (OSDI) (Best Paper Award) | ML systems | API customization pipeline as workflow |
+| 2025 | NDD (NSDI) (Best Paper Award) | Network verification | Decision diagram formalization |
+
+### ASPLOS/SOSP (ACM Format)
+
+| Year | Paper | Structural Pattern | Key Takeaway |
+|------|-------|--------------------|--------------|
+| 2025 | CXLfork (ASPLOS) (Best Paper Award) | Hardware+systems | Hardware mechanism + software design dual sections |
+| 2024 | Centauri (ASPLOS) (Best Paper Award) | ML training scheduling | Overlap analysis → scheduler design |
+| 2023 | TreeSLS (SOSP) (Best Paper Award) | Persistent microkernel | NVM observations → tree-structured design |
+| 2023 | Sia (SOSP) | GPU scheduling | 5 contributions + 3-phase design |
+
+### 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

package/skills/ai-research/20-ml-paper-writing/systems-paper-writing/references/systems-conferences.md

@@ -0,0 +1,261 @@
+<!-- vendored from orchestra-research/AI-research-SKILLs@773a52944ba4747a18bd4ae9ade53fff041adcbc 20-ml-paper-writing/systems-paper-writing/references/systems-conferences.md; MIT (c) Orchestra Research -->
+# Systems Conference Guide: OSDI, NSDI, ASPLOS, SOSP
+
+This reference provides comprehensive details for top systems conferences, including deadlines, formatting requirements, track descriptions, and submission strategies.
+
+---
+
+## Conference Overview
+
+| Conference | Full Name | Page Limit | Template | Tracks |
+|------------|-----------|------------|----------|--------|
+| **OSDI 2026** | 20th USENIX Symposium on Operating Systems Design and Implementation | 12 pages (+2 camera-ready) | USENIX `usenix-2020-09.sty` | Research + Operational Systems |
+| **NSDI 2027** | 24th USENIX Symposium on Networked Systems Design and Implementation | 12 pages | USENIX `usenix-2020-09.sty` | Research / Frontiers / Operational |
+| **ASPLOS 2027** | ACM International Conference on Architectural Support for Programming Languages and Operating Systems | 12 pages (ACM) | ACM SIGPLAN `acmart.cls` | Single track, dual review cycles |
+| **SOSP 2026** | 32nd ACM Symposium on Operating Systems Principles | 12 pages | ACM SIGPLAN `acmart.cls` | Single track |
+
+> **OSDI 2026**: New "Operational Systems" track. Max 8 papers per author. Encourages appropriate paper length (don't pad to 12 pages). Target acceptance rate ≥20%. No author response period; uses "conditional accept" instead of major revision.
+>
+> **NSDI 2027**: Two deadlines (Spring/Fall). New "Frontiers Track" for ambitious, forward-looking ideas. All papers undergo Introduction prescreening. Rejected papers may receive one-shot revision opportunity.
+>
+> **ASPLOS 2027**: Two cycles (April/September). New rapid review round (only first 2 pages reviewed). Evaluates contributions to architecture/PL/OS core areas. Max 4 papers per author per cycle.
+>
+> **SOSP 2026**: ACM SIGPLAN format. Optional Artifact Evaluation. Double-blind review. Encourages breakthrough research directions.
+
+---
+
+## Deadlines & Key Dates
+
+### OSDI 2026 (Seattle, WA, USA | July 13–15, 2026)
+
+| Milestone | Date |
+|-----------|------|
+| Abstract registration | December 4, 2025, 5:59 PM EST |
+| Full paper submission | December 11, 2025, 5:59 PM EST |
+| Notification | March 26, 2026 |
+| Camera-ready | June 9, 2026 |
+
+### NSDI 2027 (Providence, RI, USA | May 11–13, 2027)
+
+**Spring Deadline:**
+
+| Milestone | Date |
+|-----------|------|
+| Titles and abstracts | April 16, 2026, 11:59 PM EDT |
+| Full paper | April 23, 2026, 11:59 PM EDT |
+| Notification | July 23, 2026 |
+| Camera-ready | October 20, 2026 |
+
+**Fall Deadline:**
+
+| Milestone | Date |
+|-----------|------|
+| Titles and abstracts | September 10, 2026, 11:59 PM EDT |
+| Full paper | September 17, 2026, 11:59 PM EDT |
+| Notification | December 8, 2026 |
+| Camera-ready | March 4, 2027 |
+
+### ASPLOS 2027
+
+**April Cycle:**
+
+| Milestone | Date |
+|-----------|------|
+| Full paper submission | April 15, 2026 (AoE) |
+| Author response | July 6–9, 2026 |
+| Notification | July 27, 2026 |
+
+**September Cycle:**
+
+| Milestone | Date |
+|-----------|------|
+| Full paper submission | September 9, 2026 (AoE) |
+| Author response | December 1–4, 2026 |
+| Notification | December 21, 2026 |
+
+### SOSP 2026 (September 30, 2026)
+
+| Milestone | Date |
+|-----------|------|
+| Abstract registration | March 26, 2026 (AoE) |
+| Full paper submission | April 1, 2026 (AoE) |
+| Notification | July 3, 2026 |
+| Camera-ready | August 28, 2026 |
+| Workshops | September 29, 2026 |
+| Conference | September 30, 2026 |
+
+---
+
+## Track Descriptions
+
+### OSDI 2026 Tracks
+
+**Research Track**: Broad interest in operating systems design, implementation, analysis, evaluation, and deployment. Topics include:
+- Operating systems, their interaction with hardware/software, and their role as building blocks for other systems
+- Virtualization, including virtual machine monitors, hypervisors, and OS-level virtualization
+- File and storage systems, distributed systems, cloud computing
+- Systems for machine learning/AI, security and privacy, embedded/real-time systems
+
+**Operational Systems Track** (NEW):
+- Papers describing deployed and operational systems with valuable lessons
+- Title must end with "(Operational Systems)"
+- Evaluation criteria focus on deployment insights rather than novelty
+
+### NSDI 2027 Tracks
+
+**Research Track**: Original research on networked systems design and implementation.
+
+**Frontiers Track** (NEW):
+- For ambitious, forward-looking ideas in networked systems
+- May have less complete evaluation but must present compelling vision
+
+**Operational Track**: Systems deployed at scale with operational insights.
+
+### ASPLOS 2027 Review Process
+
+**Rapid Review Round** (NEW):
+- Reviewers read ONLY the first 2 pages to decide if paper merits full review
+- First 2 pages must be self-contained: problem, approach, key results, contribution
+- Papers failing rapid review receive brief feedback and are rejected
+
+**Full Review Round**:
+- Standard double-blind review process
+- Author response period
+- Major revision available (not just accept/reject)
+
+### SOSP 2026 Features
+
+- **Artifact Evaluation** (optional but encouraged): Submit artifacts for reproducibility
+- **Author Response**: 500-word limit, no new experiments allowed
+
+---
+
+## Formatting Requirements
+
+### USENIX Format (OSDI, NSDI)
+
+```latex
+% USENIX format setup
+\documentclass[letterpaper,twocolumn,10pt]{article}
+\usepackage{usenix-2020-09}
+
+% Key specifications:
+% - Paper size: US Letter (8.5" x 11")
+% - Font: Times Roman, 10pt on 12pt leading
+% - Text block: 7" x 9"
+% - Two columns, 0.33" column separation
+% - Page limit: 12 pages (excluding references)
+```
+
+### ACM SIGPLAN Format (ASPLOS, SOSP)
+
+```latex
+% ACM SIGPLAN format setup
+\documentclass[sigplan,10pt]{acmart}
+
+% For submission (hide copyright block):
+\setcopyright{none}
+\settopmatter{printfolios=true, printccs=false, printacmref=false}
+\renewcommand\footnotetextcopyrightpermission[1]{}
+
+% Key specifications:
+% - Paper size: US Letter
+% - Font: 10pt
+% - Text block: 178mm x 229mm
+% - Two columns
+% - Page limit: 12 pages (excluding references)
+```
+
+---
+
+## Submission Rules
+
+### OSDI 2026
+
+- **Max submissions per author**: 8 papers
+- **No author response period**
+- **Conditional accept** replaces major revision
+- **Anonymization**: System name must differ from arXiv/talks
+- **Paper length**: Encouraged to be as short as needed (don't pad to 12 pages)
+- **AI policy**: Generative AI tools allowed if disclosed; AI cannot be listed as author
+
+### NSDI 2027
+
+- **Prescreening via Introduction**: All papers first evaluated based on Introduction quality
+- **One-shot revision**: Rejected papers may receive revision opportunity
+- **Dual deadlines**: Spring (April 2026) + Fall (September 2026)
+- **Track selection**: Must choose Research, Frontiers, or Operational at submission
+
+### ASPLOS 2027
+
+- **Max submissions per author per cycle**: 4 papers
+- **Rapid review**: Only first 2 pages reviewed initially
+- **Dual cycles**: April + September
+- **Resubmission note**: Required if previously submitted to ASPLOS
+- **Must advance**: Architecture, Programming Languages, or Operating Systems research
+
+### SOSP 2026
+
+- **Artifact Evaluation**: Optional but recommended
+- **Author response**: 500-word limit, no new experiments
+- **Anonymous system name**: Required, different from public versions
+- **Double-blind**: Authors must not be identifiable
+
+---
+
+## Format Conversion: ML Venue → Systems Venue
+
+When converting a paper from an ML venue to a systems venue, the changes go beyond template swapping:
+
+| Aspect | ML Venue | Systems Venue | Action |
+|-------|----------|---------------|--------|
+| **Page limit** | 7-9 pages | 12 pages | Expand with system design details |
+| **Evaluation** | Benchmarks, ablations | End-to-end + microbenchmarks | Add system-level evaluation |
+| **Contribution framing** | Algorithmic novelty | System design + implementation | Reframe as systems contribution |
+| **Implementation** | Often secondary | Core contribution | Detail architecture, optimizations |
+| **Deployment** | Rarely discussed | Highly valued (especially OSDI/NSDI) | Add deployment experience |
+
+### Specific Conversion Paths
+
+| From → To | Key Adjustments |
+|-----------|------------------|
+| ML → OSDI | USENIX template; reframe for systems; add design/implementation; emphasize deployment |
+| ML → NSDI | USENIX format; emphasize networked systems; choose track |
+| ML → ASPLOS | ACM SIGPLAN; self-contained first 2 pages (rapid review); frame for arch/PL/OS |
+| ML → SOSP | ACM SIGPLAN; emphasize OS principles; system design/evaluation |
+| OSDI ↔ SOSP | USENIX ↔ ACM SIGPLAN template; similar page limits |
+| OSDI ↔ NSDI | Same USENIX format; adjust scope (general vs networked) |
+
+---
+
+## Systems Paper Structure
+
+A typical systems paper follows this structure (differs from ML papers):
+
+```text
+1. Introduction          - Problem, approach, key results (CRITICAL for NSDI prescreening / ASPLOS rapid review)
+2. Background/Motivation - System context, why existing solutions fail
+3. Design                - System architecture, key design decisions
+4. Implementation        - Implementation details, optimizations, engineering challenges
+5. Evaluation            - End-to-end performance + microbenchmarks + scalability
+6. Discussion            - Limitations, deployment lessons (optional but valued at SOSP)
+7. Related Work          - Organized by approach, not chronologically
+8. Conclusion            - Summary of contributions and impact
+```
+
+**Key differences from ML papers**:
+- **Design section** replaces Methods: Focus on architecture and trade-offs
+- **Implementation section** is a core contribution, not an afterthought
+- **Evaluation** includes both macro (end-to-end) and micro benchmarks
+- **Discussion** section is common (especially SOSP)
+
+---
+
+## Official CFP Links
+
+- **OSDI 2026**: <https://www.usenix.org/conference/osdi26/call-for-papers>
+- **NSDI 2027**: <https://www.usenix.org/conference/nsdi27/call-for-papers>
+- **ASPLOS 2027**: <https://www.asplos-conference.org/asplos2026/call-for-papers-asplos27/>
+- **SOSP 2026**: <https://sigops.org/s/conferences/sosp/2026/cfp.html>
+- **USENIX LaTeX Template**: <https://www.usenix.org/conferences/author-resources/paper-templates>
+- **ACM SIGPLAN Template**: <https://www.acm.org/publications/proceedings-template>