| name | mlsys-supplementary |
| description | Use when deciding what goes into an MLSys appendix versus the 10-page body, exploiting the venue's unlimited separately-uploaded appendix that reviewers are not required to read, organizing configs, traces, extended results, and anonymized code pointers, and keeping supplementary material blinded for the research track. |
MLSys Supplementary
Use this when splitting a Conference on Machine Learning and Systems submission between
body and appendix. The 2026-cycle mechanics (verified 2026-07-08): appendices are
unlimited in length, uploaded as a separate file from the main paper, due at the
same time — and reviewers are explicitly not required to read them. That last clause
is the design constraint everything below follows from.
The governing rule
The 10-page body must win the paper's acceptance alone. The appendix exists to survive
audits — a skeptical reviewer checking one specific configuration — and to serve future
readers and artifact evaluators. Anything that must be believed for acceptance goes in
the body; anything that must be checkable can go behind it.
Placement decision table
| Material | Body or appendix? | Reasoning |
|---|
| Headline comparison + strongest ablation | Body, always | Reviewers judge only what they must read |
| Full hyperparameter/configuration matrices | Appendix, cross-referenced | Audit material, not narrative |
| Baseline tuning protocol and budgets | Body (one paragraph) + appendix (full grid) | Fairness is decision-critical; the grid is evidence |
| Per-workload result breakdowns beyond the headline | Appendix table, body sentence summarizing spread | Spread claim needs body presence; rows do not |
| Workload/trace characterization (rates, lengths, mixes) | Body figure if representativeness is contested; else appendix | Representativeness is a top MLSys objection |
| Additional hardware generations or precision modes | Appendix | Strengthens generality without carrying the claim |
| Failure cases and non-wins | Body, briefly | Honesty here is scored; hiding it in the appendix reads as burying |
| Proof sketches for any theoretical guarantee | Body sketch, appendix proof | Same convention as ML venues |
| Artifact/repository description | Appendix (anonymized for research track) | Feeds later artifact evaluation |
Structuring the appendix file
Because it is a separate upload, the appendix must be navigable without the body open:
- Start with a half-page map: appendix section → the body section and claim it supports.
- Number appendix sections A, B, C... and cross-reference each at least once from the
body ("full grid in App. B"); un-pointered appendix content is effectively invisible.
- Restate the experimental setup header (hardware, workloads) at the top rather than
assuming the reviewer has the body's Section 5 in memory.
- Keep figures self-captioning: every axis, unit, and trial count readable standalone.
appendix.pdf
├── A. Claims map (body claim -> appendix evidence)
├── B. Full system + baseline configurations
│ B.1 our system B.2 baseline-1 (tuning grid) B.3 baseline-2
├── C. Workload characterization (trace statistics, generation scripts described)
├── D. Extended results (per-workload, per-hardware, per-precision)
├── E. Sensitivity and additional ablations
├── F. Anonymized artifact description (layout, run commands, hardware needs)
└── G. Proofs / analytical model derivations (if any)
Anonymity in supplementary material (research track)
- The appendix is part of the double-blind submission: no author names, affiliations,
cluster hostnames, internal project codenames, or company-identifying trace fields.
- Scrub trace data specifically — production traces leak identity through service
names, datacenter labels, and timestamp patterns. Rename fields and state that you did.
- Code pointers must go to anonymized mirrors; the real repository appears only at
camera-ready and artifact evaluation.
- Industrial-track supplements follow that track's looser rule (company identity may
remain; author names may not) — do not mix the two tracks' standards.
Worked split: an inference-compiler submission
A fictional paper contributes a compiler pass that fuses attention variants, claiming
1.5-1.9x kernel speedups and 1.2x end-to-end serving gains across three model families.
- Body keeps: the fusion legality insight and the pass algorithm (compressed to one
figure plus one column), the end-to-end serving comparison under a stated latency
constraint, the kernel-level speedup summary across families, one ablation isolating
the fusion from unrelated codegen wins, and the non-win (no gain on short sequences,
stated with the mechanism reason).
- Appendix takes: per-operator speedup tables for all 40 fused patterns, the full
autotuning search configuration, correctness-test methodology against reference
kernels, results on a second GPU generation, and the anonymized artifact description.
- The one judgment call: the correctness methodology gets a two-sentence summary in the
body — a compiler paper that never says how it validated correctness invites the
objection no appendix can pre-empt, because the appendix may never be opened.
The test of the split: hand a colleague only the 10-page body and ask them to argue for
acceptance; every point where they reach for the appendix is a misplacement.
Common failure modes
- The outsourced paper: body asserts, appendix proves, reviewer reads only the body
and scores the assertions as unsupported. Pull the single strongest piece of evidence
for each major claim forward.
- The stale appendix: body numbers get regenerated at the deadline, appendix tables
do not, and a careful reviewer finds the mismatch. Build both from the same logs in
the same script run.
- The dumping ground: forty pages of unreferenced plots signal an unfiltered
experiment log, not scholarship. Every appendix element should answer a question a
reviewer might actually ask.
- The forgotten upload: the appendix is a separate file with the same deadline —
assign its upload explicitly; it is not attached to the paper PDF automatically.
Interaction with later stages
The appendix outlives review. The configuration matrices and workload characterization
you file now become the skeleton of the Artifact Appendix at evaluation time
(mlsys-artifact-evaluation), and the camera-ready version de-anonymizes rather than
rewrites it — so write appendix sections as if a stranger will execute them in six
months, because at this venue one probably will. Conversely, anything you promise in
the author response ("full sweep in the appendix") must land there by camera-ready;
keep a promises ledger.
Cycle-volatility warning
The separate-upload mechanic, unlimited length, and same-deadline rule are 2026-cycle
facts; earlier cycles differed and the next may too. Confirm the current Call for
Research Papers wording before finalizing the split.
Output format
[Split status] body-sufficient / body-dependent-on-appendix (fix) / not ready
[Claims map] <major claim -> body evidence -> appendix backup>
[Appendix structure] <sections present + cross-reference check>
[Anonymity sweep] <traces/configs/code pointers cleaned?>
[Consistency] <body and appendix generated from same logs? y/n>
[Upload owner] <person responsible for the separate file>
