GenerateRandomSearch

Judging Allocation Generator

Splitting entries between judges looks like shuffling until you write down the rules. Nobody should judge their own entry or their own team's. Judges have different amounts of time. Someone who judged an entrant last round should probably not judge them again. Those are constraints, and shuffling until a draw happens to satisfy them fails exactly when the rules are tight — which is when you needed the help.

What this generator does

Assigns every entry to a judge, balancing the load across the panel and honouring the rules you set. It is a solver rather than a shuffle: it finds a valid allocation where one exists, including in the tight cases where only a few arrangements work, and when no valid allocation exists it says which rules it could not satisfy instead of quietly ignoring one. It also takes last round's allocation as history and avoids repeating a pairing where it can, which is what stops the same judge seeing the same entrant every time.

How to use this tool

  1. List the entries to be judged, one per line.
  2. List the judges, one per line, with a capacity after a comma if they cannot all take the same number.
  3. Add the rules: who must not judge what, and anything you want to keep from last round.
  4. Press Allocate, and read the notes — anything the rules would not allow is reported by name.

Understanding the controls

Entries
One per line — a project title, a team name, an application reference. These are what get shared out. Repeats are numbered rather than merged, because two teams really can submit under the same title.
Judges and capacity
One per line. Add a comma and a number to cap how many entries that judge takes: “Priya, 4” gives Priya at most four. Judges with no number share whatever is left. This is what lets a panel of mixed availability work without splitting into two events.
Conflicts
Pairs that must not happen — a judge and their own team's entry, a reviewer and an application from their department. These are hard rules: the solver will report failure rather than break one, which is the behaviour a conflict-of-interest policy requires.
Balance the load
Spreads entries as evenly across judges as the capacities allow, rather than filling one judge before starting the next. Usually what you want; turn it off if you would rather a few judges take everything and the rest be reserves.
Previous round
Allocations already made, to avoid where possible. Unlike a conflict this is a preference rather than a rule, so a repeat happens only if avoiding it would leave the allocation impossible.

Worked examples

A panel with mixed availability
Twenty entries and four judges, one of whom can only take three. The other three take between five and six each rather than one judge taking eleven.
A conflict that is honoured
A mentor listed as conflicted with their own two teams never receives either, even when the allocation is otherwise tight.
Rules that cannot all hold
Three entries, three judges, and each judge conflicted with two of the three. The tool reports that it is impossible and names the entries it could not place, rather than assigning one anyway.
A second round
Paste round one's allocation as history and the same judge rarely sees the same entrant twice — unless avoiding it would make the round impossible, in which case the repeat is flagged.

Common use cases

  • A science fair or school competition with staff and parent judges
  • A hackathon or pitch event where mentors must not judge their own teams
  • An awards shortlist split between a panel with different availability
  • Grant or bursary applications shared between reviewers
  • Any competition where a conflict of interest has to be provably avoided

How this generator works

Every rule here is a statement about one entry and one judge, which is a much simpler shape than it first appears and is why no new solver was needed for it — the site's existing constraint allocator already works in exactly those terms, with a capacity per judge on top. The search makes several passes at decreasing strictness: it first tries to satisfy every hard rule, every preference and the history; then relaxes the history; then the preferences. Hard conflicts are never relaxed. If no arrangement satisfies them it stops and reports which rules are in conflict, because for a judging panel the useful answer to an impossible request is which rules cannot all hold — not an allocation that silently breaks one of them.

Randomness and fairness

The randomness decides between allocations that are equally valid, so running it twice on the same input gives different — and equally fair — results. That matters for a judging panel: an allocation that is always the same for the same list invites the suggestion that it was arranged. The choice comes from the browser's cryptographic random number generator by default. A seed switches it to a reproducible, non-cryptographic generator so an allocation can be regenerated and shown to be the one that was published; that mode is not cryptographically secure, which is exactly what makes it reproducible.

For how randomness is produced across the whole site, see how Generate Random works.

