Asplos Supplementary

ASPLOS Supplementary Material

ASPLOS 2027 lets appendices and supplemental material ride in the submission file with no page limit — under two conditions that define this entire skill: the 11-page body must be self-contained, and reviewers are neither required nor encouraged to read anything past it (CFP, checked 2026-07-08). Supplementary material is therefore not extra space; it is a different medium with a different reader contract.

The reader-contract test

For every block of content, ask: what happens if no reviewer ever reads this?

The self-containment rule has teeth: the CFP frames appendices explicitly as not a way to circumvent the page limit. A proof sketch, key config table, or summary sensitivity plot that a claim depends on belongs inside the 11 pages, however tight that makes them.

What ASPLOS appendices are actually good for

• Full configuration dumps — simulator configs, kernel settings, tuning values whose summary appears in the evaluation section.
• Extended result grids — every workload × platform cell, where the body shows the representative subset and states the selection rule.
• Interface specifications — the full ISA-extension encoding or API surface the body describes functionally.
• Proof details for any formal claims, with theorem statements kept in-body.
• Reproduction detail that previews the Artifact Appendix (asplos-artifact-evaluation) without depending on it.

The anonymized-supplement mechanism (ASPLOS-specific)

The 2027 double-blind rules include a mechanism siblings lack: when your own prior or concurrent work cannot be cited in the third person without breaking anonymity — a workshop paper being extended, a related manuscript under review elsewhere — it is uploaded and cited as anonymized supplemental material. Checklist for using it:

1. Strip the supplement itself: author block, acknowledgments, PDF metadata, repository URLs, venue headers/footers.
2. Cite it in the body as anonymous supplemental material, not with a placeholder like "removed for review" (the placeholder wording is disallowed).
3. Include enough of the prior work that a reviewer can judge the delta — the point of the mechanism is to make "how much is new here?" answerable.

Pointer discipline

Every appendix section earns a one-line, promise-shaped pointer in the body:

Good: "Appendix B lists the full gem5 configuration; §6.1 states the
       parameters that materially affect the results."
Bad:  "Due to space constraints, details are in the appendix."
       (names no content, admits the body is incomplete)
Bad:  "See Appendix C for why this is safe."
       (a safety argument is claim-support; it must live in the body)

Staging across the cycle

• Submission: appendices frozen with the body; they share the PDF and the deadline (September 9, 2026 for the live gate).
• Response window: you may point reviewers to specific appendix content that answers their question — this is the one moment unread appendices get read, and precise pointers (asplos-author-response) are what make it happen.
• Major Revision: appendix deltas count as part of the revision; log them in the change note like body changes.
• Camera-ready/AE: decide what migrates from appendix to the archived artifact, where it gains versioning and badges instead of page count.

Appendix architecture

Unlimited length is not license for a junk drawer. Conventions that keep the appendix navigable for the two audiences who might read it (a response-window reviewer following your pointer, and a future artifact evaluator):

• One appendix per purpose, lettered and titled by content ("Appendix B: Full gem5 configurations"), never "Additional results."
• Order by likelihood of being pointed to during the response window: extended results and configurations first, proofs and encodings later.
• Each appendix opens with a two-line scope note: what it contains and which body section it backs — orphan appendices with no body pointer get cut.
• Keep appendix figures compilable from the same scripts as body figures; a supplement that contradicts the body (stale plot, different config) is worse than no supplement, because it is the kind of inconsistency that surfaces during revision re-review.

What never belongs in any supplement

• Content that breaks anonymity (author-identifying configs, lab hostnames, grant boilerplate) — appendices are swept by the same double-blind rules as the body.
• The only statement of a limitation. Burying a known weakness in an appendix reads as concealment when a reviewer finds it — and one usually does.
• Results that contradict the body's claims without discussion; if the extended grid shows losing cases, the body's claim must already be scoped to survive them.
• Anything you are not prepared to defend in the response window — appendices are in the reviewed record even when unread by default.

Interaction with the 11-page budget

The appendix is the pressure-relief valve that makes the figure-inclusive 11-page limit workable — but only content that passes the reader-contract test may flow through it. When asplos-writing-style's compression pass moves a result grid out of the body, the body must retain the summary statistic and the selection rule, so the claim remains supported by in-limit content alone. The test after every move: re-read the body claim and ask whether a reviewer who stops at page 11 still has grounds to believe it.

Output format

[Self-containment] claims supported only by appendix content: none / list
[Contract test] blocks re-classified body/appendix/artifact/cut: N moved
[Anonymized supplements] needed for: <own-work items> · stripped + cited correctly: Y/N
[Pointers] promise-shaped, content-naming: Y/N per appendix
[Staging] response-window pointer list drafted · artifact-migration list drafted