SoCC Writing Style
Use this when revising the main paper. SoCC papers are read by a joint SIGMOD+SIGOPS audience,
so they need a cloud-scale problem stated in operator terms on the first page and evidence a
skeptic from either community trusts. The failure this skill prevents is a paper that reads like a
pure-OS result with a cloud title glued on, or a benchmark with no systems contribution.
Revision rules
- Lead with the cloud problem, in cost and tail terms: the problem an operator or platform team
recognizes, why current systems are inadequate at scale, the contribution (mechanism and/or
measurement), the measured evidence, and what changes for cloud practice.
- Situate the contribution at the systems-and-data intersection. Say explicitly what is new: a
mechanism, a measurement, a benchmark, a deployment lesson, or a cost model. SoCC's twin
communities both want to see themselves in the paper.
- Make tail latency and cost first-class. Report p95/p99 (and p99.9 where it bites) and a
concrete cost model, not just averages. A cloud paper that reports only the mean signals it has
not been stress-tested the way an operator would.
- Pair every claim with measured evidence — a real or realistic deployment, a tuned baseline, a
distribution rather than a point, a trace with stated provenance — not adjectives.
- State limitations honestly where the results live: single-provider traces, one region, tested
regimes, the workloads you did not cover. A cloud paper's external validity is part of its claim.
- Respect the 12-page (full) / 6-page (short) budget as a design constraint; references are
unlimited, but the argument and its decision-critical figures fit the body.
- Maintain dual anonymity in self-citations, system/cluster/trace names, provider hints,
acknowledgements, and the availability wording.
Cloud-systems paper skeleton
| Section |
Job it must do |
Common failure |
| Intro |
Operator problem, inadequacy at scale, contribution, evidence preview, cloud payoff — first page |
Leads with a technology trend, not a problem |
| Background/Motivation |
Why current cloud systems fall short here, grounded in scale |
Motivation by assertion, no measured gap |
| Design / Study |
The mechanism or the measurement setup, reproducibly, with the testbed/trace |
Method described too thinly to re-deploy |
| Evaluation |
Throughput, tail, and cost vs. tuned baselines on a real/realistic system |
Mean-only metrics; simulation standing in for deployment |
| Limitations |
The external-validity limits that bite (provider, region, regimes) |
Generic or absent |
| Related work |
Delta-first positioning across systems and data venues |
Catalog of citations with no contrast |
Sentence-level rewrites
| Draft pattern |
SoCC-safe rewrite |
| "Our system significantly improves performance." |
"raises throughput X% and holds p99 within the SLO on a 200-node testbed vs. " |
| "We evaluate on a large workload." |
"We replay a production trace of N invocations across M functions (provenance in §3)" |
| "Results show our approach works well." |
"cuts provisioned instance-seconds Y% at equal p99 (Fig. 3); limits in §6" |
| "State-of-the-art performance." |
Claim scoped to the workloads, scale, and cost model actually tested |
| "It scales." |
"sustains the SLO from 10 to 200 nodes; beyond that, " |
Tail-and-cost discipline
[Tail] report p95/p99 (p99.9 where it bites), not just the mean; show the distribution
[Cost] state the pricing model; report instance-seconds or $ so the saving is checkable
[Baseline] tune every baseline with a documented, equal budget; an untuned baseline is a weakness
[Scale] show behavior across sizes; name the bottleneck where it stops scaling
[Limits] single-provider / one-region / tested-regime limits stated next to the results
Vignette: compressing an over-scoped systems paper
A draft with three mechanisms, twelve figures, and a sprawling background: keep the one mechanism
that carries the contribution, the throughput/p99/cost figures that decide it, tuned baselines, and
a limitations paragraph; move secondary regimes and full config sweeps to the artifact with forward
references; cut background to the measured gap the paper closes. The test of a good cut: a reviewer
should be able to answer "what did it improve, at what tail and cost, versus what baseline, and
where does it stop working?" from the body alone.
Output format
[Writing diagnosis] clear / under-motivated / mean-only / over-claimed / over-scoped
[First-page fix] <new framing leading with the operator problem in cost/tail terms>
[Evidence audit] <claim -> deployment/trace -> tail+cost reported -> tuned baseline? yes/no>
[Limitations fix] <external-validity limit that bites -> where to state it>
[Anonymity edits] <system/cluster/trace names / self-citations / links to rewrite>
Source: brycewang-stanford/Awesome-Journal-Skills → SoCC-Skills/skills/socc-writing-style/SKILL.md
1---2name: socc-writing-style3description: Use when revising an ACM SoCC paper for a cloud-scale problem an operator recognizes on the first page, a contribution at the systems-and-data intersection, evidence measured on a real or realistic deployment with tail latency and cost as first-class, dual-anonymous wording, and disciplined use of the acmart 12-page budget.4---567# SoCC Writing Style89Use this when revising the main paper. SoCC papers are read by a joint **SIGMOD+SIGOPS** audience,10so they need a **cloud-scale problem stated in operator terms on the first page** and evidence a11skeptic from *either* community trusts. The failure this skill prevents is a paper that reads like a12pure-OS result with a cloud title glued on, or a benchmark with no systems contribution.1314## Revision rules1516- **Lead with the cloud problem, in cost and tail terms:** the problem an operator or platform team17 recognizes, why current systems are inadequate *at scale*, the contribution (mechanism and/or18 measurement), the measured evidence, and what changes for cloud practice.19- **Situate the contribution at the systems-and-data intersection.** Say explicitly what is new: a20 mechanism, a measurement, a benchmark, a deployment lesson, or a cost model. SoCC's twin21 communities both want to see themselves in the paper.22- **Make tail latency and cost first-class.** Report p95/p99 (and p99.9 where it bites) and a23 concrete cost model, not just averages. A cloud paper that reports only the mean signals it has24 not been stress-tested the way an operator would.25- **Pair every claim with measured evidence** — a real or realistic deployment, a tuned baseline, a26 distribution rather than a point, a trace with stated provenance — not adjectives.27- **State limitations honestly** where the results live: single-provider traces, one region, tested28 regimes, the workloads you did not cover. A cloud paper's external validity is part of its claim.29- **Respect the 12-page (full) / 6-page (short) budget as a design constraint;** references are30 unlimited, but the argument and its decision-critical figures fit the body.31- **Maintain dual anonymity** in self-citations, system/cluster/trace names, provider hints,32 acknowledgements, and the availability wording.3334## Cloud-systems paper skeleton3536| Section | Job it must do | Common failure |37|---|---|---|38| Intro | Operator problem, inadequacy at scale, contribution, evidence preview, cloud payoff — first page | Leads with a technology trend, not a problem |39| Background/Motivation | Why current cloud systems fall short here, grounded in scale | Motivation by assertion, no measured gap |40| Design / Study | The mechanism or the measurement setup, reproducibly, with the testbed/trace | Method described too thinly to re-deploy |41| Evaluation | Throughput, **tail**, and **cost** vs. tuned baselines on a real/realistic system | Mean-only metrics; simulation standing in for deployment |42| Limitations | The external-validity limits that bite (provider, region, regimes) | Generic or absent |43| Related work | Delta-first positioning across systems and data venues | Catalog of citations with no contrast |4445## Sentence-level rewrites4647| Draft pattern | SoCC-safe rewrite |48|---|---|49| "Our system significantly improves performance." | "raises throughput X% and holds p99 within the SLO on a 200-node testbed vs. <tuned baseline>" |50| "We evaluate on a large workload." | "We replay a production trace of N invocations across M functions (provenance in §3)" |51| "Results show our approach works well." | "cuts provisioned instance-seconds Y% at equal p99 (Fig. 3); limits in §6" |52| "State-of-the-art performance." | Claim scoped to the workloads, scale, and cost model actually tested |53| "It scales." | "sustains the SLO from 10 to 200 nodes; beyond that, <named bottleneck>" |5455## Tail-and-cost discipline5657```text58[Tail] report p95/p99 (p99.9 where it bites), not just the mean; show the distribution59[Cost] state the pricing model; report instance-seconds or $ so the saving is checkable60[Baseline] tune every baseline with a documented, equal budget; an untuned baseline is a weakness61[Scale] show behavior across sizes; name the bottleneck where it stops scaling62[Limits] single-provider / one-region / tested-regime limits stated next to the results63```6465## Vignette: compressing an over-scoped systems paper6667A draft with three mechanisms, twelve figures, and a sprawling background: keep the one mechanism68that carries the contribution, the throughput/p99/cost figures that decide it, tuned baselines, and69a limitations paragraph; move secondary regimes and full config sweeps to the artifact with forward70references; cut background to the measured gap the paper closes. The test of a good cut: a reviewer71should be able to answer "what did it improve, at what tail and cost, versus what baseline, and72where does it stop working?" from the body alone.7374## Output format7576```text77[Writing diagnosis] clear / under-motivated / mean-only / over-claimed / over-scoped78[First-page fix] <new framing leading with the operator problem in cost/tail terms>79[Evidence audit] <claim -> deployment/trace -> tail+cost reported -> tuned baseline? yes/no>80[Limitations fix] <external-validity limit that bites -> where to state it>81[Anonymity edits] <system/cluster/trace names / self-citations / links to rewrite>82```8384---8586**Source:** [`brycewang-stanford/Awesome-Journal-Skills`](https://github.com/brycewang-stanford/Awesome-Journal-Skills) → `SoCC-Skills/skills/socc-writing-style/SKILL.md`
thedixitjain