Rejected work
When a reviewer rejects one of your annotations, the work comes back to you — with the reviewer's comment, a way to revise it, and a one-time way to ask for a second look if you think the verdict is wrong. This page is the annotator's side of that loop; the reviewer's side is in Review.
What happens when work is rejected​
- The annotation is marked rejected, stamped with who reviewed it, when, and the reviewer's comment (a project can require a comment on every rejection).
- You're notified — one rollup per reviewer and project, Review complete on "Project": N accepted, M rejected. Please log in and revise the rejected tasks, in the bell and by email, linking to the project's task list. It goes out when the reviewer's queue for the project drains, and any verdict still unannounced after an hour is swept out by the digest job, so a rejection never sits silent indefinitely. A reviewer isn't notified about rejecting their own work.
- Credit: on speech projects a rejected clip earns nothing, since credit lands at validation. If a reviewer flips an earlier accept to reject, the annotation credit is reversed — but only while it is still unpaid; paid-out work is never clawed back.
- Opening the task shows a Rejected in review banner with the comment. Unlike accepted or fixed work, a rejection carries no lock notice — you revise it in the editor.
The "Your rejected work" card​
On the project dashboard, annotators with rejections on that project see a Your rejected work card. It is hidden entirely when you have none. It lists your rejected annotations (skipped tasks excluded), most recently reviewed first, up to 50:
- Task # and rejected <date>;
- the reviewer's comment, quoted, when there is one;
- the row's state: a Request re-review button, Re-review requested (a request is open), or Rejection upheld (a request was answered with another rejection).
Revising​
Open the task — from the rollup notification's link, the project's task list, or the label stream — fix your annotation and save. The dashboard card is about the verdict; revising doesn't change the recorded rejection until a reviewer issues a fresh verdict.
Requesting a re-review​
If you believe the verdict is wrong rather than the work:
- Click Request re-review on the row. The dialog repeats the reviewer's comment.
- Write your reason — required, at least 10 characters (up to 2000). Send request stays disabled until then.
- Send. The card flips to Re-review requested and a toast confirms The reviewer has been notified.
What that does:
- The annotation goes back into the reviewer's stream with your reason shown above the verdict buttons (see Rejection disputes).
- The reviewer who rejected it gets a Re-review requested on "Project" notification (bell + email) quoting your reason, with a link to the review stream. If you rejected your own work, nobody is pinged.
- An
annotation.disputeaudit event is recorded.
Outcomes​
The reviewer gives a fresh verdict — accept, fix & accept, or reject again. Whatever it is:
- the request is closed, and you are always notified of the outcome, even when the rejection stands;
- accept / fix & accept credit your ledger exactly like any other acceptance (never twice on top of a crowd credit for the same annotation);
- reject again shows as Rejection upheld on the card and is final for that verdict.
The rules​
- Only your own annotations, and only ones currently rejected.
- One open request at a time per annotation — a second send while one is open is refused (A re-review is already requested).
- One request per verdict. Once a request has been answered with a rejection, that rejection can't be disputed again (This rejection was already re-reviewed and upheld). If the reviewer later issues a new verdict on their own, a fresh request becomes possible for it.
Gotchas​
- Notifications arrive in batches, not instantly. The rollup is sent when the reviewer's queue drains, or by the hourly sweep — check the dashboard card if you want the current state now.
- Email depends on your settings. The bell entry is always there; whether you also get the email follows your email volume and the platform's rules.
- The card is per project. Rejections on other projects show on those projects' dashboards.
- Re-review is about the verdict, not the work. If the reviewer's comment is fair, revise instead — a request with a weak reason just ends as Rejection upheld.
What's next​
- Review → — who reviews, what enters review, the accept / fix & accept / reject outcomes
- The reviewer's workflow → — how a disputed item looks on the other side
- Task lifecycle → — where review state sits in a task's life
- Contributions & payment → — why credit lands at validation
- Notification centre → — where the review rollups land