pods-artifact-evaluation

name	pods-artifact-evaluation
description	Use for the PODS analogue of artifact evaluation — there is no systems artifact track at this theory symposium, so this skill covers formal-claims verification instead: a complete at-submission proof appendix, a claim-to-proof mapping reviewers can check, the full-version-on-arXiv norm, and, only when a paper claims practicality, an honest optional code artifact.

PODS Artifact Evaluation

Use this to prepare the PODS equivalent of an artifact. PODS has no artifact-evaluation track in the systems sense and no ACM reproducibility badges — it is a database-theory symposium. The deliverable that plays the role of an artifact is your formal-claims package: a complete, self-contained proof appendix that ships with the submission, a mapping from every stated result to its proof, and, at camera-ready, a full version on arXiv. Do not import a systems artifact process; adapt to proof verification.

The PODS "badges" — what actually certifies a theory paper

Analogue	What it certifies	What earns it
Complete proofs (at submission)	Every stated theorem is proved and checkable now	The appendix incorporated in the submitted PDF, with no gap deferred off-paper
Claim-to-proof mapping	A reviewer can locate the proof of each result quickly	Forward references from each body statement to its body/appendix proof
Full version on arXiv (at camera-ready)	The community can read the complete development	A de-anonymized arXiv full version, DOI-linked to the PACMMOD paper
Optional code (only if practicality is claimed)	A secondary empirical illustration reproduces	A small, documented, public repository — never a substitute for a proof

The high-value, low-cost "badge" is complete proofs in the appendix: it is what the reviewers verify, and it is entirely in your control. The failure mode at PODS is never "did not run on their machine" — it is "the proof had a gap" or "the claimed proof was not in the PDF."

What PODS reviewers check first

Claim type	First thing inspected	Common failure caught
A complexity bound	The proof of the bound and its matching lower bound	Upper bound only; lower bound "sketched"
A dichotomy	Completeness — that every case is classified and proved	A tractable sub-class, not a full classification
A new semantics	Well-definedness and a decidability/complexity result	A definition with no algorithmic content
A conditional result	Whether the assumption (ETH/OMv/#P) is stated at point of use	Conditional hardness presented as unconditional

Assume a reviewer reads the key proofs in the body and opens the appendix for the deferred ones. Design the appendix so each proof is found and checked without reconstructing context.

Formal-claims packaging plan

[Appendix]     complete proofs of every deferred result, in the submitted PDF (acmsmall, unlimited
               appendix); PODS forbids external/online appendices
[Mapping]      an explicit body -> proof map: each theorem/lemma forward-references its proof location
[Self-contain] each proof restates the claim, lists assumptions, cites the exact prior lemmas used
[Assumptions]  every conditional bound labeled with its conjecture where it is used
[Full version] an arXiv full version prepared: anonymized (or withheld) at submission, public at
               camera-ready with a DOI link to the PACMMOD article
[Optional code] only if the paper claims practicality: a small, documented public repo, clearly
               secondary, that reproduces the illustrative measurements

Anonymized submission package vs. public full version

• At submission: the proof appendix ships inside the anonymized PDF — no author names, acknowledgements, funding, or a named system; any arXiv full version is withheld or anonymized so it cannot reveal authorship.
• After acceptance: post the de-anonymized full version on arXiv, add the DOI link in the camera-ready, and (if a code illustration exists) make its repository public. This is the PODS analogue of releasing an artifact — a readable full proof, not a runnable badge.

Worked vignette: packaging a dichotomy paper's claims

A paper proves a PTIME/hard dichotomy. To make the formal-claims package airtight: put the tractable algorithm and its complexity proof, the hardness reduction, and the completeness lemma in the body's statements with full proofs in the appendix; add a body-to-appendix map so each theorem points to its proof; label the hardness result with its complexity assumption at the point of use; prepare an arXiv full version with the extended development; and, if the paper also claims the algorithm is practical, add a small optional repository — stated honestly as illustration, not evidence for the theorem.

Calibration

• There is no separate artifact deadline and no badge at PODS; the "artifact" obligations are met inside the submitted PDF (proofs) and at camera-ready (arXiv full version).
• If a future PODS edition introduces any formal-verification or reproducibility initiative, confirm it on the current call rather than assuming this static picture.

Output format

[Formal-claims readiness] strong / adequate / gap present
[Appendix] every deferred proof present in the submitted PDF? yes/no
[Claim mapping] <theorem -> proof location present and forward-referenced? yes/no>
[Assumptions] <conditional bounds labeled at point of use? yes/no>
[Full-version plan] <arXiv prepared, anonymized now, DOI-linked at camera-ready>
[Optional code] <present only if practicality claimed; clearly secondary? yes/no/NA>