Research Writing Skill

Research Writing Skill

Scope

Use this skill for research writing and revision when the output is prose, LaTeX, Markdown, or manuscript text. Use office-academic-skill instead when the main deliverable is Word/PPT. Use scientific-toolkit-skill when the task is primarily MATLAB, Python, plotting, statistics, simulation, or literature search.

Writing Principles

• Default to Chinese academic expression unless the user requests English.
• Preserve English titles, formulas, variables, methods, software names, citations, and reference entries.
• Do not invent data, DOI, journal details, experiment settings, results, or author claims.
• Separate 原文/已有数据, 用户确认内容, 根据上下文推断, and 建议性扩展.
• Prefer verifiable technical statements over generic claims.
• When revising, preserve the user's intended meaning and terminology unless a change is clearly needed.

Manuscript Workflow

For a new section or paper draft:

1. Clarify target: journal/conference/thesis/course report, language, length, audience, and required format. 2. Identify source material: paper notes, experiment results, figures, tables, MATLAB/Python outputs, references, advisor comments. 3. Build an argument outline before full prose: problem, gap, method, evidence, contribution, limitation. 4. Draft in coherent paragraphs, not empty slogan bullets. 5. Add source or evidence labels for quantitative claims and literature claims. 6. Revise for logic, specificity, terminology consistency, and citation accuracy.

For revision or polishing:

• Keep claims tied to evidence.
• Replace vague words such as "显著", "先进", "有效", "鲁棒" with measured conditions, comparison baselines, or remove them.
• Check whether each paragraph advances the section's purpose.
• Keep formulas with variable definitions, units, assumptions, and applicable conditions.
• For experimental sections, state dataset/sample, hardware/software, parameters, metrics, baselines, and uncertainty when available.

Section Guides

Use these default moves unless the user's school or journal template overrides them:

• Abstract: problem, method, experiment/data, key result, contribution.
• Introduction: background, unresolved gap, why it matters, proposed approach, contributions.
• Related work: organize by technical theme, compare assumptions and limitations, avoid simple paper-by-paper summaries.
• Methods: model assumptions, variables, workflow, algorithm, implementation details needed for reproduction.
• Experiments: data/source, platform/software, parameters, metrics, baseline, repeated trials, visualization plan.
• Results and discussion: claim first, evidence second, mechanism/explanation third, limitation last.
• Conclusion: answer the research question, summarize evidence, state limitations and next steps.

Bundled References

The folder references/paper-writing/ contains external writing checklists and section patterns adapted as references. Load only the relevant file when needed:

• brainstorming_guide.md for turning an unclear idea into a paper plan.
• section_rhetorical_moves/ for section structure.
• writing_checklists/ for self-diagnosis.
• figure_templates/ for figure planning.
• author_profile/ for editorial heuristics.

These references come from an external systems/networking-oriented repository. Treat them as optional craft guidance, not binding rules, and adapt them to光电信息科学与工程, optics, optoelectronics, sensing, communication, signal processing, and MATLAB simulation work.

Final Checks

Before delivery, state:

• What was drafted or revised.
• Which source material was used.
• Which claims still need user-provided data or citation support.
• Any uncertainty about terminology, parameters, or references.

Compression Patterns

Overview

Late-stage compression is a universal part of the writing process. This document catalogs the 7 specific compression operations, their application context, and the principles they encode.

---

Pattern 1: Sentence Shortening

Operation: Remove subordinate clauses, redundant qualifiers, and throat-clearing phrases.

Before: "We argue that a data-driven approach that leverages machine learning techniques can potentially offer significantly better trade-offs between the measurement cost and accuracy."

After: "Do speed tests need to transmit their full data volume to produce accurate results?"

Principle: Every word must earn its place. If a clause can be removed without losing meaning, remove it.

---

Pattern 2: Paragraph Merging

Operation: Merge paragraphs that make the same point with different examples into a single paragraph with the best example.

Principle: Multiple examples of the same point dilute rather than strengthen. One well-chosen example is stronger than three adequate ones.

---

Pattern 3: Removal of Generic Adjectives

Before: "significant", "substantial", "impressive", "promising", "novel", "innovative"

After: Specific numbers ("2–4×"), named mechanisms, or deleted entirely.

Principle: Generic adjectives are space-consuming non-information. They tell the reader "this is good" without saying HOW good. Replace with metrics or delete.

---

Pattern 4: Removal of Tutorial Explanation

Operation: Delete paragraphs that explain concepts the venue audience already knows.

Typical deletions: General optimization theory, formal definitions of well-known ML concepts, textbook-level background on the venue's core domain.

Quantitative signature: The largest single deletions in any paper are tutorial material.

Principle: If the venue's reviewers already know it, it doesn't belong. The only exception: when the paper redefines a known concept in a new way — then the redefinition IS the contribution.

---

Pattern 5: Conversion to Claim-First Sentences

Before (descriptive): "Experimental Results" / "System Architecture"

After (claim-first): "System X outperforms all baselines by 2–4×" / "Why do linear approaches fail?"

Operation: Rewrite headings so they contain the section's conclusion, not just its topic. Rewrite paragraph openings so the claim comes first and evidence follows.

Principle: Readers skim headings and topic sentences. If the heading contains the finding, the skim-reader gets the argument. If it only names the topic, they get nothing.

---

Pattern 6: Evaluation Compression via Takeaways

Operation: Replace multiple paragraphs of detailed result description with a compact Takeaway paragraph that synthesizes the key finding.

Before: 8 paragraphs of per-condition results with individual numbers.

After: 3 paragraphs of grouped results + 1 Takeaway paragraph that states the implication.

Principle: The reader doesn't need every number — they need the PATTERN. Takeaway paragraphs compress results into interpretations.

---

Pattern 7: Figure/Table Promotion (Text → Visual)

Operation: Move detailed numerical comparisons from prose into figures or tables. Replace prose descriptions with figure references + interpretation.

Before: "Model A achieves 92%. Model B achieves 87%. Model C achieves 84%. Model D achieves 91%."

After: "Table 3 shows all model accuracies. Our system outperforms all baselines, with the largest margin against static thresholds."

Principle: Dense numerical comparisons belong in tables. Prose should interpret patterns, not list numbers.

---

Compression Intensity Guide

---

The Expansion-Compression Arc

Every paper follows this pattern:

