ICDT Skills

Use when auditing an ICDT (International Conference on Database Theory) regular-paper submission for Microsoft CMT readiness, covering the two-step abstract-then-paper deadline in the correct submission cycle, the lipics-v2021 15-page limit excluding references, the clearly-marked appendix read at the PC's discretion, anonymous submission since 2024, the complete-proofs / full-version expectation, and which submission problems are unfixable after the AoE cutoff.

Use when deciding what counts as evidence for an ICDT (International Conference on Database Theory) result — matching-bound complexity analysis as the primary evidence, worked examples and counterexamples that establish separations, and, only for papers with an algorithmic contribution, a proportional and honestly-scoped experimental evaluation that does not pretend to be the contribution.

Use when preparing the final LIPIcs camera-ready for an accepted ICDT (International Conference on Database Theory) paper — the lipics-v2021 final document, mandatory ACM CCS concepts and keywords, author ORCIDs, de-anonymization, complete proofs and the full-version link, CC-BY licensing, and passing the Dagstuhl/DROPS production checks that mint the DOI.

Use when positioning an ICDT (International Conference on Database Theory) paper against the database-theory literature — covering the ICDT/PODS lineage, finite model theory and complexity, delta-first positioning against the nearest prior theorem, honest treatment of overlapping bounds, and keeping self-citations anonymous under the since-2024 rule.

Use when deciding how to split an ICDT (International Conference on Database Theory) paper between the 15-page lipics-v2021 body and the clearly-marked appendix that referees read at their discretion, given that online/external appendices are not allowed and every proof needed to certify the result must live inside the single submitted PDF.

Use when shaping the prose of an ICDT (International Conference on Database Theory) paper — the theorem-proof structure, stating the data model and computation model precisely, leading with the result and its data-management consequence, proof-sketch-then-appendix discipline within the lipics-v2021 15-page budget, and the notation conventions a database-theory referee expects.

Use when reasoning about how an ICDT (International Conference on Database Theory) submission is evaluated, covering the two-submission-cycle model, the first-cycle revision (Accept / Revise / Reject) decision, anonymous review since 2024, the cross-cycle resubmission restriction, proof-correctness scrutiny by a database-theory PC, and how ICDT's process differs from PODS and from the co-located EDBT systems track.

Use when responding to ICDT (International Conference on Database Theory) referees — principally the first-cycle Revise-and-resubmit round, where you return a corrected paper that closes each identified proof gap, plus any short author-comment phase, keeping the response anonymous and mapping every referee point to a concrete change in the revised PDF.

Use when strengthening the verifiability of an ICDT (International Conference on Database Theory) paper — the theory-venue analogue of reproducibility — covering complete and self-contained proofs, exact models and assumptions, claim-to-proof mapping, matching upper and lower bounds, consistency between the LIPIcs paper and the arXiv full version, and honest labeling of what is proved versus conjectured.

Use when deciding whether a database-theory project belongs at ICDT (International Conference on Database Theory) or should be routed to PODS, the co-located EDBT systems track, a pure-TCS venue (LICS, ICALP, STACS), or a journal (ACM TODS, LMCS, TheoretiCS), and when distinguishing ICDT from its sibling database-theory flagship PODS by calendar, publisher, and community.

Use when preparing the "artifact" of an ICDT (International Conference on Database Theory) paper, which at a pure-theory venue is the complete-proofs full version rather than a code package — covering why ICDT has no ACM-style artifact-badging or code-artifact track, what the marked appendix and the archived arXiv full version must contain, and (only for the rare algorithmic paper) how any code should be handled.