| name | icalp-artifact-evaluation |
| description | Use to understand why ICALP (EATCS) has no artifact-evaluation track or badge scheme, and what plays the equivalent role for a pure-theory paper — the full version with complete proofs, reproducible computational certificates, and optional machine formalization — so authors coming from a systems/ML venue do not waste effort building an artifact ICALP does not evaluate. |
ICALP Artifact Evaluation (there isn't one — and what replaces it)
Read this first if you are arriving from a venue with an artifact track. ICALP has no artifact
evaluation, no artifact-evaluation committee, and no ACM/IEEE badges. It is a pure theoretical
computer science venue: the contribution is a theorem, and the "artifact" a referee cares about is
the proof. Building a Docker image, a benchmark harness, or a reproducibility capsule for an ICALP
submission is effort spent on something no one will evaluate — and can even signal that the paper is
mis-routed.
Why no artifact track
- ICALP results are mathematical: correctness is established by a proof a referee checks, not by
running code on a machine.
- The community norm and the LIPIcs open-access model center the published proof and the full
version, not a software deliverable.
- Contrast the software-engineering / systems / ML world (ACM/IEEE Available–Functional–Reusable–
Reproduced badges, or ML reproducibility checklists): those exist because the contribution is a
system or an empirical result. At ICALP it is not.
What plays the artifact's role
| Systems/ML artifact concept | ICALP equivalent |
|---|
| "Artifacts Available" (archived, DOI) | The full version on arXiv/ECCC/HAL, and the open-access LIPIcs paper |
| "Functional" (it runs) | The proof is complete and checkable in the appendix / full version |
| "Reproduced" (results re-obtained) | An expert re-derives / verifies the proof; certificates for any computation |
| Reproducibility capsule | A machine-checked formalization (Coq/Lean/Isabelle), when provided |
So the "artifact" work for an ICALP paper is: write the complete proofs, make any computation
checkable (icalp-experiments, icalp-reproducibility), and optionally formalize the central
theorem.
When your paper DOES contain software
Some ICALP papers include an implementation or a computer-assisted proof. Even then, there is no badge
track — but you should still:
- Make the code reproducible and reference it at camera-ready (public repo, or Zenodo/Software
Heritage for a DOI), primarily to support the proof, not as a graded artifact.
- Provide certificates an independent checker can verify where the method allows.
- Keep any such repository from breaking anonymity during lightweight double-blind review.
If the implementation/experiment is the actual contribution rather than support for a theorem, that
is a routing signal: an experimental-algorithms track (e.g. ALENEX/ESA's experimental track), a
systems venue, or a database/ML venue may be the right home — see icalp-topic-selection.
Do not
- Do not build an artifact-evaluation package for ICALP; there is nothing to submit it to.
- Do not import ACM/IEEE badge language or an ML reproducibility-checklist artifact into the paper.
- Do not assume a future ICALP will add an artifact track without checking the live call (待核实
if ever announced).
Output format
[Artifact track?] none at ICALP (pure-theory venue)
[Proof-as-artifact] complete proofs in full version? yes/no
[Computation support] certificates / reproducible code where a proof uses computation? n/a or yes/no
[Formalization] none / partial / archived+cited (optional, not required)
[Routing flag] is software the real contribution (=> reconsider venue)? yes/no