1. Student draft: Comprehensive, includes everything discovered 2. Advisor edit round 1: May EXPAND (add "why" arguments, structural labels) 3. Advisor edit round 2+: COMPRESS (remove what doesn't serve the argument)

The expansion peak is never the final version. The compression pass is a sign of editorial maturity — the authors finally know what matters.

This arc is observable at every scale: sentences shorten, paragraphs merge, sections consolidate, total character count decreases in the final pass.

Editorial Principles for Research Papers

Overview

These 13 principles are distilled from systematic analysis of multiple paper revision histories across systems and ML venues. Each principle is supported by evidence from at least two independent paper revision cycles. They are ordered by their observed impact on acceptance outcomes.

---

Principle 1: Introduction-Twice (Draft 0 → Evaluation → Final Introduction)

The introduction is written twice. Draft 0 is a framing scaffold — stakes, problem gap, rough contribution claims — written early to set guardrails for the evaluation. It clarifies thinking and establishes what the paper is trying to show. Draft 0 is explicitly disposable; it probably will not survive. The final introduction is written after the evaluation is complete, constrained by what the evidence actually supports. Each claim in the final introduction must map to a specific evaluation subsection.

The key insight: writing is a thinking tool, not just a communication tool. A preliminary introduction forces the student to externalize their framing before designing experiments. Without Draft 0's guardrails, the evaluation is written without constraints — the student doesn't know what they're trying to show. But without evaluation-constrained rewriting, the introduction promises what the student hoped to show rather than what they did show.

Observed consequence of skipping Draft 0: Students who went straight to evaluation without framing guardrails produced evaluations that were technically complete but narratively incoherent — the experiments didn't build toward a unified argument because there was no argument to build toward.

Observed consequence of skipping the rewrite: Papers whose Draft 0 introduction survived to submission frequently promised capabilities (e.g., "domain adaptation," "cross-domain generality") that the evaluation couldn't deliver. These papers were rejected.

Rule: Write a Draft 0 introduction early (stakes, problem gap, rough contributions) to set evaluation guardrails. Write the final introduction AFTER the evaluation is complete, from scratch. Draft 0 is scaffolding, not a starting point for editing.

---

Principle 2: Named Over Vague

Replace every generic term with a specific, named alternative. Generic adjectives ("significant," "substantial," "promising," "novel") are space-consuming non-information. Named mechanisms, specific numbers, and coined terminology earn their place.

The test: If a term could apply to ANY paper in the field, it doesn't belong in YOUR paper. "Data-driven approach" could describe thousands of papers. A precise phrase like "two-stage framework with configurable accuracy-cost trade-off" describes exactly one.

Rule: Every baseline, metric, and abstraction should have a proper name. If the paper introduces a new concept, NAME it — the name becomes citable.

---

Principle 3: The What → Why → So-What Heading Progression

Section headings evolve through three stages as a paper matures:

1. WHAT headings (student drafts): descriptive, topic-naming. Example: "Experimental Results" 2. WHY headings (first senior edit): problem-driven. Example: "Why do linear approaches fail?" 3. SO-WHAT headings (final version): claim-first, stating the conclusion. Example: "System X outperforms all baselines by 2–4×"

The test: Can a skim-reader reconstruct the paper's argument from headings alone? If headings only name topics, the skim-reader gets nothing. If headings contain claims, the skim-reader gets the argument.

Rule: Rewrite every heading to contain the section's CONCLUSION, not just its TOPIC.

---

Principle 4: Compress After Expanding

Every paper follows an expansion-compression arc. The first draft is comprehensive ("everything in"). The advisor may EXPAND first (adding structural labels, "why" arguments). Then compression removes what doesn't serve the argument. The longest version is never the final version.

Normal compression range: 30–50% reduction in the final pass. Compression above 50% usually signals a framing problem — content was cut because the narrative shifted fundamentally. Compression below 15% suggests the draft was already near publication-ready.

Rule: Write comprehensively first. Then ask of every paragraph: "Does this serve one of the paper's explicit claims?" If not, delete it.

---

Principle 5: Structural Rewrites Over Incremental Editing

The writing process is iterative reconceptualization, not polishing. Each major version should be written from scratch with the SAME underlying results but a DIFFERENT narrative. Attempting to polish an early draft into a final version produces mediocre results because the framing decisions are baked into the sentence structure.

When to polish vs. rewrite: If the paper's identity (what it claims to be about) is stable, polish. If the identity needs to change, rewrite from scratch. The signal that a rewrite is needed: the introduction promises something the evaluation doesn't deliver.

Rule: When creating a new major version, start from a blank page. The previous version is reference material, not a starting point.

---

Principle 6: Labeled Paragraphs as Narrative Contracts

In systems venues, labeled paragraph markers (e.g., \smartparagraph{}) function as explicit narrative contracts. Each label constrains what the following paragraph must deliver. Once the labels are set, editing is constrained to FILL them, not restructure around them. This is why labeled paragraph introduction correlates with paper stabilization.

Venue adaptation: Labeled paragraphs are a systems-paper convention (SIGCOMM, NSDI). For ML venues (NeurIPS, ICLR), replace with section headers using colon-style subtitles.

Rule: Before writing a section, write the paragraph labels first. They are the section's outline. If a paragraph doesn't fit any label, the paragraph doesn't belong, or a label is missing.

---

Principle 7: Problem-First, Not Method-First

Student drafts frequently lead with the ML/AI technology. The advisor's intervention shifts the opening to lead with the PROBLEM the technology solves. The ML/AI component becomes the METHOD, not the MESSAGE.

Why this matters: Method-first openings position the paper as "another ML application" — competing against every other ML-for-X paper. Problem-first openings position the paper as solving a domain problem — competing against other solutions to that specific problem. The latter is a smaller, more winnable competitive frame.

Rule: The first sentence should describe the PROBLEM or DOMAIN, not the TECHNOLOGY. ML/AI should appear no earlier than the third paragraph.

---

Principle 8: Takeaway Paragraphs in Evaluation

After every experiment or group of related experiments, insert a Takeaway paragraph that states the IMPLICATION, not just the result. The Takeaway compresses results into interpretation — it tells the reader the PATTERN, not the NUMBERS.

Before: "Model A: 92%, Model B: 87%, Model C: 84%, Model D: 91%." After: "Takeaway. Our system outperforms all baselines, with the largest margins in challenging conditions."

Rule: Every evaluation subsection ends with a Takeaway paragraph. It should be interpretable without reading the detailed results — it is the skim-reader's entry point.

---

Principle 9: Dual Evaluation for Dual Contributions

If a paper makes two fundamentally different types of claims (e.g., "the system works correctly" AND "the system improves downstream performance"), the evaluation must be split into separate sections. A monolithic evaluation that mixes claim types produces confusion because each claim requires different baselines, metrics, and experimental design.

The test: Can each evaluation subsection be described with a single sentence of the form "This section shows that [specific claim]"? If a subsection argues for multiple claims, it needs to be split.

Rule: Before writing the evaluation, list every claim from the introduction. Map each claim to baselines, metrics, and experiments. If two claims require different experimental designs, they belong in separate subsections.

---

Principle 10: Venue-Specific Structural Adaptation

The same underlying principles (claim-first headings, named-over-vague, evaluation-organized-by-claim) apply everywhere, but surface conventions must adapt to venue norms.

Systems venue conventions (SIGCOMM, NSDI): Labeled paragraphs, "Design" section with named components, Takeaway paragraphs, post-evaluation related work, page-limit compression.

ML venue conventions (NeurIPS, ICLR): Method-naming sections with colon subtitles, reproducibility checklist, large appendix, method-driven headings.

Rule: Before writing, read 3–5 recent accepted papers at the target venue. Adapt surface conventions while maintaining the underlying principles.

---

Principle 11: Rejection Drives Abstraction

Rejection forces papers to a higher level of abstraction. Each rejection identifies a framing mismatch — the paper claims to be X but delivers Y. The revision process forces alignment between claim and evidence.

Observable pattern: Papers that resolved their identity crises BEFORE submission were accepted. Papers whose identity was still evolving at submission were rejected. The number of pre-submission rewrites correlates with acceptance — not because rewrites are inherently good, but because they indicate the identity discovery happened in the writing room rather than during peer review.

Rule: After rejection, don't just address specific reviewer comments. Ask: "What does this paper claim to be about, and does the evidence support that claim?" If not, the next submission needs a structural rewrite, not a revision.

---

Principle 12: The Student Draft Is Material, Not the Paper

The student's initial comprehensive draft is valuable raw material, not a failure to be fixed. The issue is not that students write too much — it's that knowing WHAT to keep requires understanding the paper's competitive framing, which is a skill developed through experience.

The division of labor: Student writes comprehensively → Advisor restructures → Advisor compresses → Joint polishing. Students should write comprehensive first drafts without self-censoring. Asking students to "be more concise" in their first draft is counterproductive — it eliminates material the advisor might need.

---

Principle 13: Measurement Papers Have Stable Identities

Papers where the contribution is "what we found" (measurement/evaluation) have stable identities determined by the research questions. Papers where the contribution is "what we built" (systems) require discovering HOW to position the technical contribution through writing.

Implication for advising: Less experienced writers can succeed with measurement papers (stable identity, question-driven structure). Systems papers require framing skill that develops through experience — they benefit from early advisor involvement in framing.

---

Principle Summary

---

Principle 14: Technical Claims Require Citations

Every technical claim in a paper must be grounded with a citation or an explicit cross-reference. When section N references content that was established with citations in section M, it must either carry forward the relevant \cite{} commands or use an explicit forward/backward reference (\S\ref{}). Uncited technical claims — no matter how well-established — read as unsupported assertions to reviewers.

Common violation: A design section restates failure modes or properties described in the background section but drops all the citations that supported those claims. The result looks like the authors are asserting without evidence.

Rule: After drafting any section, scan for technical claims (failure modes, properties of algorithms, known limitations of baselines). Each must have either a citation or an explicit cross-reference to the section where the citation lives.

---

How to Apply These Principles

For writing feedback: Given a draft, identify which principles are violated. If the introduction leads with "ML has shown impressive results...", flag Principle 7. If section headings are descriptive, flag Principle 3. If technical claims lack citations, flag Principle 14.

For advisor simulation: Apply in order: Principle 1 (check whether the introduction promises match evaluation evidence — if not, rewrite the introduction from scratch) → Principle 7 (reframe problem-first) → Principle 3 (rewrite headings) → Principle 2 (replace generic terms) → Principle 14 (verify citations) → Principle 4 (compress).

Advisor Intervention Types

Overview

This document classifies the 7 types of editorial interventions an advisor typically makes on student drafts. Use this to simulate advisor feedback: given a draft, identify which intervention types apply, then apply them in the order listed.

---

Type 1: Framing Intervention

What it is: Changing the paper's top-level narrative — what the paper claims to be "about."

When it fires: When the draft's framing doesn't match the actual contribution, or is too broad/narrow for the target venue.

Mechanism: Complete rewrite of introduction and/or background. Near-zero sentence survival. New version created from scratch rather than editing in place.

Example pattern: "Survey of approaches in domain X" → "Methodology-agnostic layer that addresses specific problem Y."

---

Type 2: Structural Rewrite

What it is: Reorganizing sections — splitting, merging, renaming, reordering — without necessarily changing content substance.

When it fires: When the section structure reflects how the author THOUGHT about the work rather than how the reader needs to RECEIVE it.

Example patterns: Consolidating 4 sections into 2. Splitting a monolithic evaluation into separate sections by claim type. Replacing formal math with a pipeline narrative.

---

Type 3: Background Deletion

What it is: Removing substantial amounts of background/tutorial material that doesn't sharpen the contribution.

When it fires: When background sections are longer than design + evaluation combined, or when they explain concepts the venue audience already knows.

Quantitative signature: The largest single deletions are always tutorial material. Reductions of 50–65% in background sections are common.

---

Type 4: Evaluation Strengthening

What it is: Adding structure, baselines, and narrative control to the evaluation.

When it fires: When results are presented without interpretation, baselines are unnamed, or figure-text inconsistencies exist.

Mechanism: Addition of Takeaway paragraphs, named baselines, formal metrics sections, consistency checks between figures and text.

---

Type 5: Terminology Tightening

What it is: Replacing vague terms with specific, named alternatives.

When it fires: When a term could mean multiple things, or a generic term obscures the specific mechanism.

Example patterns: "heuristics" → "static thresholds, protocol-specific signals, timing-based strategies." "Data generation" → a coined term like "progressive disaggregation."

---

Type 6: Contribution Reframing

What it is: Changing how the contribution list is expressed — from process descriptions to claim-first statements.

When it fires: When contributions read like a task list rather than claims the paper defends.

Example pattern: "We propose a data-driven approach" → "We cast problem X as an optimal stopping problem, exposing the accuracy-cost trade-off as a configurable parameter."

---

Type 7: Argument Clarification

What it is: Adding explicit reasoning that connects claims to evidence.

When it fires: When results are presented without connecting them to design claims.

Mechanism: Adding connecting sentences ("This confirms that...", "The implication is...") between data presentation and interpretation.

---

Intervention Sequence

In practice, these interventions are applied in two passes:

Pass 1 (structural): Types 1, 2, 3, 5, 6 — simultaneously during a major rewrite.

Pass 2 (polish): Types 4, 7, + compression — during the final editing pass.

When simulating advisor feedback, apply the highest-priority type first (framing > structure > terminology), then move to pass 2.

Rhetorical Moves: Cross-Section Summary

Source

Derived from final versions of accepted and rejected papers across systems and ML venues.

---

Introduction (6-Move Sequence)

Critical observation: Move 3 (Key Abstraction) appears ONLY in final versions. It is discovered through writing, not planned before it.

Accepted vs. rejected: Accepted papers have specific stakes and clear named abstractions. Rejected papers have vague or overly abstract stakes.

---

Design (5-Move Sequence)

Anti-patterns: Opening with implementation details (not abstractions). Formal math replacing intuition. Missing the "why" argument.

---

Evaluation (6-Move Sequence)

Evolution: Student drafts use Move 2 only (head-to-head). The advisor adds Moves 3–6. The Takeaway (Move 4) is the signature addition — absent from all early drafts, present in all final versions.

---

Related Work (3-Move Sequence)

Placement: Post-evaluation in systems papers (confidence signal). Integrated into background in ML papers.

Anti-patterns: Exhaustive literature survey (>10K chars). Equal treatment of all categories. Missing the positioning sentence.

---

Cross-Section Coherence Rules

1. Introduction promises = Evaluation delivers: Each contribution maps to a specific evaluation subsection. 2. Key abstraction propagates: The named concept from Introduction Move 3 appears in Design Move 1, Evaluation Move 1, and Related Work Move 3. 3. Heading consistency: If the introduction says "(1) Learning problem. (2) Design. (3) Evaluation.", the section headings reflect this order. 4. Figure-claim linkage: Each evaluation head-to-head or deep dive references a specific figure or table.

Voice Profile

Source

Derived from sentence-level analysis of multiple published papers across systems and ML venues.

---

Sentence-Level Style

Length

• Mean words/sentence in final versions: ~21
• Student drafts average ~24 words/sentence — the advisor compresses by ~12%
• Maximum sentence length in final versions: ~40 words (for contribution-list items)
• Shortest functional unit: single-clause Takeaway sentences

Structure

• Claim-first: Topic sentences lead with the assertion, followed by evidence. State the claim before citing the table or figure.
• Parallel construction in contribution lists: "(1) Learning problem. We formulate... (2) Design. We implement... (3) Evaluation. We demonstrate..."
• Rhetorical questions (sparingly, in introductions only): "Do speed tests need to transmit their full data volume to produce accurate results?"
• Colon elaboration: "Three fundamental limitations: (i) non-stationarity... (ii) no tuning knob... (iii) inability to incorporate..."

Voice markers

• Avoids first-person hedging: rarely "We believe" or "We think" — prefers "We show" or "This confirms"
• Zero exclamation marks in final versions
• Minimal use of "However" as a paragraph opener (used for gap transitions, never as filler)
• Active voice everywhere — no exceptions. "System X achieves" not "accuracy was achieved by System X." "We evaluate on dataset X" not "Experiments were conducted on dataset X." "We collected data from campus gateway" not "Data was collected from campus gateway." Passive voice is never the right choice — it obscures agency and weakens prose.

---

Paragraph Density

Sentences per paragraph

• Introduction labeled blocks: 3–6 sentences (tight, focused)
• Design sections: 4–8 sentences (mechanism explanations need space)
• Evaluation result paragraphs: 3–5 sentences before a Takeaway
• Takeaway paragraphs: 1–3 sentences (maximally compressed)

Information density

• No empty "connector" paragraphs — every paragraph either (a) makes a claim, (b) presents evidence, or (c) synthesizes a takeaway
• Signposting through claims, not placeholders. Sections may open with a preamble that states the section's conclusion or purpose — "This section shows that event-centric decomposition reduces error 13× by analyzing three failure modes." What is banned is content-free preambles — "In this section, we describe our evaluation setup" — which delay the claim without guiding the reader. The test: does the opening sentence tell a skim-reader what the section concludes, or only what it contains?
• Quantitative data density in evaluation: one number per clause, pattern per paragraph, takeaway per experiment cluster

---

Tone

Assertive vs. hedged

• Final versions are strongly assertive: "System X achieves 2–4× higher savings" not "System X appears to offer improved savings"
• Hedging reserved for scope limitations: "Our evaluation focuses on dataset Y" (scoping, not undermining)
• Calibrated confidence: Claims match evidence scope. No "we solve the problem of" — instead "we address [specific aspect] of [bounded problem]"
• Measured academic register in ML venues: slightly less assertive than systems venues

Tonal evolution from student draft to final

---

Vocabulary Patterns

Preferred terms

• Infrastructure language: "layer", "substrate", "abstraction"
• Analysis-of-structure language: "disaggregation", "decomposition"
• Prioritization language: "first-order requirement"
• Design-parameter language: "configurable trade-off"
• Formal precision: "intrinsic evaluation"

Avoided terms (consistently removed in editing)

• "novel" — never in final versions
• "significant" / "substantial" / "impressive" / "promising" — replaced with numbers
• "state-of-the-art" — used only when naming a specific prior system
• "paradigm" / "leverage" / "utilize" — academic filler
• "In this paper, we..." — always removed

Named abstraction coining pattern

• The advisor typically coins 1–2 named abstractions per paper
• Naming convention: compound noun phrase with architectural metaphor (e.g., "external termination layer," "progressive disaggregation," "intrinsic evaluation framework")
• Named abstractions appear ONLY in final versions — they are discovered through writing, not pre-planned

---

Structural Preferences

Labeled paragraphs (systems venues)

• Labels are short imperative phrases: "The opportunity.", "Key contributions.", "Limitations of existing approaches."
• Each label is a narrative contract — what follows must deliver on the label
• Removed for ML venues — replaced with colon-style subtitles

Heading style

• Systems venues: Problem-driven. "Why do linear approaches fail?" / "Taming the tails"
• ML venues: Method-driven. "Embedding Analysis: quantifying representation space utilization"
• Universal: Claim-first in final versions. Never "Section 4" or "Evaluation Results" — always a claim or question

Contribution framing

• Numbered, labeled list: "(1) Learning problem. (2) Design. (3) Evaluation."
• Each item starts with a bold domain label, followed by a claim (not a process description)
• "We show" preferred over "We propose" — positions the paper as delivering evidence, not promises

---

Engineering Specificity

• Named protocols and tools, not generic references (not "network metrics" but "RTT, retransmissions, congestion window")
• Named data sources, not generic references (not "speed tests" but the specific benchmark names)
• Named scales: "2–4×", "65% compression" (not "significantly reduced")
• Architecture as metaphor: "layer" = pluggable component; "substrate" = foundational platform; "framework" = evaluation methodology

Structured Brainstorming: From Unstructured Ideas to a Precise Project Context

Why This Exists

The biggest obstacle for students isn't writing skill — it's that their ideas live as unstructured intuitions. They know something is interesting but can't articulate what or why. This guide walks through a series of pointed questions that force clarity. By the end, you'll have a project_context.md precise enough to drive every section of your paper.

How to use this: Claude will walk you through these questions interactively when you invoke /paper-writing on a new project. Answer honestly — "I don't know" is a valid and useful answer. The questions are designed to reveal gaps early, when they're cheap to fix.

---

Phase 1: Problem Discovery (Before You Think About Your Solution)

Most students skip straight to describing their system. That's backwards. Reviewers care about the problem first. If the problem isn't compelling, nothing else matters.

1.1 The Domain Problem

1. Who is suffering? Name specific actors — not "users" but "network operators at Tier-1 ISPs" or "ML practitioners training models on heterogeneous clusters." If you can't name the actor, you don't know who your work helps.

2. What breaks for them today? Describe the concrete failure mode. Not "things are slow" but "operators must manually inspect 10,000+ time series daily to detect anomalies, and 60% are false positives." Ground it in observable behavior.

3. Why does it break? This is the structural limitation — the root cause that can't be fixed by just "doing more" of the current approach. Is it a fundamental assumption that doesn't hold? A missing abstraction? An architectural mismatch? If the answer is "they just need more data/compute/effort," you may not have a research contribution — you have an engineering task.

4. What happens if nobody solves this? What's the cost of the status quo? Dollar amounts, user impact, operational burden, scientific dead-ends — any concrete consequence. This becomes your opening paragraph's stakes.

1.2 The Intellectual Gap

5. What do existing approaches assume that doesn't hold? Name 2-3 specific systems or methods. For each, identify the assumption they make that fails in your setting. Example: "Chronos2 assumes stationarity, which fails on bursty telemetry where 90% of timestamps are zero." This becomes your Problem Gap (Introduction Move 2).

6. Is the limitation STRUCTURAL or QUANTITATIVE? Structural: "Linear models can't capture event-triggered dynamics." Quantitative: "Existing models only achieve 80% accuracy." Structural limitations motivate new approaches. Quantitative gaps motivate more experiments. If your gap is only quantitative, your paper will face "incremental" criticism.

7. Can you draw a 2×2 matrix of existing approaches? Put approach categories on one axis and capabilities on the other. Where is the empty quadrant? That's your paper's territory. If there's no empty quadrant, your contribution needs to be something other than a new approach (maybe a new understanding, a new benchmark, or a unifying framework).

---

Phase 2: Contribution Crystallization

2.1 The Core Claim

8. Complete this sentence: "This paper shows that ______." Not "proposes" or "introduces" — shows. The verb forces you to state a finding, not an activity. If you can't complete it, you don't yet know your contribution.

9. What is the ONE thing a reader should remember after skimming for 60 seconds? If your answer is a list, you haven't found the core insight yet. Boil it down to one sentence. This becomes your key abstraction (Introduction Move 3).

10. Can you name your core idea in 2-4 words? A compound noun phrase that captures the intellectual contribution. Examples of the pattern: "event-centric decomposition," "progressive disaggregation," "intrinsic evaluation framework." If you can't name it, it isn't crisp enough yet. The name will evolve — but having even a placeholder forces precision.

2.2 Evidence Mapping

11. For each contribution, what is the specific evidence? Fill in this table:

If a claim has no evidence entry, it's an aspiration, not a contribution. Move it to "Open Questions."

12. What is your headline number? The single most impressive quantitative result. "13× error reduction," "44% lower latency," "2× faster search." This goes in the introduction's Results Preview and the abstract. If you don't have one yet, which experiment would produce it?

13. What CAN'T your system do? Every system has limitations. Name them now. Honest limitations in the paper build reviewer trust. Hidden limitations get discovered during review and destroy trust.

---

Phase 3: Evaluation Design (Before Writing Anything)

This is the most important phase. The evaluation determines what claims you can make. Design it before writing a single section.

If you've already been exploring your data using the data-visualization-skill, the iteration you did there — ingesting, exploring, brainstorming what to show and why — has already shaped your understanding of what the data says. Your exploration_log.md captured what the data looked like from multiple angles before you formed hypotheses. Your braindump.md forced you to articulate what question each figure answers and what would surprise you. That exploration is the empirical foundation for the claims you design here. Load those artifacts now: the surprises you found during exploration may be more compelling than the results you expected, and the predictions that failed are often where the real contribution lives.

3.1 Experimental Setup

14. What are your baselines, by name? Not "prior work" or "state-of-the-art." Specific system names. For each baseline, explain WHY it's the right comparison — what does beating this baseline prove?

15. What are your metrics, and why these specific ones? For each metric: what aspect of your claim does it measure? Are there metrics that would make your system look BAD? If so, should you report them anyway? (Usually yes — it builds trust.)

16. What datasets will you use? For each dataset: what makes it appropriate for your claims? Is it publicly available? If not, how will reviewers verify your results? Are there dataset characteristics (size, distribution, domain) that affect generalizability?

3.2 Experiment Planning

17. What experiments do you need, and what does each one prove? Map experiments to claims:

The "what if it fails" column is critical. If an experiment could fail and you have no backup, that claim is at risk.

18. Do you have an ablation plan? Which components of your system can be removed or varied? For each: what does the ablation show? If removing a component doesn't hurt performance, you need to either justify its inclusion or remove it.

19. What's the "honest disaggregation"? Where does your system work BEST and WORST? Breaking results down by meaningful dimensions (difficulty level, data characteristics, edge cases) shows you understand your system. Uniform improvement everywhere is suspicious; nuanced results are convincing.

20. Do you have a robustness/generalization story? Does your system work beyond the specific evaluation setup? New data? New domains? Different parameters? Temporal shift? If not, reviewers will ask "does this generalize?" — have an answer ready.

---

Phase 4: Positioning and Framing

4.1 Venue Fit

21. What venue are you targeting? What is the page limit, deadline, and review process?

22. What type of paper is this? The type constrains the evaluation, the framing, and what reviewers expect. Common types in CS:

Systems papers need more "why this design" arguments. Measurement papers need more "so what" arguments. If your paper doesn't fit neatly into one type, be explicit about which type reviewers will expect — and take extra care with the narrative so they aren't confused about what kind of contribution they're evaluating.

23. Read the last 3 accepted papers in your topic area at this venue. What do they have in common? How long are their evaluations? How many baselines? Do they have systems benchmarks (latency, memory)? Do they have user studies? This calibrates your evaluation ambition.

If you've run a literature survey using the literature-survey-skill, your Pass 3+ paper notes already contain writing craft extractions for the strongest papers in your corpus — introduction anatomy (six-move formula), evaluation architecture, design section craft, and figure design choices. Load those notes now. The craft patterns you extracted from papers you read are the templates for the paper you're about to write. This is where reading and writing reinforce each other: the survey skill teaches you to recognize how the best papers in your area communicate; this skill teaches you to reproduce those patterns in your own work.

4.2 Competitive Positioning

24. Name the 2-3 closest competing works. For each, answer: (a) What is the structural difference between their approach and yours? (b) Is there a scenario where their approach is better than yours? (c) If a reviewer says "how is this different from X?" — what is your one-sentence answer?

25. Are you creating a new category or competing in an existing one? If competing: you need to beat the best in that category convincingly. If creating: you need to define the category clearly and show why existing categories don't cover it. The positioning sentence in your Related Work section depends on this answer.

---

Phase 5: Architecture and Constraints

5.1 Design Decisions

26. What is the high-level architecture? Describe it as a pipeline: "Input → [Stage 1] → [Stage 2] → ... → Output." Name each stage. These names become the vocabulary of your paper.

27. For each major design choice, why this and not the obvious alternative? The "obvious alternative" is whatever a reviewer would try first. If you can't articulate why the simple approach fails, reviewers will wonder why you didn't just do the simple thing.

28. What is the key "knob" in your system? The parameter or trade-off that the user controls. Its existence shows the system isn't one-size-fits-all. If there's no knob, is your system really general enough?

5.2 Scope and Constraints

29. What are the locked decisions — things NOT up for debate? Architecture choices, evaluation setup, dataset selection, venue — anything that's final. Write them down. These prevent revisiting settled questions during writing.

30. What are the genuinely open questions? Things you don't know yet. Experimental results pending, design alternatives still being explored, framing you're unsure about. Separating "locked" from "open" prevents wasted effort.

31. What is your paper's section architecture? Fill in:

---

Phase 6: Narrative Spine

6.1 The Story

32. What is the narrative arc? Every good paper tells a story: "The world has problem X → Existing approaches fail because Y → We observe insight Z → This leads to system W → W achieves [results]." Write yours in 3-4 sentences.

33. What is the "inevitable" moment? The point where your design feels like the only reasonable response to the problem. This comes from showing that the obvious approach fails (Design Move 2). What negative result or failed experiment motivates your approach?

34. If your paper were a tweet, what would it say? Force yourself into ~280 characters. This is your elevator pitch, your abstract's first sentence, and the thing reviewers will remember.

---

After Brainstorming: What Comes Next

Once you've answered these questions, Claude will generate a project_context.md file that captures:

• Your identity sentence (from Q8-10)
• Your venue and constraints (from Q21-22, Q29-30)
• Your contributions as claims with evidence pointers (from Q11-12)
• Your evaluation plan (from Q14-20)
• Your competitive positioning (from Q24-25)
• Your section architecture (from Q31)
• Your locked decisions and open questions (from Q29-30)
• Your key figures needed (from Q31)

This project_context.md becomes the binding contract for all writing sessions. Every time you invoke /paper-writing, Claude reads it and holds you to it. If something changes (new results, revised framing, shifted venue), update the context file — don't just tell Claude in conversation.

See examples/netburst_project_context.md for what a complete, real project context looks like.

Then: Write Draft 0 of the Introduction

Before touching the evaluation, write a Draft 0 introduction — a disposable framing scaffold covering Stakes, Problem Gap, Key Abstraction (placeholder name is fine), Design Intuition, and rough Contributions. Leave the Results Preview blank (you don't have results yet).

Draft 0 is not the introduction. It is a thinking tool. Writing it forces you to commit your framing to concrete prose, which reveals gaps that bullet points in project_context.md hide. It sets guardrails for the evaluation: once you've written "This paper shows that X," you know the evaluation must demonstrate X.

Draft 0 will probably not survive to the final version — and that's the point. The final introduction is rewritten from scratch after the evaluation, constrained by what the evidence actually supports. Draft 0 is reference material for that rewrite, not a starting point for editing.

Figure Synthesis Guide: Non-Data Figures for Systems/Networking Papers

This guide helps synthesize conceptual figures — architecture diagrams, pipeline illustrations, comparison schematics, and other non-data figures. It does NOT handle data figures (CDFs, bar charts, scatter plots, heatmaps) — those go through the data-visualization-skill via /viz.

The boundary: If a figure requires experimental data to render, it goes through /viz. If it illustrates structure, flow, or concepts, it comes here.

Modes

• /paper-writing figure spec — Classify non-data figures, walk through archetype-specific questions, produce a figure_spec.md
• /paper-writing figure generate — Route to AI prompt or TikZ, produce the figure
• /paper-writing figure critique — Review against claims, venue formatting, design principles

Choosing a Mode

When the user asks for help with a non-data figure, assess where they are:

If no project_context.md exists, stop. The student must run the brainstorming workflow first (/paper-writing → brainstorming). Figures cannot be designed in a vacuum — they serve claims, and claims live in the project context.

---

Seven Figure Archetypes

Every non-data figure in a systems/networking paper fits one of these archetypes. The archetype determines which questions to ask in spec mode and which generation backend to use.

The student can override the default backend. If they want TikZ for an architecture overview (for precise control) or AI generation for a taxonomy (for visual richness), respect that choice.

---

Mode 1: Spec — "What does this figure need to show?"

Step 1: Identify Non-Data Figures

Read project_context.md → "Key Figures Needed" section. For each figure listed:

1. Classify as data or non-data. Ask: "Does this figure require experimental data to render?"

• Yes → route to /viz. Tell the student.
• No → continue here.

2. Assign an archetype from the table above. If ambiguous, ask the student. 3. Confirm the generation backend (AI image or TikZ). State the default and let the student override.

Present a summary table:

Step 2: Walk Through Archetype-Specific Questions

For each non-data figure, ask the questions below. Skip questions the student has already answered in project_context.md. Push back on vague answers — every answer should be specific enough to appear in a generation prompt.

Architecture Overview Questions

1. What is the system's name? 2. How many major stages/phases does it have? Name them. 3. What is the input to the first stage? What is the output of the last stage? 4. For each stage: what transformation does it perform? What goes in, what comes out? 5. Which stage is the paper's key contribution? (This gets visual emphasis.) 6. Are there any parallel paths or branches in the pipeline? 7. Are there feedback loops or iterative components? 8. What groupings make sense? (e.g., "Offline training" vs. "Online inference") 9. Does the figure need to show data shapes/dimensions at each stage?

Pipeline / Process Flow Questions

1. What is being transformed? (e.g., "raw time series → event representation") 2. How many transformation steps are there? 3. For each step: what is the operation? Is it standard (off-the-shelf) or novel? 4. Where does the pipeline branch or merge? 5. Should intermediate data representations be shown (e.g., tensor shapes, data examples)? 6. Does the pipeline have a natural direction (left-to-right for temporal, top-to-bottom for processing depth)?

Component Detail Questions

1. Which component from the architecture overview is being expanded? 2. What are the sub-components inside it? 3. What are the internal data flows between sub-components? 4. Are there configurable parameters that should be annotated? 5. What makes this component different from a standard implementation?

Concept Illustration Questions

1. What is the concept you need to illustrate? 2. What is the reader's likely misconception or default mental model? 3. What type of illustration best corrects that misconception?

• Before/after: "Here's the problem state → here's the improved state"
• Spatial analogy: "Think of this as a 2D space where..."
• Visual metaphor: "This works like a funnel / bridge / filter..."
• Process contrast: "Existing approach does X; ours does Y"

4. What are the concrete elements in the illustration? (No abstract blobs — every shape must represent something named.) 5. Where is the "aha moment" — the point where the reader sees why the old way fails?

Comparison Schematic Questions

1. What two approaches are being compared? 2. What is the shared input to both approaches? 3. Where exactly does the existing approach fail? (Name the specific step or assumption.) 4. Where exactly does the proposed approach succeed? (Name the corresponding step.) 5. What structural element is different between the two? (Not just "ours is better" — what specific mechanism differs?) 6. Are there components shared between both approaches? (These should be visually identical.)

Taxonomy / Classification Questions

1. What is being classified? (Papers? Techniques? Systems?) 2. What are the axes or dimensions of classification? 3. Which quadrant/category/branch does this paper occupy? 4. Is the key insight that this paper fills an empty quadrant or creates a new branch? 5. What specific prior works go in each category? (Name them — "Work A [citation]".) 6. Is this a 2x2 matrix, a hierarchical tree, or a Venn diagram?

Deployment / System Diagram Questions

1. What is the deployment environment? (Cloud, edge, campus network, ISP backbone, etc.) 2. What are the infrastructure layers? (Client → Edge → Core → Cloud) 3. What components exist at each layer? 4. What are the network connections? Distinguish data plane from control plane. 5. Are there replication factors, scale indicators, or trust boundaries to show? 6. Where does the paper's system sit in this deployment? (Which component is "ours"?)

Step 3: Generate the Figure Spec

Read figure_templates/figure_spec_template.md. Fill in every field from the student's answers:

1. Identity section: figure ID, section, placement, archetype, backend. 2. Purpose section: copy the claim from project_context.md verbatim. Write the "what it shows" and "why it exists" from the student's answers. 3. Content section: build the Components, Connections, and Groupings tables from the archetype-specific answers. 4. Layout section: flow direction, hierarchy levels, symmetry constraints, size target (from figure_templates/venue_styles.md). 5. Styling section: assign colors from the Paul Tol palette based on semantic roles. Note which component gets emphasis. 6. For AI backend: assemble the generation prompt using the template from figure_templates/prompt_templates.md. Fill all placeholders. Append the styling block from venue_styles.md. 7. For TikZ backend: note which skeleton from figure_templates/tikz_skeletons.md to start from. 8. Caption: draft an interpretive caption following voice_profile.md rules — claim-first, states the takeaway.

Save the completed spec as figure_spec_[fig_id].md in the paper's figures/ directory (create the directory if needed).

Tell the student: "Figure spec saved to figures/figure_spec_[fig_id].md. Run /paper-writing figure generate to produce the figure."

---

Mode 2: Generate — "Produce the figure"

Step 1: Read the Figure Spec

Load figures/figure_spec_[fig_id].md. Verify all required fields are populated. If any are missing, return to spec mode for that field.

Step 2: Route by Backend

Manual Or Local Figure Path

1. Read the assembled prompt from the spec's "Generation prompt" field. 2. Do not call external image-generation APIs or check for image API keys from this skill. 3. Prefer reproducible local figure creation with TikZ, matplotlib, PowerPoint shapes, or a user-provided drawing tool. 4. If an AI image prompt is useful, present the prompt text only and let the user decide whether to use an external service. 5. After the user provides a generated image or a local draft, proceed to critique mode.

Iteration: If the first result is unsatisfactory, refine the prompt:

• Be more specific about spatial layout ("component A is directly above component B, connected by a downward arrow")
• Add negative instructions ("do NOT show component X as a circle, use a rectangle")
• Adjust emphasis ("make the contribution component 1.5x larger than the others")
• Cap at 3 prompt iterations before suggesting manual refinement in a drawing tool.

TikZ Path

1. Read the archetype from the spec. Load the corresponding skeleton from figure_templates/tikz_skeletons.md. 2. Customize the skeleton:

• Replace placeholder nodes with the actual components from the spec.
• Set colors from the spec's color mapping.
• Adjust layout (node distances, positioning) to fit the actual component count.
• Add all connections, groupings, and annotations from the spec.
• Set the figure width to match the venue target from figure_templates/venue_styles.md.

3. Write the TikZ code to figures/fig_[short_id].tex. 4. Compile (if pdflatex is available):

   cd figures && pdflatex -interaction=nonstopmode fig_[short_id].tex

• If compilation fails, read the error log, fix the TikZ code, and retry (max 3 attempts).
• If compilation succeeds, display the PDF for the student to review.

5. If `pdflatex` is not available:

• Present the TikZ code to the student.
• Instruct them to compile in Overleaf or their local TeX installation.

Step 3: Update the Spec

After generation, update the figure_spec.md:

• Set "Generated: yes" with today's date
• For TikZ: record the source file path
• For AI: save the successful prompt version and the output image path

Tell the student: "Figure generated. Run /paper-writing figure critique to review it against your paper's claims and venue standards."

---

Mode 3: Critique — "Does this figure serve the paper?"

Step 1: Load Context

Read all of:

• The figure_spec.md for this figure
• The generated figure (image or compiled PDF)
• The paper's project_context.md
• figure_templates/venue_styles.md for formatting standards

Step 2: Run Five Checks

Check 1: Claim Alignment

• Does the figure support the specific claim listed in the spec's "Paper claim supported" field?
• Could a reader understand the claim from the figure alone (with caption)?
• Does the figure show anything that contradicts or weakens the claim?
• Verdict: PASS / REVISE (with specific fix)

Check 2: Completeness

• Are all components from the spec present in the figure?
• Are all connections shown?
• Are all groupings visible?
• Are labels legible and correctly spelled?
• Is the key contribution component visually prominent?
• Verdict: PASS / REVISE (list missing elements)

Check 3: Venue Formatting

• Does the figure fit the target column width without rescaling below legibility?
• Is text at least 8pt at print size?
• Is the background white?
• Are colors from the approved palette?
• Would the figure be readable in grayscale?
• Verdict: PASS / REVISE (list violations)

Check 4: Design Principles

• Data-ink ratio (Tufte): Is every visual element encoding information? Remove decorative borders, background fills, and chrome that don't carry meaning.
• Self-containment: Can a reader understand the high-level flow without reading the paper body?
• Simplicity: Could any component be removed without losing information? If yes, remove it.
• Consistency: Does the style match other figures in this paper? (Same fonts, colors, line weights, node shapes.)
• Verdict: PASS / REVISE (list violations)

Check 5: Caption Quality

• Is the caption interpretive (states what the figure shows and why it matters)?
• Is it claim-first (the takeaway leads, details follow)?
• Does it follow voice_profile.md rules (no hedging, no filler adjectives, active voice)?
• Is it self-contained enough for a skim-reader?
• Verdict: PASS / REVISE (suggest rewrite)

Step 3: Produce Critique Report

Present results as a table:

Overall verdict:

• PASS — all checks pass. The figure is ready for inclusion.
• REVISE — one or more checks failed. List the specific action items and suggest re-running generate mode with updated spec/prompt.

Step 4: Update the Spec

After critique, update the figure_spec.md:

• Set "Critique passed: yes/no"
• Record iteration notes (what needs to change for the next version)

---

Cross-Figure Consistency

When a paper has multiple non-data figures, enforce consistency across all of them:

1. Color semantics: If blue represents "our system" in Figure 1, it must represent "our system" in all figures. Document the color-to-meaning mapping in the first figure_spec.md and reference it from all others. 2. Node shapes: Consistent shape vocabulary across figures (rectangles for processing stages, cylinders for data stores, diamonds for decision points). 3. Font and line weight: Identical across all figures — use the shared styles from venue_styles.md. 4. Naming: The same component must have the same label in every figure. If the architecture overview calls it "Event Encoder," the component detail figure must also call it "Event Encoder." 5. Level of detail: Figures at the same level of abstraction should have similar visual complexity. An architecture overview shouldn't be more detailed than a component detail figure.

When critiquing any figure after the first, check consistency against all previously critiqued figures.

---

Integration with the Paper Pipeline

This guide connects to the paper-writing pipeline at three points:

Stage 2 (Architecture): When building the section architecture table, classify each figure from "Key Figures Needed" as data (→ /viz) or non-data (→ spec mode here). Run spec mode for all non-data figures during this stage.

Stage 3 (Section Drafts): When drafting the Design section, the architecture overview figure should already exist. Design Move 3 (Component Architecture) uses it as structural scaffolding — each subsection corresponds to a component in the overview figure. If the figure doesn't exist yet, generate it before drafting.

Stage 4 (Integration): During the cross-section consistency pass, run critique mode on all non-data figures. Check visual balance, claim alignment, and cross-figure consistency.

Figure Spec: [Figure Name]

<!-- This template captures everything needed to generate a non-data figure. --> <!-- Fill it in by running /paper-writing figure spec mode, or manually. -->

Identity

• Figure ID: fig:[short_id] (matches \label{fig:short_id} in LaTeX)
• Paper section: [e.g., §3 Design]
• Placement: [full-width (figure*) / single-column (figure)]
• Archetype: [architecture_overview | pipeline_flow | component_detail | concept_illustration | comparison_schematic | taxonomy | deployment_diagram]
• Generation backend: [ai_image | tikz]

Purpose

• Paper claim supported: [the exact claim from project_context.md this figure serves]
• What it shows: [1-2 sentences — what should the reader understand after looking at this figure?]
• Why this figure exists: [what would be lost if it were removed?]
• Role in narrative: [motivation | design explanation | evidence summary | positioning]

Content Specification

Components

Connections

Groupings

Annotations

<!-- Callout boxes, dimension labels, example data snippets, or emphasis markers -->

• [annotation 1]
• [annotation 2]

Layout

• Flow direction: [left-to-right / top-to-bottom / radial]
• Hierarchy levels: [how many vertical or horizontal tiers]
• Symmetry constraints: [any components that must be visually parallel, e.g., "encoder and decoder are symmetric"]
• Size target: [single-column (3.33in) / full-width (7.0in) — adjust per venue from venue_styles.md]

Styling

• Color mapping: [which semantic category maps to which palette color]
• Emphasis: [which component is the paper's key contribution — should be visually prominent via color, border weight, or size]
• Consistency notes: [references to other figures in this paper whose style this must match]

Generation

For AI image backend

Assembled prompt:

<!-- Claude fills this in during generate mode by combining the content spec above --> <!-- with the AI prompt styling block from venue_styles.md. --> <!-- The student can also paste this prompt directly into Gemini/DALL-E. -->

[Full generation prompt goes here]

For TikZ backend

TikZ source: [path to generated .tex file, e.g., figures/fig_pipeline.tex]

Caption

<!-- Interpretive, claim-first. States the takeaway, not just a description. --> <!-- "NetBurst's three-stage pipeline transforms raw time series into event-centric --> <!-- representations, enabling per-event feature extraction (§3.2) and embedding-based --> <!-- similarity search (§3.3)." -->

Draft caption: [...]

Status

• Spec complete: [yes / no]
• Generated: [yes / no — date if yes]
• Critique passed: [yes / no]
• Iteration notes: [what changed between versions]

AI Image Generation Prompt Templates

These templates produce prompts for Gemini, DALL-E, or other image generation models. Each template has a skeleton (the structure with placeholders) and assembly instructions (how to fill it from a figure_spec.md).

The AI prompt styling block from venue_styles.md is appended to every prompt automatically. Do not duplicate styling instructions inside the archetype-specific content.

---

Architecture Overview

When to use: Full system pipeline showing end-to-end data flow through named stages. Typically the first figure in the Design section, spanning full page width.

Skeleton:

Create a clean, professional architecture diagram for a systems research paper.

SYSTEM NAME: {{system_name}}

OVERALL FLOW: {{flow_direction — e.g., "left to right" or "top to bottom"}}

COMPONENTS (in order of data flow):
{{for each component in figure_spec.components:}}
- [{{component.label}}]: {{component.description}}. Shape: {{component.shape}}. Color: {{component.color}}.
{{end for}}

DATA FLOW CONNECTIONS:
{{for each connection in figure_spec.connections:}}
- {{connection.from}} → {{connection.to}}: "{{connection.label}}" ({{connection.style}} arrow)
{{end for}}

GROUPINGS (draw dashed boundary boxes around these sets):
{{for each group in figure_spec.groupings:}}
- "{{group.label}}": contains [{{group.contains}}]
{{end for}}

KEY CONTRIBUTION: The component [{{emphasis_component}}] is the paper's main contribution — make it visually prominent (thicker border, slightly larger, brighter color).

ANNOTATIONS:
{{for each annotation in figure_spec.annotations:}}
- {{annotation}}
{{end for}}

SIZE: {{width}} inches wide, suitable for a two-column academic paper (full-width figure).

{{VENUE_STYLING_BLOCK from venue_styles.md}}

Assembly instructions: 1. Read the figure_spec.md's Components, Connections, and Groupings tables 2. Identify which component is the key contribution (from the Styling → Emphasis field) 3. Set flow direction from Layout → Flow direction 4. Set width from Layout → Size target (typically 7.0in for architecture overview) 5. Append the AI prompt styling block from venue_styles.md

---

Concept Illustration

When to use: Making an abstract concept concrete through visual metaphor, before/after comparison, or spatial analogy. Typically in Background or Motivation sections.

Skeleton:

Create a concept illustration for a systems research paper.

CONCEPT: {{concept_name}}

ILLUSTRATION TYPE: {{one of: before_after | spatial_analogy | visual_metaphor | process_contrast}}

{{if before_after:}}
LEFT PANEL ("Before" / "Problem"):
- Title: "{{before_title}}"
- Show: {{description of the problematic state}}
- Visual elements: {{what to draw — e.g., "scattered points with no structure, arrows pointing in random directions"}}
- Color: use red (#EE6677) and grey (#BBBBBB) to convey the problem

RIGHT PANEL ("After" / "Solution"):
- Title: "{{after_title}}"
- Show: {{description of the improved state}}
- Visual elements: {{what to draw — e.g., "organized clusters with clear boundaries, arrows aligned"}}
- Color: use blue (#4477AA) and green (#228833) to convey the solution

DIVIDING ELEMENT: {{arrow, vertical line, or transformation symbol between panels}}
{{end if}}

{{if spatial_analogy:}}
SPACE: {{describe the conceptual space — e.g., "2D embedding space"}}
ELEMENTS IN SPACE:
{{list of elements and their spatial positions/relationships}}
KEY INSIGHT: {{what the spatial arrangement reveals — e.g., "similar items cluster, dissimilar items separate"}}
{{end if}}

{{if visual_metaphor:}}
METAPHOR: {{the analogy — e.g., "funnel" for progressive filtering, "bridge" for connecting domains}}
CONCRETE MAPPING:
- {{metaphor element 1}} represents {{technical concept 1}}
- {{metaphor element 2}} represents {{technical concept 2}}
AVOID: Do not make the metaphor cartoonish. Keep it abstract and geometric.
{{end if}}

{{if process_contrast:}}
TOP ROW ("Existing Approach"):
- Steps: {{step 1}} → {{step 2}} → {{step 3}}
- Outcome: {{what goes wrong}}
- Mark the failure point with a red X or broken arrow

BOTTOM ROW ("Our Approach"):
- Steps: {{step 1}} → {{step 2}} → {{step 3}}
- Outcome: {{what succeeds}}
- Mark the success with a green checkmark

ALIGNMENT: Both rows should be horizontally aligned so the reader can compare step-by-step.
{{end if}}

SIZE: {{width}} inches wide.

{{VENUE_STYLING_BLOCK from venue_styles.md}}

Assembly instructions: 1. Determine the illustration type from figure_spec.md's Content section 2. Fill in the appropriate conditional block 3. For before/after: the "before" state should match the Problem Gap from project_context.md; the "after" state should match the key contribution 4. Keep the illustration abstract and geometric — no realistic imagery

---

Comparison Schematic

When to use: Side-by-side showing why the existing approach fails and the proposed approach works. Motivation or design justification sections.

Skeleton:

Create a comparison diagram for a systems research paper showing two approaches side by side.

LEFT SIDE — "{{existing_approach_name}}" (the limitation):
- Components: {{list of components in the existing approach}}
- Data flow: {{how data moves through the existing approach}}
- FAILURE POINT: {{where and why it breaks — mark with red (#EE6677)}}
- Label: "{{short failure description — e.g., 'Misses bursty patterns'}}"

RIGHT SIDE — "{{proposed_approach_name}}" (the solution):
- Components: {{list of components in the proposed approach}}
- Data flow: {{how data moves through the proposed approach}}
- SUCCESS POINT: {{where the improvement happens — mark with green (#228833)}}
- Label: "{{short success description — e.g., 'Captures event boundaries'}}"

SHARED ELEMENTS:
- Both sides receive the same input: {{input description}}
- Both sides produce: {{output description}}
- Align shared elements horizontally so the structural difference is immediately visible

VISUAL CUES:
- Use a vertical dividing line or "vs." marker between the two sides
- Matching components (same in both approaches) should have the same position and grey color
- Differing components should be highlighted in their respective colors (red for problem, blue/green for solution)

SIZE: {{width}} inches wide (typically full-width for maximum clarity).

{{VENUE_STYLING_BLOCK from venue_styles.md}}

Assembly instructions: 1. The left side comes from the Problem Gap in project_context.md — the structural limitation of existing work 2. The right side comes from the key contribution — the insight that fixes the limitation 3. Shared elements should be visually identical to emphasize that the difference is surgical, not wholesale

---

Deployment / System Diagram

When to use: Physical or logical arrangement of infrastructure components. Systems evaluation or background sections showing how the system is deployed in practice.

Skeleton:

Create a system deployment diagram for a systems/networking research paper.

DEPLOYMENT CONTEXT: {{e.g., "distributed measurement infrastructure" or "cloud-edge pipeline"}}

INFRASTRUCTURE LAYERS (top to bottom or left to right):
{{for each layer:}}
### {{layer_name}} (e.g., "Client tier", "Edge tier", "Cloud tier")
Components:
{{for each component in layer:}}
- [{{component.label}}]: {{component.description}}. Icon style: {{server / database / router / switch / cloud / mobile / container}}.
{{end for}}
{{end for}}

NETWORK CONNECTIONS:
{{for each connection:}}
- {{from}} ↔ {{to}}: {{protocol or description}} ({{style: solid for data plane, dashed for control plane}})
{{end for}}

ANNOTATIONS:
- Latency/bandwidth labels on key links: {{list}}
- Replication indicators: {{e.g., "×3 replicas" near a database component}}
- Trust boundaries: {{dashed boxes separating trusted from untrusted zones}}

SCALE INDICATORS: {{e.g., "N clients", "K edge nodes"}}

SIZE: {{width}} inches wide.

{{VENUE_STYLING_BLOCK from venue_styles.md}}

Assembly instructions: 1. Identify the deployment topology from project_context.md or the Design section outline 2. Use standard infrastructure icon styles (box=server, cylinder=database, cloud shape=cloud service, diamond=router) 3. Distinguish data plane (solid) from control plane (dashed) connections 4. Mark the paper's contribution within the deployment (thicker border, brighter color)

---

Assembling the Final Prompt

When Claude runs generate mode, it:

1. Reads the figure_spec.md for the target figure 2. Selects the matching archetype template from this file 3. Fills in all {{placeholders}} from the spec 4. Appends the AI prompt styling block from venue_styles.md 5. Presents the assembled prompt to the student

The student can then:

• Paste the prompt into Gemini (recommended: gemini-2.5-flash-image or later)
• Paste into DALL-E or another image generation tool
• Use the prompt as a brief for manual creation in Figma, draw.io, or Inkscape
• Run it through a local script if they have API access configured

If the student has a Gemini API key available, Claude can generate the figure directly by running a Python script:

# Requires: pip install google-genai
from google import genai
client = genai.Client()
response = client.models.generate_images(
    model="gemini-2.0-flash-exp",  # or latest image-capable model
    prompt=assembled_prompt,
    config=genai.types.GenerateImagesConfig(number_of_images=1)
)
# Save the image
response.generated_images[0].image.save("figures/fig_name.png")

TikZ Skeletons by Archetype

These are starter templates for the TikZ-default archetypes. Each skeleton compiles standalone and follows the venue styling from venue_styles.md. Replace placeholder content with figure-specific components from the figure_spec.md.

---

Pipeline / Process Flow

Sequential transformation of data through stages. Vertical or horizontal. Each stage shows input shape → transformation → output shape.

\documentclass[border=5pt]{standalone}
\usepackage[dvipsnames]{xcolor}
\usepackage{tikz}
\usetikzlibrary{positioning, arrows.meta, shapes.geometric, fit, calc}

% Paul Tol bright palette
\definecolor{ptblue}{HTML}{4477AA}
\definecolor{ptcyan}{HTML}{66CCEE}
\definecolor{ptgreen}{HTML}{228833}
\definecolor{ptgrey}{HTML}{BBBBBB}

\begin{document}
\begin{tikzpicture}[
    node distance=0.6cm and 1.8cm,
    stage/.style={rectangle, draw, rounded corners=3pt, thick,
        minimum width=2.2cm, minimum height=0.7cm,
        font=\small\sffamily},
    data/.style={font=\footnotesize\sffamily, text=gray!60!black},
    arrow/.style={-{Stealth[length=5pt]}, thick},
]

% --- Stages (left to right) ---
\node[stage, fill=ptblue!15] (s1) {Stage 1};
\node[stage, fill=ptcyan!15, right=of s1] (s2) {Stage 2};
\node[stage, fill=ptgreen!15, right=of s2] (s3) {Stage 3};

% --- Data annotations between stages ---
\node[data, above=0.15cm of s1.west, anchor=south west] {Raw input};
\draw[arrow] (s1) -- node[data, above] {intermediate} (s2);
\draw[arrow] (s2) -- node[data, above] {transformed} (s3);
\node[data, above=0.15cm of s3.east, anchor=south east] {Output};

% --- Input/output markers ---
\draw[arrow, ptgrey] ([xshift=-1cm]s1.west) -- (s1.west);
\draw[arrow, ptgreen] (s3.east) -- ([xshift=1cm]s3.east);

\end{tikzpicture}
\end{document}

Customization points:

• Add/remove stage nodes as needed
• Add data shape annotations (e.g., "[N x D tensor]") as data nodes
• For vertical flow, change right=of to below=of and adjust arrow directions
• Add branching with additional nodes positioned above/below the main flow

---

Component Detail

Zoomed view of a single pipeline component showing internal structure. Uses nested boxes to show sub-components.

\documentclass[border=5pt]{standalone}
\usepackage[dvipsnames]{xcolor}
\usepackage{tikz}
\usetikzlibrary{positioning, arrows.meta, fit, backgrounds}

\definecolor{ptblue}{HTML}{4477AA}
\definecolor{ptcyan}{HTML}{66CCEE}
\definecolor{ptgreen}{HTML}{228833}
\definecolor{ptgrey}{HTML}{BBBBBB}

\begin{document}
\begin{tikzpicture}[
    node distance=0.5cm and 0.8cm,
    subcomp/.style={rectangle, draw, rounded corners=2pt,
        minimum width=1.8cm, minimum height=0.6cm,
        font=\footnotesize\sffamily, thick},
    arrow/.style={-{Stealth[length=4pt]}, thick},
    label/.style={font=\footnotesize\sffamily\bfseries},
]

% --- Sub-components ---
\node[subcomp, fill=ptblue!15] (a) {Sub-component A};
\node[subcomp, fill=ptcyan!15, right=of a] (b) {Sub-component B};
\node[subcomp, fill=ptgreen!15, below right=0.8cm and 0cm of $(a)!0.5!(b)$] (c) {Sub-component C};

% --- Internal connections ---
\draw[arrow] (a) -- (b);
\draw[arrow] (a) |- (c);
\draw[arrow] (b) |- (c);

% --- Outer boundary ---
\begin{scope}[on background layer]
\node[draw=ptblue, thick, dashed, rounded corners=5pt,
    fit=(a)(b)(c), inner sep=10pt,
    label={[label, anchor=south]above:Component Name}] {};
\end{scope}

% --- Input/output ---
\draw[arrow, ptgrey] ([xshift=-1.2cm]a.west) -- (a.west)
    node[pos=0, left, font=\footnotesize\sffamily] {Input};
\draw[arrow, ptgreen] (c.east) -- ([xshift=1.2cm]c.east)
    node[pos=1, right, font=\footnotesize\sffamily] {Output};

\end{tikzpicture}
\end{document}

Customization points:

• Add/remove sub-components
• Adjust layout (vertical vs. horizontal internal flow)
• Add parameter annotations next to sub-components
• Use fill colors to indicate which sub-components are novel vs. standard

---

Taxonomy / Classification

2x2 matrix or hierarchical categorization. Use for positioning figures in related work or background sections.

2x2 Matrix Variant

\documentclass[border=5pt]{standalone}
\usepackage[dvipsnames]{xcolor}
\usepackage{tikz}
\usetikzlibrary{positioning, calc}

\definecolor{ptblue}{HTML}{4477AA}
\definecolor{ptcyan}{HTML}{66CCEE}
\definecolor{ptgreen}{HTML}{228833}
\definecolor{ptred}{HTML}{EE6677}
\definecolor{ptgrey}{HTML}{BBBBBB}

\begin{document}
\begin{tikzpicture}[
    cell/.style={rectangle, draw, rounded corners=2pt, thick,
        minimum width=3cm, minimum height=1.5cm,
        font=\small\sffamily, align=center},
    axislabel/.style={font=\small\sffamily\bfseries},
    entry/.style={font=\footnotesize\sffamily},
]

% --- Quadrant cells ---
\node[cell, fill=ptblue!10] (q1) at (0, 0) {Quadrant 1\\[2pt] {\footnotesize Work A, Work B}};
\node[cell, fill=ptcyan!10] (q2) at (3.5, 0) {Quadrant 2\\[2pt] {\footnotesize Work C}};
\node[cell, fill=ptred!10] (q3) at (0, -2) {Quadrant 3\\[2pt] {\footnotesize Work D, Work E}};
\node[cell, fill=ptgreen!15, line width=1.2pt] (q4) at (3.5, -2)
    {\textbf{This paper}\\[2pt] {\footnotesize (empty quadrant)}};

% --- Axis labels ---
\node[axislabel, above=0.3cm of $(q1.north)!0.5!(q2.north)$] {Dimension X};
\node[axislabel, rotate=90, left=0.3cm of $(q1.west)!0.5!(q3.west)$] {Dimension Y};

% --- Axis value labels ---
\node[entry, above=0.05cm of q1.north] {Low X};
\node[entry, above=0.05cm of q2.north] {High X};
\node[entry, rotate=90, left=0.05cm of q1.west] {High Y};
\node[entry, rotate=90, left=0.05cm of q3.west] {Low Y};

\end{tikzpicture}
\end{document}

Hierarchical Tree Variant

\documentclass[border=5pt]{standalone}
\usepackage[dvipsnames]{xcolor}
\usepackage{tikz}
\usetikzlibrary{positioning, arrows.meta}

\definecolor{ptblue}{HTML}{4477AA}
\definecolor{ptcyan}{HTML}{66CCEE}
\definecolor{ptgreen}{HTML}{228833}
\definecolor{ptgrey}{HTML}{BBBBBB}

\begin{document}
\begin{tikzpicture}[
    node distance=0.6cm and 1.5cm,
    cat/.style={rectangle, draw, rounded corners=3pt, thick,
        minimum width=2cm, minimum height=0.6cm,
        font=\small\sffamily},
    leaf/.style={rectangle, draw, rounded corners=2pt,
        minimum width=1.6cm, minimum height=0.5cm,
        font=\footnotesize\sffamily},
    edge/.style={thick},
]

% --- Root ---
\node[cat, fill=ptblue!15] (root) {Category};

% --- Level 1 ---
\node[cat, fill=ptcyan!15, below left=0.8cm and 1.5cm of root] (l1a) {Subcategory A};
\node[cat, fill=ptcyan!15, below right=0.8cm and 1.5cm of root] (l1b) {Subcategory B};

% --- Leaves ---
\node[leaf, fill=ptgrey!20, below left=0.6cm and 0.3cm of l1a] (w1) {Work 1};
\node[leaf, fill=ptgrey!20, below right=0.6cm and 0.3cm of l1a] (w2) {Work 2};
\node[leaf, fill=ptgreen!20, line width=1.2pt, below=0.6cm of l1b] (ours) {\textbf{This paper}};

% --- Edges ---
\draw[edge] (root) -- (l1a);
\draw[edge] (root) -- (l1b);
\draw[edge] (l1a) -- (w1);
\draw[edge] (l1a) -- (w2);
\draw[edge] (l1b) -- (ours);

\end{tikzpicture}
\end{document}

Customization points:

• 2x2: Change axis dimensions and quadrant labels to match your positioning argument
• 2x2: Bold-border the quadrant where your paper sits (the "empty quadrant" claim)
• Tree: Add/remove levels and leaves
• Tree: Annotate edges with the distinguishing property (e.g., "statistical" vs. "learned")

Venue-Specific Figure Styling Defaults

These defaults apply to ALL non-data figures (both AI-generated and TikZ). They ensure figures match the paper's formatting and print correctly.

---

Column Widths

Architecture overview figures almost always span full width (double column). Pipeline details and component diagrams fit single column.

Font Rules

• Body text in figure labels must be legible at print size: 8 pt minimum, 9 pt preferred.
• Match the paper's body font family where possible:
• USENIX: Times / Linux Libertine
• ACM: Times New Roman
• IEEE: Times New Roman
• Sans-serif (Helvetica, CMSans) is acceptable for diagram labels and annotations — it improves readability inside boxes and along arrows.
• Bold only for the figure's title element or the component representing the paper's key contribution.

Color Palette

Use the Paul Tol "bright" palette — colorblind-safe and print-friendly:

Rules:

• Maximum 5-6 distinct colors per figure.
• Use grey for elements that provide context but are not the focus.
• The paper's key contribution component should use the most visually prominent color (Blue or Green).
• Reserve Red for problem/failure states in comparison schematics.

Line and Shape Standards

TikZ Preamble (for TikZ-backend figures)

\usepackage[dvipsnames]{xcolor}
\usepackage{tikz}
\usetikzlibrary{positioning, arrows.meta, shapes.geometric, fit, calc, backgrounds}

% Paul Tol bright palette
\definecolor{ptblue}{HTML}{4477AA}
\definecolor{ptcyan}{HTML}{66CCEE}
\definecolor{ptgreen}{HTML}{228833}
\definecolor{ptyellow}{HTML}{CCBB44}
\definecolor{ptred}{HTML}{EE6677}
\definecolor{ptpurple}{HTML}{AA3377}
\definecolor{ptgrey}{HTML}{BBBBBB}

% Standard node styles
\tikzset{
    component/.style={rectangle, draw, rounded corners=3pt,
        minimum width=2cm, minimum height=0.8cm,
        font=\small\sffamily, thick},
    arrow/.style={-{Stealth[length=5pt]}, thick},
    dashedarrow/.style={-{Stealth[length=5pt]}, dashed},
    group/.style={draw=gray!50, dashed, rounded corners=5pt, inner sep=8pt},
    annotation/.style={font=\footnotesize\sffamily, text=gray!70!black},
}

AI Prompt Styling Block

Inject this block into every AI image generation prompt to ensure venue-appropriate output:

STYLING REQUIREMENTS (non-negotiable):
- Pure white background (#FFFFFF)
- Clean, professional academic style suitable for a top-tier systems/networking venue (NSDI, SIGCOMM, IMC)
- All text labels must be crisp, readable, and at least 8pt equivalent at print size
- Use sans-serif font for all labels and annotations
- Color palette: blue (#4477AA) for primary components, cyan (#66CCEE) for secondary,
  green (#228833) for outputs, grey (#BBBBBB) for context/background elements
- Maximum 5-6 distinct colors
- Solid lines for data flow arrows (0.75pt), dashed for control flow (0.5pt)
- No gradients, no drop shadows, no 3D effects, no decorative elements
- No clip art, no stock imagery, no photorealistic elements
- Every visual element must encode information — nothing purely decorative
- Rounded corners on component boxes (3pt radius)
- Filled arrowheads on all directional arrows
- Group related components with dashed boundary boxes and phase/stage labels
- The figure must be self-contained: a reader should understand the high-level flow without reading the paper

Print Safety Checklist

Before finalizing any figure, verify: 1. Readable in grayscale (not just color) — shapes and labels distinguish components, not only color 2. Text legible at 50% zoom (simulates print at column width) 3. No thin hairlines that may vanish in print (minimum 0.5pt) 4. White background (no transparency issues in PDF embedding) 5. Aspect ratio fits the target column width without scaling below legibility

Writing a Design Section: The 5-Move Sequence

Overview

The design section answers "How should the reader think about this system?" before "How does it work internally?" Lead with the abstraction, not the implementation.

---

Move 1: Abstraction Introduction

Function: Present the user-facing mental model before any implementation detail.

How to do it: Open with what users reason about, not what the system computes. Name the core abstraction — this is the intellectual contribution. The implementation is the engineering contribution.

Test: Does the section open with the system's core abstraction (named, defined)?

---

Move 2: Design Justification (The "Why" Move)

Function: Explain why this particular design was chosen over alternatives.

How to do it: Often takes the form of a negative result: "We tried the obvious approach (linear method / monolithic design / single-stage pipeline) and it fails because X." This makes the chosen design feel INEVITABLE rather than arbitrary.

Test: For every major design choice, is there a "why" argument? Does the section explain why alternatives were rejected?

---

Move 3: Component Architecture

Function: Decompose the system into named stages/modules.

How to do it: Always a pipeline or structured flow the reader can trace. Each component gets a name that reflects its function. Component names become the vocabulary the evaluation section uses.

Pattern: Overview figure → subsection per component. Each subsection explains one component.

---

Move 4: Key Design Decision (The "Knob" Move)

Function: Identify the critical parameter or trade-off the user controls.

How to do it: Every non-trivial system has at least one configurable parameter whose existence demonstrates the system isn't one-size-fits-all. Name it, explain it, show how it affects behavior.

Test: Is there a parameter whose adjustment reveals a meaningful trade-off?

---

Move 5: Robustness / Edge Cases

Function: Address what happens when assumptions fail.

How to do it: Often added late, per reviewer or advisor feedback. Common elements: safety mechanisms for edge cases, sensitivity to key parameters, handling of distribution shift.

Its presence signals defensive design awareness. Its absence is a common reviewer concern.

---

Anti-Patterns to Avoid

1. Opening with infrastructure: Don't start with an implementation detail ("Generating realistic data..."). Start with the abstraction ("Programming model for expressing...").

2. Formal math replacing intuition: Dense mathematical formulation without a pipeline narrative. The math should survive but be subordinated to the flow.

3. Missing the "why": Presenting "Abstract X / Concrete X" — the WHAT without the WHY. Add the justification: "Why does the simple approach fail?"

---

The What → Why → So-What Test (Principle 3)

For each subsection, check which level the heading achieves:

• WHAT (minimum): "System Architecture" — names the topic
• WHY (better): "Why do linear approaches fail?" — argues for the design
• SO-WHAT (best): "Nondeterminism as a first-order requirement" — states the implication

Target: SO-WHAT headings for all subsections.

Writing an Evaluation: The 6-Move Sequence

Overview

The evaluation is where the paper earns its claims. Student drafts typically use only Move 2 (head-to-head comparison). Adding Moves 3–6 is what transforms a lab notebook into a conference paper.

---

Move 1: Setup Anchoring

Function: Establish dataset, baselines, and metrics in compact form.

How to do it: Use labeled paragraphs (Datasets / Baselines / Metrics) — one paragraph each. Compress ruthlessly: just enough for reproducibility, not a technical report.

Common mistake: The setup section is bloated with hardware specs and software versions. In final versions, this is a few labeled blocks, not a multi-page section.

---

Move 2: Head-to-Head Comparison

Function: Compare the proposed system directly against named baselines.

How to do it: Baselines must be NAMED (not "prior work" or "state-of-the-art"). Tables and figures are dense here. The comparison uses the exact metrics defined in setup.

This is the core evidence. If your head-to-head doesn't support a claim from the introduction, either the claim or the experiment needs to change.

---

Move 3: Deep Dive / Disaggregation

Function: Break down results by meaningful dimensions to show WHO benefits and WHEN.

How to do it: Disaggregate by relevant conditions (e.g., by difficulty level, data characteristics, geographic region, user type). Show where the system helps MOST and LEAST.

Why it matters: Honest disaggregation actually STRENGTHENS the paper by showing nuanced understanding. Reviewers trust authors who acknowledge their system doesn't uniformly excel.

Connection to data exploration: If you used the data-visualization-skill, the Explore phase already forced you to look at your data from multiple angles before forming hypotheses. The surprises you found — distributions that weren't what you expected, subgroups that behaved differently, outliers you couldn't explain — are the raw material for the Deep Dive. The predictions you wrote in braindump.md and then confronted in the Analyze phase tell you exactly where your system's behavior diverges from expectation. That divergence is the Deep Dive.

---

Move 4: Takeaway Synthesis

Function: After each experiment cluster, state what was learned.

How to do it: An explicit "Takeaway." paragraph that states the IMPLICATION, not just the result. The Takeaway ties results back to a specific design claim or contribution.

This is the most important advisor convention. It is absent from all student drafts and present in all accepted papers. The Takeaway is where the author controls the reader's interpretation.

Test: Is the Takeaway interpretable without reading the detailed results? Does it tie back to a contribution?

From WALTER to Takeaway: If you've run the data-visualization-skill's Analyze phase, each figure already has a WALTER narration — Hypothesis, Axes, Look here, Trend, Exception, Result. The R (Result) of a WALTER narration is a first draft of the Takeaway paragraph for that experiment cluster. The WALTER forces you to articulate what the figure means before you write about it in the paper. Load your WALTER narrations when writing Takeaways — they've already done the interpretive work.

---

Move 5: Ablation / Sensitivity

Function: Show which design choices matter and which don't.

How to do it: Test the system with components removed or varied. Show each component contributes. This answers "is your design over-engineered?"

Warning: If an ablation variant outperforms the full system, you MUST acknowledge and explain it. Hiding this will be caught by reviewers.

---

Move 6: Robustness / Generalization

Function: Show the system works beyond the specific evaluation setup.

How to do it: Test on conditions not in the training set. Common sub-moves: temporal generalization (does it work on new data?), spatial generalization (does it work in new contexts?), computational overhead (is it practical?).

---

The Evaluation Evolution Pattern

Every evaluation goes through three stages:

Target: Stage v3. Get there by writing comprehensively first (v2), then compressing with Takeaways (v3).

---

The Monolithic-to-Split Decision

When to split your evaluation: If a single evaluation section answers two fundamentally different questions (e.g., "Does the system work correctly?" and "Does it improve downstream performance?"), split it. The questions require different baselines and metrics — combining them confuses the narrative.

Decision rule: If your evaluation subsections don't share baselines or metrics, they should probably be separate sections.

---

The Evaluation Maturity Test

Rate your evaluation:

Target: Level 4.

---

Learning Evaluation Craft from Papers You Read

The six-move sequence tells you what an evaluation must accomplish. To learn how the best authors in your area accomplish it, analyze the evaluation sections of 2–3 strong papers at your target venue during deep reading (Pass 3+ in the literature-survey-skill). Extract: How do they structure Setup Anchoring — one paragraph or a full subsection? How many baselines do they name, and how do they justify each? Where do Takeaway paragraphs appear — after every experiment, or only after clusters? How do they handle ablation — separate section or integrated? What does their evaluation's heading structure look like — claim-first or descriptive?

The evaluation architecture of the best-accepted paper at your venue is a more reliable guide than any generic template. If three NSDI papers all use labeled Takeaway paragraphs after each experiment cluster, that's the convention — match it.

Writing an Introduction: The 6-Move Sequence

Overview

An effective introduction follows a 6-move sequence. Each move has a specific function. Missing a move weakens the paper; getting the order wrong confuses the reader.

The Introduction Is Written Twice

Draft 0 is written early — before the evaluation — as a framing scaffold. It covers Moves 1–5 (Stakes through Contributions) in rough form. Its purpose is to set guardrails: what is the paper trying to show? Draft 0 clarifies thinking and constrains what experiments need to be run. It is explicitly disposable.

The final introduction is rewritten from scratch after the evaluation is complete. Now Move 6 (Results Preview) can be filled with real numbers, and Moves 3–5 can be sharpened to match what the evidence actually supports. The final introduction promises exactly what the paper delivers — no more, no less. Draft 0 is reference material for the rewrite, not a starting point for editing.

---

Move 1: Stakes

Function: Establish why the domain matters to the reader.

How to do it: Name specific actors (users, operators, policymakers) or specific applications (video, gaming, cloud services). Anchor with a concrete number if possible (dollar amounts, user counts, scale of the problem).

The rule: Never open with the technology. "ML has shown great promise..." is a rejected-paper opening. Start with the PROBLEM.

Test: Would a domain expert at the target venue care about your opening sentence?

---

Move 2: Problem Gap

Function: Identify the specific gap between current practice and what is needed.

How to do it: The gap must be STRUCTURAL, not quantitative. Not "existing tools aren't good enough" but "existing tools are fundamentally limited because they assume X, which doesn't hold when Y."

Pattern: Number the limitations. "Three fundamental limitations: (i) ... (ii) ... (iii) ..." Each limitation should map to a specific design choice in your system.

Test: Are existing approaches NAMED (not "prior work" or "existing methods")?

---

Move 3: Key Abstraction

Function: Introduce the paper's defining intellectual contribution as a named concept.

How to do it: Coin a term that captures your core insight. Make it a compound noun phrase, ideally with an architectural metaphor. Examples of the pattern (not from specific papers): "external termination layer," "progressive disaggregation," "intrinsic evaluation framework."

Critical insight: The key abstraction appears ONLY in final versions of papers. It is discovered through writing, not planned in advance. If you don't have one yet, that's normal — it will emerge as you write the evaluation and design sections.

Test: Is the name memorable? Would other researchers cite it? Does it distinguish your approach from ALL existing categories?

---

Move 4: Design Intuition

Function: Give the reader a one-paragraph mental model of how the system works.

How to do it: One paragraph maximum. No algorithmic details. Describe the system as a pipeline or architecture: "Two-stage framework: (1) X, (2) Y." This is the "elevator pitch."

Test: Can a reader understand the high-level operation from this single paragraph? Is there an overview figure that maps to the section structure?

---

Move 5: Contributions

Function: Enumerate what the paper delivers.

How to do it:

• Always numbered or bulleted
• Each item starts with a bold label (e.g., "Learning problem.", "Design.", "Evaluation.")
• Each item states a CLAIM, not a process: "We show that X" not "We propose X"
• Each item has a matching evaluation subsection (Principle 1)

Test: Does each contribution have evidence you can point to? If not, it's an aspiration, not a contribution.

---

Move 6: Results Preview

Function: Anchor the introduction with concrete numbers from the evaluation.

How to do it: Include a headline number (e.g., "2–4× improvement") and reference a headline figure. This move is left blank in Draft 0 and filled only in the final introduction — after the evaluation is complete.

Test: Are the numbers specific and defensible? Do they match what the evaluation section actually shows?

---

Accepted vs. Rejected: What's Different?

The pattern: Papers that resolved their identity (key abstraction + contribution framing) before submission were accepted. Papers whose framing was still vague at submission were rejected.

Learning the Moves from Papers You Read

The six-move sequence is not just a writing template — it is also a reading lens. When doing deep reading (Pass 3+ in the literature-survey-skill), analyze the introductions of the strongest papers in your area: identify each move, note how the authors execute it, and extract the specific craft choices they make. Which concrete actors do they name in the Stakes? How do they phrase the structural gap? What is their key abstraction's name, and when in the revision history did it appear?

The craft patterns you extract from papers you read become reference material for your own writing. The best way to learn what a strong Move 2 (Problem Gap) looks like at SIGCOMM is to dissect the Problem Gaps of three accepted SIGCOMM papers — not to read a generic guide. The move sequence tells you what each move must accomplish; the craft extractions from your literature survey show you how the best authors in your field accomplish it.

---

Venue Variations

Writing a Related Work Section: The 3-Move Sequence

Overview

Related work is a positioning tool, not a literature survey. It should be under 10K characters and every cited work should serve the purpose of positioning YOUR contribution.

---

Placement Decision

Two strategies:

Post-evaluation placement (most systems papers): Related work appears AFTER the evaluation. This is a confidence signal — "you'll understand why existing work is insufficient only after seeing our results." Use when novelty is primarily empirical.

Integrated into background (most ML papers): Related work is woven into the background/motivation section. Use when the paper needs to establish a landscape before the contribution makes sense.

Rule: Choose placement based on whether the paper needs to DEFEND (post-eval) or ESTABLISH (pre-eval) its positioning.

---

Move 1: Category Clustering

Function: Group prior work into 2–4 categories, each with a named limitation.

How to do it: Name categories by approach type (e.g., "Crowdsourced / Controlled / Hybrid"), not by individual paper. Never more than 4 categories — more signals the author hasn't found the right abstraction.

Test: Can the reader hold the full taxonomy in working memory?

---

Move 2: Per-Category Limitation

Function: After presenting each category, identify its structural limitation.

How to do it: The limitation must be STRUCTURAL (an inherent property of the approach), not quantitative (just didn't do enough). Structural limitations motivate new approaches; quantitative gaps motivate more experiments.

Test: Does the limitation connect to a feature of your system that addresses it?

---

Move 3: Positioning Sentence

Function: A single sentence that places the paper relative to the entire landscape.

How to do it: "Unlike X, our approach provides Y while maintaining Z." Or: "This paper does not compete in category X; it creates category Y." This preempts the "incremental" criticism by carving out ARCHITECTURAL space.

Test: Does the positioning sentence name your key abstraction? Is it honest about what you DON'T do?

---

Anti-Patterns

1. Exhaustive literature survey: If your related work is over 10K characters, it's a survey, not a positioning section. Cut to representative examples per category.

2. Symmetric treatment: Don't give equal space to every category. Weight toward what matters for positioning YOUR paper.

3. Missing the positioning sentence: Without it, reviewers will ask "how is this different from X?" Don't make them guess — state it explicitly.

4. Tutorial paragraphs: Don't explain foundational concepts the venue audience already knows. If you're submitting to SIGCOMM, don't explain TCP.

---

Consistency Checks

Before finalizing:

• Does the positioning sentence align with the key abstraction in the introduction?
• Are the baselines mentioned in related work the same baselines used in the evaluation?
• If a reviewer asks "how is this different from [closest work]?", does the related work preemptively answer?

Self-Diagnostic: Design Section

Source

Derived from design rhetorical move analysis across 6 papers (see section_rhetorical_moves/design.md and argument_evolution/).

---

Structure

• [ ] Does the section open with the system's core abstraction (named, defined)?
• [ ] Is there an overview/architecture figure early in the section?
• [ ] Does each subsection correspond to a component in the overview figure?
• [ ] Are subsection headings claim-first (e.g., "Nondeterminism as a first-order requirement") rather than descriptive (e.g., "Abstract NFA")?

Design Justification

• [ ] For every major design choice, is there a "why" argument?
• [ ] Does the section explain why alternatives were rejected (not just what was chosen)?
• [ ] Is the justification grounded in empirical observation or requirement analysis, not just intuition?

Abstraction vs. Implementation

• [ ] Does the section lead with user-facing abstractions (APIs, interfaces, programming model)?
• [ ] Are implementation details subordinate to the abstraction explanation?
• [ ] Could a reader understand the design without reading the implementation section?

Terminology

• [ ] Is every technical term defined on first use?
• [ ] Is the system name used consistently (no accidental name variants)?
• [ ] Are there any generic terms that should be replaced with named mechanisms? (Principle 2)

Audience Calibration

• [ ] Is the section calibrated for the target venue's audience?
• [ ] Are there tutorial paragraphs explaining concepts the audience already knows? (Delete them — Principle 4)
• [ ] Does the section use venue-appropriate conventions (\smartparagraph for systems, method-naming for ML)?

The What → Why → So-What Test (Principle 3)

For each subsection, check:

• [ ] Does the heading state WHAT the component does? (minimum)
• [ ] Does the heading argue WHY this design choice? (better)
• [ ] Does the heading state the SO-WHAT implication? (best)

Self-Diagnostic: Evaluation Section

Source

Derived from evaluation rhetorical move analysis across 6 papers (see section_rhetorical_moves/evaluation.md and author_profile/claim_evidence_patterns.md).

---

Claim-Evidence Alignment (Principle 1)

• [ ] Can you list every claim the introduction makes?
• [ ] Does each claim have a dedicated evaluation subsection?
• [ ] If the paper makes two types of claims (e.g., system correctness + downstream improvement), are they in separate evaluation sections? (Principle 9)
• [ ] Can each subsection be described as: "This section shows that [specific claim]"?

Setup Anchoring

• [ ] Are all baselines named (not "prior methods" or "state-of-the-art")?
• [ ] Are baselines described precisely enough for the reader to understand what they are?
• [ ] Are metrics defined and justified (why these metrics for these claims)?
• [ ] Is the dataset described (size, source, time period, any biases)?

Result Presentation

• [ ] Are detailed numerical comparisons in tables or figures, not inline prose?
• [ ] Does prose interpret patterns rather than list numbers? (Principle: "Table 3 shows..." + pattern, not "Model A: 92%, Model B: 87%...")
• [ ] Do figures have proper axis labels, units, and captions?
• [ ] Does the text match the figures exactly? (No contradictions with table captions, no wrong time ranges)

Takeaway Paragraphs (Principle 8)

• [ ] Does every experiment cluster end with an explicit "Takeaway." paragraph?
• [ ] Does the Takeaway state the implication (not just the result)?
• [ ] Is the Takeaway interpretable without reading the detailed results?
• [ ] Does the Takeaway tie back to a specific design claim or contribution?

Deep Dive / Disaggregation

• [ ] Are results disaggregated by relevant conditions (e.g., by RTT, speed tier, geographic region)?
• [ ] Do disaggregated results reveal where the system helps most and where it helps least?
• [ ] If aggregate results are "surprising," is there a distribution-level analysis explaining why?

Ablation

• [ ] Is there an ablation study that validates key design choices?
• [ ] Does the ablation support the design narrative (not undermine it)?
• [ ] If an ablation variant outperforms the full system, is this acknowledged and explained?

Robustness

• [ ] Are results tested under conditions not in the training set (concept drift, new data, edge cases)?
• [ ] Is the deployment overhead or scalability addressed?

The Evaluation Maturity Test

Rate your evaluation on this scale:

Target: Level 4.

Self-Diagnostic: Introduction

Source

Derived from introduction rhetorical move analysis across 6 papers (see section_rhetorical_moves/introduction.md and author_profile/editorial_principles.md).

---

Move 1: Stakes

• [ ] Does the first sentence name a specific domain problem, not a technology? (Principle 7)
• [ ] Does the opening name specific stakeholders (users, ISPs, policymakers) or specific applications (video, gaming, cloud)?
• [ ] Is ML/AI absent from the first two paragraphs? (If present, consider moving it later.)
• [ ] Would a domain expert at the target venue care about the opening sentence?

Move 2: Problem Gap

• [ ] Is the gap structural (fundamentally limited) rather than quantitative (not good enough)?
• [ ] Are limitations numbered and specific (e.g., "Three fundamental limitations: (i)...(ii)...(iii)...")?
• [ ] Does each limitation map to a specific design choice in your system?
• [ ] Are existing approaches named (not "prior work" or "existing methods")?

Move 3: Key Abstraction

• [ ] Does the paper have a named abstraction — a coined term that captures the core insight?
• [ ] Is this name memorable and citable (e.g., "progressive disaggregation", "external termination layer")?
• [ ] Does the name distinguish your approach from all existing categories?

Move 4: Design Intuition

• [ ] Can a reader understand the system's high-level operation from a single paragraph?
• [ ] Is there an overview figure that maps to the section structure?
• [ ] Is the design described as a pipeline or architecture, not as mathematical formalism?

Move 5: Contributions

• [ ] Are contributions numbered (not prose paragraphs)?
• [ ] Does each contribution start with a bold label (e.g., "Learning problem.", "Design.", "Evaluation.")?
• [ ] Does each contribution state a claim (not a process: "We show X" not "We propose X")?
• [ ] Does each contribution have a matching evaluation subsection? (Principle 1)

Move 6: Results Preview

• [ ] Is there a headline number (e.g., "2-4x improvement")?
• [ ] Does the introduction reference a headline figure (first 2 pages)?

Overall

• [ ] Can a skim-reader reconstruct the paper's argument from headings + topic sentences alone? (Principle 3)
• [ ] If you removed every sentence except the first sentence of each \smartparagraph block, would the argument still be clear?
• [ ] Does the introduction promise exactly what the evaluation delivers — no more, no less? (Principle 1)

Self-Diagnostic: Related Work Section

Source

Derived from related work analysis across 6 papers (see section_rhetorical_moves/related_work.md).

---

Placement

• [ ] Is related work placed after the evaluation (systems venues: SIGCOMM, NSDI)?
• [ ] Or integrated into the introduction/background (ML venues: NeurIPS, ICLR)?
• [ ] Is the placement choice deliberate and venue-appropriate?

Category Clustering (Move 1)

• [ ] Is prior work organized into 2-4 categories (not a flat list)?
• [ ] Are categories named by approach type (e.g., "Crowdsourced / Controlled / Hybrid"), not by individual paper?
• [ ] Does each category contain representative examples (not exhaustive lists)?

Per-Category Limitation (Move 2)

• [ ] For each category, is there a specific limitation stated?
• [ ] Is the limitation structural (fundamentally unable to do X) rather than quantitative (doesn't do X well enough)?
• [ ] Does the limitation connect to a feature of your system that addresses it?

Positioning Sentence (Move 3)

• [ ] Is there a clear sentence that says: "Unlike X, our approach provides Y while maintaining Z"?
• [ ] Does the positioning sentence name your key abstraction?
• [ ] Is the positioning honest — does it acknowledge what you DON'T do?

Anti-Patterns

• [ ] Is the section under 10K chars? (If longer, it's a survey, not a positioning section.)
• [ ] Are there no tutorial paragraphs (explaining what TCP is to a SIGCOMM audience)?
• [ ] Is the section a limitation argument, not a literature review?
• [ ] Does every cited work serve the purpose of positioning your contribution (not padding the bibliography)?

Consistency Check

• [ ] Does the positioning sentence align with the key abstraction in the introduction?
• [ ] Are the baselines mentioned in related work the same baselines used in the evaluation?
• [ ] If a reviewer asks "how is this different from X?", does the related work preemptively answer?