| name | sigmod-supplementary |
| description | Use when deciding what accompanies a SIGMOD submission beyond the 12 pages, covering extended technical reports, anonymized code and data links that survive multi-round review, appendix placement relative to the unlimited reference pages, and what reviewers actually open during a PACMMOD round. |
SIGMOD Supplementary
SIGMOD's supplementary question is shaped by two venue facts: the body is
capped at 12 pages with unlimited pages only for references, and the
review cycle — including a possible revision — runs for months under
double-anonymity. Everything that supports the paper from outside the PDF
must therefore stay anonymous far longer than at one-shot conferences, and
whether appendices may ride inside the PDF varies by cycle: check the current
CFP and CMT form rather than assuming.
The three vehicles
| Vehicle | Carries | Multi-round hazard |
|---|
| In-PDF appendix (if the cycle allows) | Proofs, extra plots, tuning grids | Counting against the 12 pages by mistake |
| Anonymized extended report | Full proofs, complete evaluation | Hosting that expires or exposes authors mid-round |
| Anonymized code/data link | Implementation, workloads, scripts | Repo activity revealing identity during revision |
Decide per item, not wholesale. The default discipline: the 12 pages carry
every decision-critical argument; vehicles outside the PDF carry
verification depth, never the contribution itself.
Anonymous hosting that survives a round
- Use a purpose-made anonymous mirror (fresh account or an anonymization
service), not a scrubbed view of the real lab repository.
- Freeze it: pushes during the review window leak timezones, usernames in
commit metadata, and CI badges. Snapshot once, before the deadline.
- Test from a logged-out browser and a second network; institutional
single-sign-on redirects have unmasked authors before.
- Plan for the revision: if reviewers demand new experiments, you will need
a second frozen snapshot — name the first one
v1 from the start.
- Remember late withdrawal counts as rejection; do not host anything you
would have to take down in a hurry mid-round.
What a database reviewer opens, in order
- The PDF itself — if the 12 pages cannot stand alone, nothing else is
read charitably.
- The extended report, when a proof or algorithm detail is contested;
mirror the paper's theorem and section numbering exactly so lookup takes
seconds.
- The code link, most often to check whether a suspicious number has a
plausible harness behind it — a README naming which script produces
which figure answers this without a checkout.
- Raw logs or datasets, rarely; include them for the ARI future, not for
review-time persuasion.
Extended-report etiquette
- Give the report the same title with "(Extended Version)" and keep it
anonymous during review — an arXiv posting under real names that the
paper links to is an anonymity breach, not a supplement.
- Do not fork content: the report is a superset of the paper, never a
different-numbers sibling. Divergent figures between the two versions is
a credibility wound reviewers do report.
- If the report is cited in the submission, cite it anonymously ("Full
proofs appear in the anonymous technical report [URL]").
Splitting a systems paper across vehicles
Worked split for a fictional adaptive-indexing engine submission: the body
keeps the architecture, the two headline comparisons, the correctness
argument sketch, and one ablation that carries the mechanism claim. The
extended report absorbs the remaining ablations, the full proof of the
maintenance-cost bound, and per-query latency tables. The anonymous
repository holds the engine, workload generators with seeds, and per-figure
run scripts. Each vehicle references the others by stable anonymous URL, and
nothing in the report contradicts a number in the body.
Body (12pp): claim spine + headline evidence + mechanism ablation
Report: proof detail + secondary ablations + full latency tables
Repo snapshot: engine v1 tag + generators + fig-to-script map
Size and format practicalities
- Keep any uploaded archive lean: source, scripts, configs, and small
sample data — not the 200 GB dataset, which belongs behind a fetch
script with checksums and a stated size.
- Prefer plain tar/zip over exotic formats; a reviewer who cannot open the
archive in ten seconds will not try twice.
- Put a one-screen INDEX file at the archive root mapping contents to paper
sections; reviewers grant minutes, not hours.
- Whatever CMT's current size ceiling is, verify it on the live form —
upload limits are among the least stable venue parameters.
Pre-upload sweep
- Grep the archive for names, employers, cluster hostnames, cloud account
IDs, and internal ticket references.
- Strip notebook execution metadata and PDF producer fields.
- Verify every URL in the PDF resolves to the anonymous mirror, not the
canonical repo you will publish at camera-ready.
Camera-ready conversion of the vehicles
Plan the vehicles' afterlife when creating them: at acceptance the extended
report becomes a named tech report or arXiv posting, the anonymous mirror
retires in favor of the canonical repository, and the paper's URLs all flip
(see sigmod-camera-ready). Vehicles built with this flip in mind — clean
history, no baked-in anonymous URLs inside scripts, version tags from day
one —
convert in an hour; vehicles built ad hoc convert over a painful week while
the PACMMOD metadata deadline looms.
Output format
[Vehicle map] item -> body / report / repo, with rationale
[Standalone test] does the 12-page body carry the claim spine alone
[Hosting audit] anonymity, freeze status, logged-out access verified
[Numbering mirror] report matches paper theorem/section numbers yes/no
[Sweep findings] identity artifacts found and removed
[Revision reserve] plan for a v2 snapshot if a revision verdict lands
