Rejection must give an actionable revision direction
Aliases: actionable feedback · rejection explanation · revision guidance
What it is
Actionable rejection feedback states, when a request, manuscript, or proposal is turned down, which criteria were not met, what evidence that judgment rests on, whether a revisable path exists, and whether resubmission is possible. It does not promise eventual approval; it tells the submitter which direction to move in to align with the review criteria instead of guessing blind.
Why it happens
A bare rejection is a single bit of information that leaves the submitter to guess among several very different causes: a fixed constraint that cannot change, missing evidence that could be supplied, or simply a reviewer's preference. The more plausible causes there are, the more expensive it is to eliminate them by trial and error — this is fundamentally a search problem, and a specific reason does the submitter's elimination work in advance, turning what could take several rounds of blind guessing into one or two targeted fixes.
Giving reasons is not free, though. Once a stated reason exposes the exact threshold or detection logic behind a decision, in adversarial settings — fraud screening, content moderation, academic misconduct checks — that detail becomes a manual for evading the check next time. Systems in those settings can only offer safe, category-level reasons ("insufficient evidence for this claim") rather than the triggering rule itself; this is a genuine trade-off between informativeness and exploitability, not reviewer reluctance to be clear.
Feedback quality also operates through a second channel: procedural-justice accounts distinguish whether an outcome felt fair from whether the outcome was favorable, and perceived fairness of a rejection depends heavily on whether the submitter received a serious, specific explanation, even when the answer stays no. That channel only holds, however, if the stated reason is what actually drove the decision rather than a rationalization assembled afterward. Where the real determination comes from an opaque model or pooled scores across several reviewers, a generated "actionable reason" may only approximate the true cause — and a submitter who revises accordingly and is rejected again a second time can end up trusting the process less than if no reason had been given at all.
Studying it
- Paradigm: randomly assign otherwise-similar rejected submissions to a bare-rejection condition, a stated-reason condition, and a reason-plus-revision-path condition, and compare resubmission quality, resubmission count, and whether submitters can restate the actual reason for rejection.
- Variables: clarity of the stated criterion, whether evidence is cited, whether the suggestion is actionable, resubmission rate, movement toward the criteria on resubmission, abandonment rate, and perceived procedural fairness.
- Methodological caution: a higher resubmission rate is not itself evidence of better feedback — separate resubmissions that move toward the standard from resubmissions that just retry with cosmetic changes, since the latter usually signals feedback that was still too vague, not an uncooperative submitter.
Where it stops holding
In one-off review episodes with review cycles measured in weeks or months (grant review, academic publication), a submitter has little chance to act on specific direction before the next opportunity even exists, so detailed feedback mainly sustains trust in the process rather than changing this attempt's outcome. In fast-iteration workflows with review cycles measured in hours (pull request review), a concrete, verifiable next step directly determines whether the submitter can fix it within the same day, and specificity matters more than the fairness perception itself.
Safety, privacy, and anti-abuse decisions cannot disclose the full basis for a determination; they can only offer a safe, high-level reason that resists reverse engineering, alongside an independent appeal or human-review path. When no viable revision exists — the request conflicts with a hard policy rather than a fixable gap — the honest response is to say so plainly rather than manufacture a plausible-sounding but nonexistent path forward.
Scale imposes its own limit as automated determination grows: at the volume of millions of automated decisions (platform account actions), individualized, fully specific reasons are not economically feasible, and practice falls back to batched, category-level reasons — at which point "actionable" degrades from "specific to this submission" to "at least identifies which class of problem this is," a real compromise forced by scale rather than a design failure.
Applying it
- Tie the rejection to a specific criterion and specific content, distinguishing a required fix, an optional improvement, and a non-negotiable constraint.
- Provide at least one verifiable next step, or state plainly why resubmission is not an option, rather than substituting vague encouragement for direction.
- Let submitters ask questions, supply additional evidence, and request independent review, while preserving the original rationale rather than quietly rewriting it after an appeal.
- Verification: sample submitters and check whether they can restate the actual reason and the next step in their own words; track whether the same class of error recurs for the same submitter over time — good feedback should shrink that rate, not just increase resubmission counts.