ARR

Navigating Desk Rejections Based on Incorrect Submission History

A desk rejection stings more when the reason doesn't match your reality.

4 min readMachine Learning

A desk reject is frustrating under any circumstances. It becomes something else entirely when the stated reason appears to be a factual error. The researcher who posted this account described two papers rejected by an ACL ARR program chair on the grounds that the work had already been reviewed through ARR. The author insists neither paper was ever submitted there. If that is accurate, this is not a minor mix-up. It is a procedural failure that raises real questions about how submission histories are checked, how errors are corrected, and what a researcher is supposed to do when the system's record does not match their own.

This is not an abstract governance problem. It is a practical bottleneck for people who are trying to move their work forward. The same frustration shows up across the research lifecycle, often in quieter forms. Consider the experience of someone training a sentiment model and discovering that AI detectors had flagged legitimate reviews, forcing them to filter out valid data and watch accuracy drop. That story, Clean Data Starts With Catching AI Slop Before It Skews Your Model, is about noisy labels in a dataset. But the underlying issue is the same: when the tools we rely on to make decisions are wrong, the person on the receiving end pays the cost. A false positive here is not a minor inconvenience. It is a denial of a fair review cycle.

The same pattern appears in the practical world of model deployment. Builders who ship computer vision systems, like those described in Exploring Real-World Computer Vision: Deployments, Edge Models, and Current Challenges, know that a model is only as good as the conditions it handles. If a system misreads a frame, you do not just shrug. You trace the pipeline, find the failure point, and correct it. The same standard should apply to editorial processes. If a desk reject is based on a mistaken record, the researcher deserves a clear path to show that the premise is wrong. That is not an unreasonable ask. It is the baseline for a credible review system.

What would we tell someone who came to us with this problem? First, do not assume the system is infallible. Request the full record, including the submission ID and the reviewer history the PC referenced. Ask for the specific ARR submission that matches your title or abstract. If there is a mismatch, say so plainly and provide your own submission history, including timestamps and confirmation receipts. If the venue uses an automated matching system, ask whether a human verified the match before the reject was sent. And if the error is confirmed, push for a formal correction and a new review slot. This is not about being difficult. It is about ensuring that a single bad record does not silently terminate two pieces of work.

The deeper issue here is that the burden of verification is being placed on the author, not the organizer. That is backwards. The person who submitted the paper is the least likely to benefit from a false claim of prior review. The system that made the error should be the one to verify and correct it. Until then, researchers should keep their own records close, ask for specifics, and treat a desk reject as a decision that can be challenged, not a verdict that must be accepted. The question worth watching is whether the next version of ARR builds in a simple correction mechanism, or whether it expects authors to fight for accuracy one paper at a time.

From Machine Learning

I have got two papers which got desk rejected by PC saying they are previously got reviewed in arr. But those paper never got submitted ever. Any idea what can be done?

Read the original at Machine Learning