/atc-writing-style

name: atc-writing-style
description: Use when drafting or revising an ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) systems paper — writing a self-standing two-page extended abstract for the round-one gate, structuring the implementation-and-measurement narrative, reporting costs beside gains, and holding the two-column 12-page budget.

ATC Writing Style

Write for two audiences in two rounds. In round one, two reviewers read only your **two-page extended abstract**; in round two, 3-4 reviewers read the full paper. The abstract is **review-only, not published, and must stand alone**. So ATC writing has a demand no single-round venue makes: the paper's core argument must fit, self-contained, into two pages *and* expand faithfully into twelve.

The self-standing extended abstract (round-one surface)

A round-one reviewer who reads only the abstract should finish knowing:

1. **The systems problem** — a pain a builder or operator recognizes, in the first breath. 2. **Why the current design is inadequate** — the specific limitation your work removes. 3. **The contribution** — the system or technique, stated as what it *does*, not "novel." 4. **The evidence** — the real testbed and the headline result (with the metric that matters, e.g., tail latency, throughput at matched cost). 5. **The honest cost** — what the design trades away, named not hidden.

Test it: hand the two pages to a systems colleague *without* the paper and ask them to state the problem, contribution, testbed, and result. If they cannot, the abstract will lose round one no matter how strong the paper is. A trimmed introduction can work only if it already reads self-contained.

The full-paper arc

ATC papers are implementation-and-measurement narratives:

• **Introduction:** problem → inadequacy → contribution as systems claims → real-testbed evidence →

what changes in practice. Lead with the systems contribution, not a trend sentence.

• **Design:** the mechanism and the *reasons* for each choice, tied to the deployment constraint.

Reviewers reward a design justified by the problem over one justified by novelty.

• **Implementation:** enough that a reader believes it was built and could be rebuilt — scale (lines,

components), integration points, and what was hard.

• **Evaluation:** questions first, then answers. End-to-end results *and* microbenchmarks that

isolate the mechanism; baselines that are fair; tails and variance, not just means.

• **Costs and limitations:** report the trade beside the gain, ideally in the same figure/table. ATC

reviewers trust evaluations that volunteer their costs.

Report costs beside gains (the ATC trust move)

Every systems design trades something — CPU on the fast path, memory, write amplification, warm-up, compatibility. The fastest way to earn a systems reviewer's trust is to **quantify the cost in the same breath as the win**, at a *matched* operating point (same budget, same load). Concealing the cost is the fastest way to lose it.

Page-budget discipline (two columns, 12 pages)

• **≤ 12 pages** full / **≤ 6** short, excluding references and appendices, in **two-column** 10pt.

The two-column format is denser than single-column ACM layouts — a figure-heavy systems paper fills it fast.

• Recover space **editorially**, never by shrinking the font or margins (a desk-reject ground): cut

redundant background, merge overlapping figures, and move non-decision-critical detail to an appendix (reviewers are not required to read appendices — see `atc-supplementary`).

• Keep every claim that decides acceptance inside the body; the appendix and artifact hold support,

not load-bearing evidence.

Systems-prose specifics

• **Name the testbed early** — hardware (CPU/NIC/SSD models), OS/kernel versions, and workloads —

so results are legible.

• **Quantify, don't adjective** — "reduces p99 by X at matched throughput" beats "significantly

faster."

• **Third-person self-citation** for double-blind — never "our earlier system X"; write it as prior

work by others.

• **Figures earn their space** — each should answer an evaluation question a reviewer would ask.

Anti-patterns (ATC-specific)

• **A dependent extended abstract** that only makes sense after reading the paper — a round-one

loss.

• **Average-only evaluation** with no tail or variance — reads as hiding the interesting cases.
• **Novelty-as-argument** — asserting "novel" instead of motivating the design from the problem.
• **Costs quarantined** in a late limitations paragraph instead of reported with the gains.
• **Template tampering** to fit the page budget — recover space by cutting, not shrinking.

Output format

[Extended abstract] self-standing? problem/contribution/testbed/result/cost all present in 2 pages? yes/no
[Arc] problem -> inadequacy -> contribution -> real-testbed evidence -> what changes: complete? gaps?
[Evidence shape] end-to-end + microbenchmarks? tails + variance? fair baselines? costs beside gains?
[Budget] pages used (body/refs), two-column compliance, editorial cuts available
[Rewrite queue] <ordered edits, highest-leverage first — usually the abstract>