跳到主要内容
知仓学习社ZHICANG

mlsys-supplementary

Use when deciding what goes into an MLSys appendix versus the 10-page body, exploiting the venue's unlimited separately-uploaded appendix that revie…

不碰外部(只输出文字)无严重或高危命中brycewang-stanford/Awesome-Journal-Skills

它会碰到什么

扫了多少1 个文本文件,7 KB
它会碰到什么不碰外部(只输出文字)
命中总数0 处
命中统计严重 0 · 高 0 · 中 0 · 低 0

这一栏是扫描器报的事实,不是结论。命中多不等于有毒(安全工具、规则库、示例脚本本来就会包含危险写法),命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系,需要你自己看。

技能内容

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>

想直接用这个技能?

本站把开放许可(MIT / Apache 等)的技能按仓库打包整理到网盘,点一下转存到你自己的网盘,不用一个个从 GitHub 拉。许可未声明的技能只给原始仓库链接,不打包。