icalp-review-process

ICALP Review Process

Model the pipeline before interpreting any single review. ICALP's process is **conference-style and

correctness-centered**: a paper is accepted or rejected in one round (no journal-style major

revision), and the reviewers' overriding job is to judge whether the **theorems are significant and

the proofs are correct**. The most consequential thing to internalize is that the two tracks run

different processes — Track B gives you a rebuttal, Track A generally does not.

Process model

• Submission and review run on HotCRP, on separate servers per track, under **lightweight

double-blind**: identities are hidden for an unbiased first read, self-references are third person,

but the regime is deliberately not adversarial about de-anonymization.

• Each paper is refereed by the track's program committee (often with sub-reviewers who are

subject experts), who weigh the significance of the result, the correctness and depth of the

proofs, the improvement over prior bounds, and clarity.

• Track A (Algorithms, Complexity and Games): chairs for ICALP 2026 are Sayan Bhattacharya and

Danupon Nanongkai (reported). Authors are contacted only if a correctness issue must be

resolved — otherwise there is no interaction.

• Track B (Automata, Logic, Semantics and Theory of Programming): chaired by Michael Benedikt

(reported). There is a rebuttal period (ICALP 2026: 21-24 March) where authors respond to

initial reviews.

• Decisions are accept / reject in one round; accepted papers publish open-access in LIPIcs.

Reading a decision against the criteria

| Decision | What it usually means | Author move |

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

| Accept | Result significant, proofs judged correct, improvement over prior work is clear | Camera-ready in LIPIcs; post/refresh the full version; arrange a presenter |

| Reject (borderline) | Correct but incremental, or a proof gap the referees could not close in time | Strengthen or reframe; consider STOC/FOCS/SODA/LICS or a journal (icalp-topic-selection) |

| Reject (structural) | A proof is wrong or the model/claim is off | Fix the mathematics before resubmitting anywhere; do not merely re-target |

The strategic reading: because there is no revision round, the submission must be **correct and

complete at deadline**. A believable-but-unwritten proof is the classic ICALP rejection — reviewers

cannot accept what they cannot check in the appendix or full version.

How ICALP differs from its US siblings

• vs. STOC / FOCS: those are ACM/IEEE flagships with their own PCs, templates, and calendars, and

a US-centered community. ICALP is EATCS/European, LIPIcs open-access, and two-track. Prestige

and pool differ; never assume a shared calendar or format.

• vs. SODA: SODA is SIAM's algorithms venue with a distinct community and its own reviewing style.

ICALP Track A overlaps in scope but is a different program committee and audience.

• vs. journals: ICALP is single-round accept/reject, not revise-and-resubmit. There is no major

revision; a paper that needs one belongs in a journal (LMCS, TALG, TCS, JACM) or a later cycle.

Who reads you

Expect subject-matter referees for your specific subarea and track — a matroid result is read by

someone who knows matroid intersection; a VASS result by someone who knows Petri nets. They will

check the proofs, not skim them, which is exactly why the full version / appendix must be complete.

A vague proof sketch with "details omitted" and no full version is caught, not trusted.

Where author leverage actually exists

[Before submission]  track choice + clean model + complete proofs      (largest lever)
[Track A]            essentially none post-submission except a correctness clarification if asked
[Track B rebuttal]   correct factual misreadings; point to the exact lemma answering an objection
[After reject]       no appeal; reroute to a sibling venue or journal, having fixed the mathematics

For Track B, a rebuttal moves a paper when it fixes a misread ("the reviewer thinks Lemma 4

needs X, but the hypothesis already gives it, see line ...") — not when it argues taste. For **Track

A, the lever is almost entirely before** submission: get the proofs complete and the exposition

clear, because you will likely not get to speak again.

Reading a review packet

Weight reviews by how closely the proof was read. A review that cites your lemma numbers and questions

a specific step engaged the mathematics and is your most important reader — answer that step exactly

(Track B) or make sure it is airtight (Track A). A review that discusses only novelty has left

correctness to the others. Reviewers who flag a potential gap are giving you the single most

important signal: if they are right, no rebuttal saves it; if they misread, a precise pointer to the

proof can.

Misreadings to avoid

• Expecting a revision round — there is none; the submission is the artifact of record.
• Assuming a Track A rebuttal — Track A contacts you only for correctness; do not bank on

responding.

• Treating "details in the full version" as sufficient without the full version — reviewers must

be able to check the proof at submission time.

• Projecting a US-venue process onto ICALP — the two-track split and the rebuttal asymmetry are

ICALP-specific.

Output format

[Process stage] pre-submission / under review / Track B rebuttal / notified
[Track] A (correctness-contact only) / B (rebuttal)
[Decision criterion] significance / correctness / improvement-over-prior / clarity
[Proof-check risk] any headline theorem whose full proof a referee cannot currently verify?
[Leverage plan] the next-stage action that can actually change the outcome
[Forbidden moves] shipping an unproved claim / arguing taste in a rebuttal