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>