icalp-artifact-evaluation

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