--- name: asplos-topic-selection description: Use when deciding whether a project belongs at ASPLOS or at a single-community venue — applying the cross-layer deletion test, matching against ASPLOS's architecture/PL/OS intersection identity, routing to ISCA/MICRO/HPCA, PLDI/POPL, SOSP/OSDI/EuroSys, SC, or MLSys instead, and choosing between the April and September deadlines. --- # ASPLOS Topic Selection ASPLOS's self-description is unusually operational: it seeks work that improves the core disciplines — operating systems, programming languages, computer architecture — **and their intersection**, and its 2027 rapid-review round explicitly prioritizes submissions at that intersection (CFP, checked 2026-07-08). Venue fit is therefore not a prestige question here; it is a screening variable. A technically strong paper that lives cleanly inside one community can be filtered in the first round not because it is bad but because a single-community venue owns its reviewers. ## The deletion test Ask, for each layer the paper touches: *if this layer's content were deleted, would a publishable paper remain?* - Delete the software half and a full paper remains → the work is an ISCA/MICRO/HPCA candidate wearing an ASPLOS template. - Delete the hardware half and a full paper remains → it is a SOSP/OSDI/EuroSys or PLDI paper. - Delete either half and *nothing defensible remains* → the coupling is real; ASPLOS is a first-choice target. The exemplars library shows what passing looks like in award-validated form: an accelerator argued from data movement, a scheduler premised on hardware heterogeneity, an interrupt-delivery boundary redrawn between hypervisor and silicon (see `../../resources/exemplars/library.md`). ## Routing table | If the core claim is... | Stronger first target | ASPLOS becomes right when... | |---|---|---| | A microarchitectural structure (predictor, cache policy, pipeline) | ISCA / MICRO / HPCA | The structure exists to serve a named software behavior, and software changes with it | | A language design, type system, or compiler optimization | PLDI / POPL / CGO / OOPSLA | The compiler co-evolves with an ISA, accelerator, or OS interface | | An OS/distributed-systems design on commodity hardware | SOSP / OSDI / EuroSys / ATC | Hardware assumptions are load-bearing: new memory technology, custom hints, near-data compute | | HPC-scale performance engineering | SC / PPoPP | The result generalizes into an architectural or systems principle beyond one machine | | ML training/serving systems on stock stacks | MLSys | The ML workload drives a hardware/software interface change, not just better scheduling | | Security via hardware mechanisms | IEEE S&P / USENIX Security / CCS | The defense requires co-designed architecture + systems support and its evaluation is performance-shaped | Scope confirmation: the 2027 topics list spans heterogeneous architectures and accelerators; cloud and datacenters; memory, storage, networking, and I/O; power, energy, and thermal management; profiling, debugging, and testing; security, reliability, and availability; parallelism and big-data systems; virtualization; and experimental methodologies — with non-traditional topics welcome when centered in the core disciplines. ## Fit interrogation script Run this before any writing begins: ```text Q1 Name the interface/boundary the work changes (ISA extension, OS/hardware contract, runtime/accelerator ABI, ...). No boundary named -> weak fit. Q2 Deletion test per layer (above). Both halves survive alone -> route away. Q3 Who must adopt this? If one community can adopt it without the other noticing, the intersection claim is decorative. Q4 What evidence class does the claim need — real silicon, FPGA, simulator? If the answer is "none of these", the paper may be a PL/theory paper. Q5 Can the contribution be stated in one sentence that a rapid reviewer reading only two pages will believe? Draft that sentence now. ``` ## Choosing between the two 2027 deadlines ASPLOS 2027 offers two submission gates — April 15, 2026 (passed as of 2026-07-08) and **September 9, 2026** — framed by the CFP as "submit when ready." Treat the choice as an evidence-maturity decision, not a calendar accident: - Submit September only if the evaluation matrix is complete; the two-deadline model removed the mid-year round, so a miss costs roughly half a year. - A Major Revision outcome effectively adds a private third gate (revision due at the camera-ready deadline, six weeks after notification) — but only for papers whose core was sound. Do not submit a hollow evaluation hoping for the revision path; the revision counts as a submission on your record with that PC. ## Distinctive-fit signals worth writing down - The paper's insight is *information that crosses a layer* (what hardware knows that software needs, or vice versa) — the most reliably ASPLOS-shaped idea. - The evaluation needs both a hardware-accuracy instrument (simulator/FPGA/silicon) and a software-realism instrument (kernel patch, runtime, full applications). - Related work must be argued against two or three communities at once; if one community's literature suffices, so would its venue. ## Intersection anti-patterns Recurring shapes that look ASPLOS-flavored but fail the screen: - **The garnish paper** — a complete single-community design plus one paragraph of "hardware support could accelerate this." The intersection must be load-bearing on page 1, not speculative in section 8. - **The stapler paper** — an architecture result and an OS result about the same workload, bound in one PDF with no shared mechanism. Two rejectable halves do not sum to one acceptable whole. - **The tuning paper** — heroic performance engineering on existing interfaces. Without a changed boundary or a transferable principle, it routes to ATC-style venues or an industrial track. - **The premature-generality paper** — a mechanism evaluated only where it was conceived, claiming the whole intersection. Scope the claim to the evidence and let the routing table above pick the venue for the scoped claim. ## Repairing a near-miss instead of rerouting If the deletion test fails narrowly, a reframing pass is often cheaper than a venue change: identify the strongest cross-layer *consequence* of the existing result (a new OS policy the hardware data enables; a compiler contract the mechanism makes checkable), promote it from implication to evaluated contribution, and rebuild pages 1-2 around the promoted claim. Budget this as real research work — it usually needs one new experiment — and re-run the interrogation script afterward rather than assuming the patch took. ## Output format ```text [Fit verdict] first-choice ASPLOS / viable but single-community-stronger / route away [Boundary changed] [Deletion test] hardware-only remainder: Y/N · software-only remainder: Y/N [Route-away target] [Deadline call] September 9, 2026 readiness: evidence gaps listed [Two-page sentence] ```