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 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.
| 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 |
Because it is a separate upload, the appendix must be navigable without the body open:
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)
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.
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.
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.
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.
[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>