cav-author-response

CAV Author Response

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.

Triage

• Answer what affects the decision: soundness of the theorem/proof, **fairness and

reproducibility of the benchmarks, novelty/delta** against prior verification work, scope, and

clarity.

• Use evidence that already exists in the submission or that you can state precisely — a proof step,

a number already in a table, a benchmark-configuration clarification. Do not promise unrun

experiments as if they were results.

• Correct factual misreadings first; a reviewer who misread a theorem's assumption or a benchmark

subset is often persuadable.

• Keep every word anonymous for anonymized categories. (Tool and Industrial papers are not

double-blind, so this constraint relaxes — but still avoid gratuitous self-promotion.)

The verification rebuttal, point by point

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.

Reviewer pushback patterns

| 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 |

Anonymity in the response (anonymized categories)

• Refer to your own prior work in the third person, as in the paper.
• Describe tool/benchmark changes without naming the real tool or linking an identity-revealing

repository; use the anonymized location.

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

Calibration

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

word/character limit before sending.

• The PC discussion decides; write the response as evidence for an advocate, and let the paper — not

the rebuttal — carry the argument.

Output format

[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>