Rejection: Handle Feedback & Revise

When a reviewer can't approve a submitted calc, they reject it with a written reason. The calc moves to rejected, you're notified with that reason, and you respond by creating a revision that addresses the feedback and resubmitting.

What happens on rejection#

• The reviewer must supply a reason — rejection without one isn't allowed.
• The calc's status becomes rejected, and the reason is stored on the calc.
• You receive a notification with the reviewer's reason so you know exactly what to fix.
• The rejection is recorded in the calc's event timeline.

Revise to address the feedback#

1. Open the rejected calc and create a revision. The rejected calc becomes the parent of your new revision, and the new revision joins the same chain with the next revision number.
2. The revision copies the original's params as a starting point. Make the changes the reviewer asked for.
3. Resubmit. A client revision returns through the normal Submission flow; the new revision carries the original's submission grouping forward so it stays grouped with related calcs (for example a linked post) in the reviewer's queue.

Because the rejected original stays in the chain, the full history — original, rejection reason, and each revision — is preserved and visible in the revision switcher and the event timeline. See Revisions: Parent & Source Tracking.

Rejection vs. "Reviewed with Changes"#

Not every change a reviewer makes is a rejection. If a reviewer refines your work themselves rather than sending it back, they create a revision and the original is marked superseded instead of rejected. A superseded calc doesn't show a rejection badge and doesn't generate a rejection notification — it simply means a newer revision replaced it.

For where these states sit in the overall flow, see Calculation Lifecycle.