Use this after CAV stage-2 reviews are released. At CAV the rebuttal exists only for papers that passed the stage-1 filter — the two-stage process means a rejected paper never reaches this turn. So the rebuttal is a focused instrument: answer what the two additional reviewers, and the two from stage 1, need in order to advocate for the paper in the PC discussion. For Regular and Application papers, the response must respect double-anonymity — do not reveal authors, the tool's real name, or identity-revealing repositories.
Treat the response as a claim ledger: for each reviewer concern, either resolve it with concrete evidence or explain precisely why the concern does not apply.
[R1.1] "The soundness proof assumes X, which fails for unbounded inputs."
-> Response: X is not assumed; Lemma 2 holds for unbounded inputs (the bound is only on
the encoding width, §3.2). Pointer: §3.2, Lemma 2.
[R2.1] "The baseline solver was not the latest version / not tuned."
-> Response: baseline is vA.B (latest release at submission); we used its default portfolio
as recommended in its README; per-instance data in the artifact confirms parity of limits.
[R2.2] "Novelty over <prior technique> is unclear."
-> Response: prior technique shares lemmas only propositionally; ours admits theory lemmas
under a re-derivation check (the soundness contribution), see §3.3 and Table 2.
The rule that turns a stage-2 paper into an acceptance: answer the axis the reviewer raised, with something they can verify — a section pointer, a proof step, or a benchmark fact — not a promise.
| Pushback | What it signals | CAV-ready response |
|---|---|---|
| "The soundness argument is incomplete" | Correctness doubt | Point to the exact lemma/assumption, or concede and scope the claim |
| "The baseline is outdated or untuned" | Evaluation-fairness doubt | Name the version and configuration; show equal resource limits from the artifact |
| "Only easy/self-selected benchmarks" | External-validity limit | Point to the standard set/revision used; state the class not covered as a limit |
| "Delta over prior work X is thin" | Novelty doubt | Name the precise technical difference (what X cannot do that you do) |
| "The tool did not build / is missing" | Reproducibility gap | Clarify the build path; note the artifact plan (AEC is post-acceptance) |
| "Claim generality is over-stated" | Scope objection | Narrow the claim in the response and promise the camera-ready scoping edit |
[Turn] stage-2 rebuttal (only for papers past the stage-1 filter)
[Priority issue] <reviewer concern>
[Decision dimension] soundness/proof / benchmark-fairness / novelty / scope / clarity / tool
[Claim ledger] <concern -> resolved with (proof step / number / pointer) or scoped>
[Anonymity check] <no identity leak for Regular/Application: passed/issues>