Paper Review Assignment: Two Qualified Reviewers on Every Submission, Within Load

Two reviewers per paper, three hard rules and a slate that keeps moving

A program committee gives each submission two reviewers. The policy has three hard rules: the reviewer's topics must match the paper, the reviewer must not be a co-author or otherwise conflicted, and nobody goes over a personal load cap. Within those rules the best topic match wins, and ties break in a fixed order. Doing that for a few dozen papers is careful work. Keeping it right through declines, withdrawals and late conflicts is where it slips.

Submissions sit in an Airtable base, the reviewer roster with topics, status, caps and current load is a Notion database, the policy and topic-match table are in Google Drive, and reviewers write in by email. When two reviewers decline their whole slate on the same afternoon, their papers have to move in a defined order while every reviewer's load stays true in Notion.

Who works in the room

The review cycle lives in a single Kylon room. Myco is the default agent, so any question about who reviews what lands with it. The draft roster goes to Nova, whose specialty is checking it, and messages from reviewers go to Ryan, which works the committee mailbox as the chair it is drafting for, checked on every call. When a decline arrives, Ryan opens a thread for Myco whose first message names the reviewer and the affected paper ids, and Myco leads it until the reassignment is approved.

The review cycle, change by change

Every reassignment runs under the full policy, and the program chairs approve the result before Airtable, Notion or the calendar changes.

When the slate changes after it is published

Declines come as short emails: a reviewer has a new job or a family matter and cannot take any papers this cycle. Myco marks the reviewer on leave and walks the affected papers from the lowest id up, giving each the best-matching reviewer with load to spare and no conflict. Because the walk goes in order, two papers competing for the same strong reviewer always resolve the same way, and Ryan drafts one reply on each decline thread naming the papers that moved.

Not every change moves papers. A withdrawn submission frees two slots and reduces two loads, but nobody is assigned in its place. A raised cap changes nothing until a later change needs the room. A lowered cap moves only the papers above the new limit. Myco says in the thread which of these it is doing and why, so the chairs approve a scope as well as a list.

What the checks catch

• A co-author or same-lab reviewer slipping onto a paper during a reassignment
• A reviewer whose Notion load still counts a withdrawn paper
• An out-of-scope submission touched during a re-run, though the policy leaves it alone
• A raised cap read as a reason to reshuffle papers that were already correctly placed
• A paper missing from the draft roster altogether, not only lines that are wrong

What stays with people

• Approving every assignment and reassignment before Airtable or Notion changes
• Judging a declared conflict the policy does not spell out
• Sending each reply to a reviewer, which Ryan drafts
• Setting load caps and signing the close-out

Integrations in this workflow

Kylon is not a conference submission system and does not replace the one the committee runs. It sits between the records and mailboxes the desk already has, so the handoffs happen in one place instead of across inboxes.

• Airtable
• Gmail
• Google Calendar
• Google Drive
• Notion
• Slack

• Airtable holds the submissions with both reviewer fields, status and the close-out records
• Notion keeps the reviewer roster with topics, status, load caps and current load
• Google Calendar carries the five track discussion sessions, booked after the chairs approve
• Google Drive stores the assignment policy, the topic-match table and the draft roster
• Gmail is the committee mailbox for declines and conflicts, and a reply leaves only when a chair sends Ryan's draft
• Slack is where track chairs flag conflicts and topic questions between emails

Where to start

Run one track through a full cycle first. Connect the Airtable base and the Notion roster, and give the room guidelines one rule: every change runs under the full policy in ascending paper id order, and the program chairs approve it before a reviewer's load or a paper's slate changes.

“Two reviewers per paper is the easy part. Keeping every load true after the fifth change is the work.”

Set it up with your agent

Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it.