---

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