CIKM Artifact Evaluation

CIKM has no verified badge-granting artifact track (2026 lineup: full, short, applied, resource, demo — source map, 2026-07-08), but artifacts do more work here than at most venues, because two of the five tracks are about artifacts: Resource papers publish them, and Demonstration papers perform them. This skill covers the artifact strategy per track and the staging from anonymous review object to public citable release.

Artifact role by track

Resource-track packaging bar

A CIKM resource paper is graded on whether others will build on the object. The verified call names data resources, software, evaluation tasks, and open-source frameworks. Package accordingly:

• Provenance and license first: where the data came from, what consent/terms cover it, and a license a university lab and a company can both act on. An unlicensed dataset is unadoptable regardless of quality.
• Schema and statistics: field-level documentation, size, class balance, known gaps — the datasheet discipline, applied without the buzzword.
• Baselines included: a resource ships with reference numbers and the scripts that produce them, or every adopter re-invents the evaluation differently.
• Maintenance posture: versioning scheme, issue channel, and an honest statement of how long the hosting is funded. Reviewers of resource papers have watched too many datasets rot at dead URLs.
• All of it inside 4 pages (2026) — the paper is the resource's brochure and datasheet condensed; depth lives in the repository.

KG-specific packaging

Knowledge graphs — a CIKM staple — need artifact fields other objects skip: the dump date of any upstream KG, the extraction queries or rules that produced the subgraph, entity-resolution decisions (what merged, what split), and per-relation counts. Two teams "using Wikidata" are usually using different graphs; the artifact is where that ambiguity dies.

Demo systems as artifacts

A demo paper's artifact must run where demos actually happen: conference Wi-Fi, projector resolution, a visitor who types adversarial queries. Package a local fallback (cached index, canned dataset, offline model), a 90-second scripted tour, and a reset mechanism that restores clean state between visitors. The 4-page paper should include the architecture and what a visitor experiences — reviewers accept demos they can imagine standing in front of.

Licensing quick guide

License choice is an adoption decision, and CIKM's mixed academic/industry audience makes it consequential:

Two failure modes recur in resource-track reviews: no license at all (unadoptable), and a license the authors had no right to grant because upstream terms forbid redistribution. Resolve the rights question before the paper claims release.

Hosting for the decade, not the deadline

CIKM papers become baselines years later (cikm-reproducibility), so host on that horizon: an institutional or platform repository under an organization account rather than a personal one; an archival deposit with a DOI for the exact proceedings-version snapshot; dataset hosting with a stated funding horizon rather than a lab NAS URL. The cheapest insurance is the archival snapshot — it survives graduations, lab moves, and platform pivots, all of which the venue's older artifact links have visibly failed to.

Anonymous-to-public staging

Review stage:  anonymized hosting, no author-resolving URLs/metadata,
               referenced from the PDF where each claim needs it
Acceptance:    real repository public by camera-ready (13-day window in 2026 —
               prepare during the review wait)
Public stage:  license chosen; versioned release tagged to the proceedings
               numbers; archival DOI (e.g., a Zenodo-class deposit) so citation
               outlives the hosting; README linking the ACM DL record

The GenAI Usage Disclosure obligation follows the artifact too: generated code, synthetic data, or AI-produced labels inside the package belong in the paper's disclosure section (cikm-reproducibility).

Naming and versioning conventions

Give the artifact the paper's short name (the mechanism name from cikm-writing-style), version it semantically with the proceedings snapshot tagged (e.g., v1.0-cikm2026), and keep the README's first line identical to the paper title so search engines and readers connect the two objects. Post- publication improvements go in later versions with a changelog; the tagged snapshot stays frozen because it is what the paper's numbers mean.

Output format

[Track role] evidence / proof-of-practice / the-contribution / the-performance
[Package state] provenance / license / docs / baselines / maintenance
[KG fields] dump date / extraction / resolution decisions (if applicable)
[Staging] review-anonymous → public-citable, with dates
[Adoption blocker] <the single thing most likely to stop a stranger from using it>