Peer review workflows

When peer review is the right call

Peer review works when you want students to read each other's writing and name what's working — not when you want a second grader. The reviewer writes prose feedback; they don't score the rubric, return work, or see your gradebook. The audience is the author, not you.

Good fit: revision-driven units, opinion writing, narrative drafts — anything where reading another student's draft sharpens what good looks like. Bad fit: binary-correct work (mechanics drills, short-answer comprehension), where an answer key says it better than a classmate could.

Two practical considerations before turning it on:

• Class size of at least four. Peer review with a roster of three is mostly people reviewing the same two classmates over and over. Below four it's awkward.
• Submissions need to be in first. Reviewers can't review a draft that hasn't been submitted. If your due date is fixed, plan to assign reviewers after the submission window closes, not before.

Enabling it on an assignment peerReview.enabled

Peer review lives inside the assignment-creation modal, near the bottom. Tick Enable peer review and the panel unfolds — four fields:

• Reviewers per submission reviewersPerSubmission — how many classmates to assign to each student's work. Default 2. Target, not a cap. Assign more if you want; the manager keeps showing the target as your guide.
• Anonymous reviews anonymous — whether reviewer and author see each other's names. Default on. The anonymization section below covers what flips.
• Review deadline endsAt — when reviews are due. Defaults to the assignment's own dueAt. Advisory — the server accepts late submissions — but shown in the reviewer's queue and your tracking view.
• Grade weight peerReview.gradeWeight — 0-100, default 0. When above 0, the reviewer's own grade picks up that percentage based on how many of their assigned reviews they completed. See the grading section for what this measures and what it doesn't.

Peer review can be enabled on an assignment that already has submissions, and turned off later. Existing reviews stay readable to everyone involved; new reviewers can't be assigned once it's off.

How reviewers get assigned

Two paths: pair students by hand, or fan out automatically. Both go through the same Peer reviews manager.

The manager opens from a button on the teacher's view of the assignment card. It's a table with one row per submission. Each row shows:

• The author's name
• The reviewers already assigned, each with a status pill (assigned, in-progress, submitted, responded)
• A dropdown of eligible classmates to add as a new reviewer

The dropdown excludes the author (no self-review) and anyone already assigned to this submission (no double-booking). A reviewer assignment can be removed any time before the reviewer's status leaves assigned — once they've started typing (in-progress) or submitted, the row is locked. If the feedback turns out off-base, talk to the reviewer or author directly; the assignment itself stays on record.

Auto-fanout

The manager's Auto-assign reviewers drawer fills empty slots in one shot. Pick a number (defaults to the assignment's reviewers-per-submission target), click Auto-fanout, and the server picks reviewers from the roster for every submission still short of its slate. Self-review is excluded, duplicate (submission, reviewer) pairs are skipped, and existing pairings stay put. Re-running the button is safe.

In group mode (peer review enabled on a group assignment), the unit changes from student to group. Each group is assigned N other groups' submitted docs to review. Reviewer-group identity is hidden from the reviewed group until you reveal it from the manager.

Reviewer progress column

A Reviewer progress column on the manager shows each reviewer's completion ratio across their assigned reviews — "2/3" plus a thin red progress bar. Read it before the deadline to see who's pulling their weight and who needs a nudge.

What reviewers are asked to write

The review surface is one big text area — prose only. Reviewers type a paragraph (or three) about what they noticed in the author's piece. There's no rubric to score, no checklist to tick, no per-criterion field. The placeholder reads: "What's working well? What could be stronger? Be specific and kind."

One textarea, one piece of feedback. If you want to shape the response, put the prompts in the assignment instructions — reviewers see the full instructions panel above the doc when they review.

Per-criterion reviewer prompts

The rubric editor has a Reviewer prompt textarea on each criterion. Whatever you write there surfaces above the feedback textarea as a "What to address" block — one bullet per criterion, criterion name on top, your prompt underneath. The reviewer still writes free prose; the prompts just anchor what to notice.

The reviewer's view

When a reviewer is assigned, two things happen: an in-app notification lands in their feed, and a new row appears in their reviewer queue. Clicking either opens the peer-review workspace — a split panel built specifically for reading-while-writing.

Left pane: the author's submitted doc, read-only, with the assignment instructions pinned above. Right pane: a textarea for feedback. Anything typed survives close-and-reopen.

Reviewers can only reach the doc body through this surface. The regular doc-read path won't authorize them — peer review uses a dedicated query (peerReviews.getForReview) that grants access to this one submission only. Reviewers can't browse the author's other work, see their drafts, or open an older version. One review, one window in.

When the reviewer hits Submit feedback:

• The row locks (status flips to submitted)
• The author gets a notification
• The textarea becomes read-only — the reviewer sees what they wrote, but they can't revise after the fact

Anonymization — what each side sees peerReview.anonymous

