By name: iclr-topic-selection description: Use when deciding whether a project is a strong ICLR submission, should be reframed for ICLR, or should be routed to NeurIPS, ICML, AAAI, AISTATS, ACL, CVPR, KDD, or another venue. Use when a project lacks a clear representation-learning insight, when an application result needs a learning contribution to fit ICLR, or when weighing ICLR's deep-learning center of gravity against a better-matched venue.
ICLR Topic Selection
Use this when a project is still movable. ICLR is broad, but the paper should teach the learning community something about representations, objectives, models, data, optimization, evaluation, or deployment.
Strong ICLR signals
- A clear representation-learning, model-behavior, optimization, generative modeling, RL, theory, or evaluation contribution.
- Evidence that changes how researchers should build, analyze, or judge learning systems.
- A simple central claim that can be verified by focused theory, experiments, or artifacts.
- Interest beyond one dataset, product, or application vertical.
- Honest limitations and ethics treatment for high-impact model or data claims.
Weak ICLR signals
- Pure application paper with little learning insight.
- Incremental benchmark bump without mechanism, analysis, or robust evidence.
- Closed system claim that reviewers cannot inspect or reproduce.
- Dataset-only paper without a learning-representation or evaluation advance.
- Theory result disconnected from modern learning practice and not routed to a theory-focused venue.
Routing logic
- Prefer NeurIPS or ICML for broader ML method/theory work with less ICLR-specific representation framing.
- Prefer AISTATS or UAI for statistics, uncertainty, causal, or probabilistic emphasis.
- Prefer ACL, CVPR, KDD, or robotics/HCI venues when the contribution is primarily domain-specific.
- Prefer workshops when the idea is timely but under-evidenced.
Fit-versus-route decision table
ICLR's center of gravity is deep representation learning: architectures, self-supervision, generative models, foundation models, RL with deep function approximation, optimization for deep nets, interpretability, and alignment. Score the project against that center before routing.
| Project shape | ICLR fit | Better route if not ICLR |
|---|---|---|
| New self-supervised objective with analysis | Strong | — |
| Theory explaining a deep-net phenomenon | Strong | AISTATS/UAI if purely statistical |
| LLM/foundation-model behavior study | Strong | ACL if narrowly language-specific |
| Benchmark bump, no mechanism | Weak | Domain venue or workshop |
| Causal/uncertainty emphasis | Plausible | AISTATS or UAI |
| Deployed application, little learning insight | Weak | KDD, CVPR, robotics/HCI venue |
Worked vignette
A team has a method that improves recommendation click-through in production. As written it is an application paper. To make it ICLR-shaped, they extract the representation-learning claim: a new contrastive objective that yields embeddings transferring across catalogs, demonstrated with an ablation and a probe on a public dataset. The product result becomes one validation point, not the contribution. If that reframing fails to surface a learning insight, the honest route is KDD.
Reviewer-pushback patterns
- "No learning insight, just engineering." Reframe around the mechanism or route to a domain venue.
- "Dataset-only paper." Add an evaluation or representation advance, or target a datasets-and- benchmarks track instead.
- "Theory disconnected from practice." Tie the result to an observed deep-learning phenomenon.
Output format
[ICLR fit] strong / plausible / weak / no
[Core learning insight] <one sentence>
[Evidence required] <theory, experiment, benchmark, artifact>
[Best venue route] ICLR / NeurIPS / ICML / AISTATS / UAI / domain venue / workshop
[Reframe] <how to make the paper more ICLR-shaped>