socc-author-response

SoCC Author Response

Use this after SoCC reviews are released, during the round's author-response (rebuttal) window

(SoCC 2026 Round 2: 10-12 Sep 2026). SoCC gives you one written turn, not a journal-style

revise-and-resubmit — there is no Major Revision to repair the paper in, so the rebuttal must do all

the persuading before the PC discussion decides. Because the reviewer pool is drawn from **both

SIGMOD and SIGOPS**, a winning rebuttal answers the systems reviewer and the data/measurement

reviewer, not one at the expense of the other.

Triage

• Answer what affects the decision: significance of the cloud contribution, soundness of the

mechanism, realism of the deployment or trace, and the measurement quality — especially **tail

latency and cost**, the numbers reviewers most often say are missing.

• Prioritize by impact-times-fixability: a factual misreading you can correct, or a number you can

supply from existing logs, moves more than a philosophical disagreement.

• Correct factual misreadings first; a reviewer who misread a table or a workload is often

persuadable.

• Keep every word within dual anonymity: do not reveal your cluster, company, provider, trace

provenance, or system's real name to strengthen a point.

Structure the single turn

Short and decision-focused. Map each reviewer to the axis they raised:

[R1 - systems] "Evaluated in simulation only?"
       -> We report the 200-node testbed run in Table 2 (already in the paper, §5.2); rebuttal
          clarifies it is a real deployment, not a simulator.
[R2 - measurement] "Tail latency not reported."
       -> p99 attainment is in Fig. 3; we add the p99.9 breakdown from existing logs and will
          include it in the final version.
[R3 - cost] "Cost claim unsupported."
       -> Provisioned instance-seconds vs. the CPU baseline are in Table 2; we clarify the pricing
          model used and the saving it implies.

Answer the reviewer on the axis they actually raised. Do not spend the systems reviewer's attention

defending a measurement point they did not make.

Reviewer pushback patterns

| Pushback | What it signals | SoCC-ready response |

|---|---|---|

| "Simulation only / not a real system" | Systems realism doubt | Point to the testbed/deployment result, or scope the claim honestly |

| "Only average latency reported" | Missing the cloud outcome | Supply p95/p99 from existing logs; do not promise unrun experiments as fact |

| "Baseline is not tuned/fair" | Soundness of the comparison | Report the tuned-baseline number with an equal, documented budget |

| "Workload/trace is unrepresentative" | Measurement validity (data reviewer) | Justify the trace's provenance and scope; bound the external-validity limit |

| "Cost/economic claim hand-waved" | The adoption outcome is unproven | Give the cost breakdown and the pricing model behind it |

| "Overlaps prior cloud work X" | Novelty/delta doubt | Sharpen the one-sentence delta against the nearest SoCC/OSDI/NSDI work |

What a SoCC rebuttal may and may not do

• May: cite numbers already in the paper the reviewer overlooked; report an analysis of

existing logs (a tail percentile, a cost breakdown) that needs no new run; correct a

misreading; commit to a concrete, bounded final-version change.

• May not: present major new experiments as if already done; reveal identity to make a point;

argue taste; over-promise a revision that SoCC's accept/reject process has no round to verify.

Anonymity in the rebuttal (easy to slip)

• Refer to your own prior work in the third person, as in the paper.
• Describe artifact or trace changes without linking to an identity-revealing repository or naming

the source deployment.

• Do not thank a named collaborator, funder, or provider inside the response.

Calibration

• Respond to the criterion the reviewer actually raised, not the one you would rather defend.
• Length and format of the response vary by cycle; confirm the current instructions and the

character/word limit before sending.

• The PC discussion decides; the rebuttal is evidence for an advocate. Remember there is **no

fallback revision round** — this turn is the paper's last word before the verdict.

Output format

[Round + window] round 1 / round 2; response window dates
[Priority issues] <one decision-critical concern per reviewer>
[Axis map] each concern -> systems | measurement/data | cost/tail | novelty
[Response ledger] <concern -> correction / existing-log number / tuned baseline / bounded final-version change>
[Anonymity check] <no cluster/provider/system-name/trace leak in the response: passed/issues>