Anonymous mode is on by default. Here's what flips when it's on (and what doesn't):

What the reviewer sees

• The author's name is replaced by the literal string (anonymous submission)
• The document title is also hidden — replaced with the same string — because document titles often contain author names ("Ava's draft 2") and leak identity unintentionally
• The doc body is shown verbatim; if the author wrote "Hi I'm Ava" inside their own piece, that's on them
• The notification announcing the assignment says "a peer's submission" rather than naming the author

What the author sees

• The reviewer's name is replaced by "Anonymous reviewer"
• The notification that arrives when feedback is submitted says "A peer reviewer reviewed your submission"
• The feedback text is shown verbatim — same rule as above; if a reviewer signs their feedback they've outed themselves

What you (the teacher) see

Everyone. Always. The anonymity flag has no effect on teacher views — your manager table and your read of any individual review show real names regardless of the setting. You're the accountable party for grading; you can't grade what you can't see.

The author's view

When a peer's feedback comes in, the author sees a new Peer feedback section inline on their own assignment info panel — same place they see your teacher feedback and the rubric, just a separate block. Each review is its own card, in order of arrival.

Each card shows:

• The reviewer's name or "Anonymous reviewer", depending on the assignment's anonymity setting
• The timestamp the review was submitted
• The full feedback body, rendered with light markdown (bold, italics, lists, links — same renderer used everywhere else in Red Stet)
• A reply form (described in the next section)

Reviews still in assigned or in-progress — a reviewer was picked but hasn't submitted yet — stay hidden from the author. The author has no way to learn who's been asked to review their work or whether anyone is stalling. They see only completed reviews. If no one submits, the section stays empty.

The author's one-shot reply authorResponse

Below each piece of peer feedback, the author gets a single reply textarea. They write a response — agreeing, pushing back, asking for clarification, thanking the reviewer — and submit it. Once submitted, the form disappears and the reply is shown alongside the feedback as a permanent record.

One reply per review. Not a thread, not a back-and-forth, not a chat — one shot. The reviewer is notified that the author replied, the review's status flips from submitted to responded, and that's the end of the conversation.

Provenance fingerprint on peer work

The typing-recording layer that proves a doc was written follows the document into peer review.

When a reviewer opens a peer's submission, the doc header shows a small chip: "Provenance verified · N sessions" in sage green if the chain of recorded sessions is intact, or "Chain broken" in red if it isn't. Clicking the chip gives a one-line summary — session count, total keystrokes — and nothing more. The keystroke-by-keystroke data stays sealed.

The chip exists for two reasons:

• Peer trust. Reviewers know they're reading actual writing, not a paste of an LLM output. Their feedback is more honest when they trust the input.
• Identity-blind verification. The chip works in anonymous mode without revealing who wrote the doc. The fingerprint says "this work has provenance"; it doesn't say "this work was written by Ava."

If a piece's chain is broken — sessions don't link up, a paste replaced a recorded session, etc. — the chip flips to the warning state. That's a signal to the reviewer to read the feedback question differently, and a signal to you (the teacher) to look more closely at the original submission.

Teacher's tracking view

The Peer reviews manager doubles as your tracking surface. Each row shows the current status of every assigned review.

Status pills:

• assigned — reviewer picked, no text yet
• in-progress — reviewer has typed something; first autosave fired
• submitted — feedback submitted; author notified
• responded — author posted their one-shot reply

States move in one direction — assigned → in-progress → submitted → responded. A reviewer can't pre-claim "submitted" before writing anything; the author can't reply before the reviewer is done.

Click any row to read the full review — feedback body, author's reply, both names. This is your audit surface: if a reviewer wrote something out of bounds (mean, off-topic, copy-pasted), this is where you find it.

Deadlines and lifecycle states

The endsAt deadline shows up alongside the assignment title in the reviewer's queue, so reviewers know when their reviews are due. As noted in the Enabling section: advisory, not enforced.

Reviewers see their queue with pending reviews on top (oldest first), completed below. Pending reviews carry a colored side bar; submitted ones look quieter.

Lifecycle, end to end:

1. Teacher assigns reviewer → row created with status assigned; reviewer is notified
2. Reviewer starts typing → status flips to in-progress on the first autosave (see below)
3. Reviewer submits feedback → status flips to submitted; author is notified
4. (Optional) Author replies → status flips to responded; reviewer is notified

Unassign works only while the row is still assigned. Once any text has been captured (in-progress) or feedback is in (submitted / responded), unassign refuses — the work has already happened.

Autosave while typing

Reviewer feedback autosaves 1.5 seconds after typing stops. The first autosave flips the row from assigned to in-progress and stays there — your manager surface shows "in progress" the moment any text exists. A "Saved Xs ago" indicator next to Submit updates after each save. Closing and reopening the workspace restores the draft from the server.

Does completing peer review affect the grade?

Optionally yes. The Grade weight field (0-100, default 0) controls this. When above 0, completing assigned reviews adds that percentage to the reviewer's own grade on the assignment. The pipeline reads completed/assigned at score time — full slate gets full weight, partial gets a proportional share.

At the default of 0, peer review stays separate from grading. The manager's status pills are tracking signals for you, not gradebook inputs.

The practical patterns:

• Quick weight (5-10%). Enough that students take it seriously without making it dominant. Pairs with a rubric criterion for review quality.
• Pure participation. Leave weight at 0 and treat the manager's Reviewer progress column as your participation log. Glance at it when you enter grades and adjust by hand.
• Hybrid. Set a small weight (e.g. 5%) AND keep a rubric criterion for "Peer review quality" so the reviewer's work itself gets graded, not just whether they did it.

Related

→ Creating an assignment — the modal-level peer-review settings, in the broader context of every assignment option

→ Grading submissions — how the rubric, comments, and the gradebook work, including how you'd hand-score peer-review participation

→ Setting up your first class — covers roster visibility, which interacts with anonymized peer review

→ Back to the help library

Missing something? Email feedback — this doc grows by use.