Assumptions this tool makes

  • Each entry needs exactly one judge in this round.
  • Every conflict that matters has been entered; the tool cannot infer them from names.
  • Capacities are upper limits rather than targets, so a judge may end up with fewer.

Limitations and good to know

  • It allocates entries to judges, not to time slots. If your judging happens in scheduled sessions you will need to lay those out separately once you know who has what.
  • There is no notion of judge expertise or subject matching — a rule can say who must not judge something, but not who is best placed to.
  • Every entry is assigned to exactly one judge. If you need two or three independent scores per entry, run it once per scoring round and use each round's output as the next round's history.
  • Soft preferences are honoured where possible and dropped where not, so a heavily constrained panel can produce an allocation that satisfies every hard rule and few preferences. The notes say which.
  • It does not know your conflict-of-interest policy. Conflicts are only avoided if you enter them, and a missed conflict is invisible to the tool.

Common mistakes

Entering conflicts as preferences and hoping they hold
A conflict of interest is a hard rule. Enter it as a conflict so the tool reports failure rather than quietly breaking it — that report is what protects the decision if it is ever challenged.
Assuming an even split when capacities differ
Balance spreads the load as evenly as the capacities allow, which is not the same as equally. A judge capped at three gets at most three, and the rest of the panel absorbs the difference.
Re-running to get an allocation you like better
Every allocation the tool returns satisfies the same rules, so re-rolling changes nothing except who got what. If you keep re-rolling until it looks right, the rule you are applying is one you have not written down.
Treating an impossible result as a bug
It is an answer. Some sets of rules genuinely cannot all hold, and the tool names the ones in conflict. Remove or soften one, or add a judge.

Practical tips

  • Publish the conflicts list alongside the allocation. A panel that can see which conflicts were declared can see that they were honoured.
  • Run it once and keep the output. Pasting it back as history for the next round is the whole benefit of having it in a tool rather than a spreadsheet.
  • If it reports impossible, add a judge before you start removing conflicts — the conflicts are usually the part you cannot negotiate.

Troubleshooting

It says the allocation is impossible
Too many conflicts for the panel size. The notes name which entries could not be placed. Adding one more judge is normally the fix, and is preferable to relaxing a conflict.
One judge has far fewer entries than the others
Either their capacity is lower, or their conflicts rule out most of the entries. Check both — a judge conflicted with half the field cannot take an equal share.
A pairing from last round has repeated
History is a preference, not a rule, so it is dropped when honouring it would make the round impossible. The notes flag every repeat it had to allow.

Privacy and your data

Entry titles, judge names and conflicts stay in this browser. Nothing is uploaded, nothing is written into the page address, and the site has no endpoint that could receive them. This matters more here than on most pages, because a conflicts list is a statement about real people's relationships — treat it as you would any other confidential panel document. Analytics records only that the tool was used and how many entries and judges were involved.

Frequently asked questions

Why not just shuffle the entries and deal them out?
Because shuffling has no way to satisfy a rule. It can only be re-rolled until a draw happens to comply, and the tighter the conflicts the longer that takes — until, on the genuinely constrained panels where you most needed help, it never succeeds and you cannot tell whether that is because it is impossible or because you were unlucky. A solver answers that question.
Can one entry go to more than one judge?
Not in a single run. If you want two or three independent scores per entry, run it once per scoring round and paste each round's output in as history, which also stops the same judge seeing the same entry twice.
What happens if the rules cannot all be satisfied?
It tells you, and names the entries it could not place and the rules that blocked them. It never returns an allocation that quietly breaks a conflict — for a judging panel, an answer you cannot trust is worse than no answer.
Is the same allocation produced every time?
No, unless you enter a seed. Different valid allocations are equally fair and varying them avoids any suggestion that the split was arranged. A seed makes it reproducible when you need to demonstrate that the published allocation is the one the tool produced.
How is this different from the peer review pairing tool?
Peer review pairs people with each other — everyone reviews and is reviewed, and nobody reviews their own reviewer. This assigns items to people, where the judges are not themselves being judged and each has a capacity. Different shapes, different rules.