From a pile of proposals to decisions that hold up.

What that looks like in the product

• A review queue per reviewer, scored on your rubric

  Each reviewer opens their own assignments and nobody else's. Every score has to name a criterion in your evaluation plan and land inside that criterion's range, so two reviewers are always answering the same question.

• Conflicts of interest, declared and enforced

  A reviewer who recognises a colleague or their own employer can step back from a proposal. The rule the button follows and the rule the server enforces are the same rule, and a review that already counted toward a decision cannot be quietly dropped.

• Decide in bulk, then mail on purpose

  Accept or reject a batch in one action; anything already decided is skipped and reported rather than overwritten. Deciding never sends mail. The decision email is a separate step you preview first, and the send is bound to the exact text you read.

• The loop around the decision

  Proposals arrive through a public form with no account required and a link back to an unfinished draft. Accepted talks go onto a grid that refuses a double-booked room or speaker. The program then publishes itself as pages, an embeddable iframe, and a calendar file.

There is a drafting assistant, and it is deliberately kept out of the judgement: it writes a decision note from the feedback your reviewers already left. It does not score a proposal and it does not decide one. That call stays with the program chair.