Check Paper Structure Flow

Paper Structure and Flow Check

Check a systems paper's structure at macro and micro levels. Report findings without editing.

Do not perform any Git operation. Return the review to the caller.

First Step

Read the paper. Determine the paper type by page count or venue:

• 12-14 pages → read references/full-paper-12p.md
• 6 pages → read references/workshop-paper-6p.md (inherits from full paper, lists only differences)
• 2 pages → read references/extended-abstract-2p.md

Then check at three levels.

Level 1: Macro Structure

Compare the paper's section list against the template for its type. Check:

• Are all required sections present? Any missing?
• Is the ordering correct?
• Is Background separate from Motivation (full paper) or merged (workshop)?
• Does Design open with goals/requirements/principles + system overview?
• Does Design include an architecture diagram?
• Is Design separated from Implementation?
• Does Evaluation open with exactly two to five explicit numbered RQs and organize its primary evidence blocks by them?
• Are subsections balanced in length?
• Is page budget roughly correct per section?

Level 2: Paragraph Roles

For each section, check whether paragraphs play the correct roles as defined in the template. Focus especially on:

• Abstract: Does it follow the sentence-role structure? Correct word count? Does every abstract sentence map to an intro paragraph with the same claims, numbers, and terminology (no concept debuting in the abstract, no logic jumps)?
• Introduction: Are all required paragraph roles present (¶1 background, ¶2 problem, ¶4 existing solutions, ¶5 insight, ¶6 this paper, ¶7 contributions — never merged)? If ¶3 (root cause) is absent, is the cause still named at the end of ¶2 when ¶5's insight answers one? If ¶5b (challenges) is present, does ¶6 answer its challenges one-for-one? Does each paragraph's first sentence state that paragraph's topic? Are transitions at the start of new paragraphs, not the end of previous ones? Does ¶1 give background (not hook/problem)? Does ¶5 state the insight separately from the system?
• Design: Does it open with design goals? Is each subsection one design decision with why-before-what?
• Evaluation: Does the opening list the complete RQ1--RQn set with two to five RQs? Does each primary evidence block correspond to one RQ, open by stating it, and close with its evidence-backed answer or an explicit unanswered evidence TODO? Are all experiments subordinate to an RQ, with Setup kept outside the RQ count? Is the section free of a evidence-gap list, or negative result? Before a full empirical-paper submission, are all RQs answered?

Level 2.5: Subsection Naming

Subsection titles must follow these conventions:

• Noun phrases only. Not questions ("Why X?"), not claims ("X Stops Y"), not verbs ("Implementing X").
• Parallel structure within a section. If one subsection is "Threat Model", siblings should be similar noun phrases ("Per-Tool Sandboxing", "Pipeline Composition"), not mixed styles.
• Descriptive of content, not argument. The title says what's IN the subsection, not what point it makes.
• No "How" / "Why" / "What" question-style titles.
• No redundant system name. Don't repeat the system name in every subsection title.

Bad: "Why Per-Tool Confinement", "How It Stops Attacks" Good: "Motivation", "Per-Tool Sandboxing", "Pipeline Composition"

Level 3: Paragraph-Internal Flow

For every paragraph:

• Topic sentence first. First sentence states what the paragraph is about.
• One idea per paragraph. Split if two distinct points.
• Why before what. Motivation before mechanism in design paragraphs.
• Old-to-new. Each sentence starts with known information, ends with new.
• Logical connectors. Paragraphs linked by transitions (cause, contrast, elaboration).

Output Format

MACRO: [section-level issue]
MICRO: [paragraph-role issue]
FLOW:  [within-paragraph issue]

Prioritize as Must-fix / Should-fix / Consider.