A lottery decides which children get a place. It will be disputed — by a family, a board, sometimes a court. So the question is not whether the software runs a fair draw. It is what the school can put on the table months later, when someone asks how a particular result came about.
This note does three things, in order: how enrolment lottery software commonly works today, six requirements a lottery system should meet, and how Verifair answers each — including the three things it still cannot prove.
The short answer · commitment code
a3f9c21e7b40
Twelve characters, computed from the sealed applicant list, the rules in force and the promised draw moment — and published while the draw’s key does not yet exist. Every requirement below is either that idea or a consequence of it.
Part I · how it works today
The draw happens, and then it is gone
What follows is not an accusation against any vendor. It is the ordinary architecture of enrolment lottery software, and several vendors document it themselves.
The key is generated at draw time and not written down. The randomiser is seeded from operating-system entropy mixed with the clock and the process id. Nothing records that seed.
So the draw can never be repeated. Not by the family, not by the school, not by the vendor. Vendor documentation states it directly: every run of the lottery shows different results.
Confidence is then produced socially, in the room. A common practice: run the lottery three times in front of the parents, show the results differ each time, then run it a fourth time and publish that one.
But different results prove variability, not impartiality. A biased randomiser also produces a different list every time. And from outside the room, “the fourth run counts by protocol” is indistinguishable from “we ran it until we liked one.”
The applicant pool is rarely fingerprinted at all. Half the fairness question is not “was the ordering random” but “was the list right”. A draw is changed just as effectively by adding a name or approving a claim. Three demonstration runs never touch that half.
And the record is an audit trail kept by the audited party. Where verification exists, it runs inside the vendor’s own system and produces a single yes.
Put together: the school is asked to be believed, and given nothing to be believed with. That is the actual problem — not dishonest software, but software that leaves honest people unable to demonstrate their honesty.
Part II · what it should be
Six requirements, in the order they have to hold
These are not features. They are the conditions under which a result can be defended, and each is useless without the ones before it. A recorded key means nothing if the list was not sealed first; an independent verifier means nothing if the draw could be re-run until it looked right.
01
Seal the pool before anything random happens
Who is in the draw, what priority each holds, which rules apply — all fixed and fingerprinted, and the fingerprint published. Otherwise the ordering can be honest while the list is not.
Verifair
Locking freezes the full decision projection — tier, weight, score, sibling group — fingerprints it, and publishes a twelve-character commitment code. Editing an application afterwards changes nothing; altering the sealed snapshot makes the draw refuse to run.
02
Let the draw run exactly once — and enforce it in code
“We only run it once” as a promise is worth nothing: nobody outside can check it. The system itself must be unable to produce a second official result, or to quietly discard the first.
Verifair
A second official draw for the same grade and round is refused outright, and execute cannot be undone. Abandoning a published commitment requires a written reason and a second approver, and the next attempt carries a counter printed on the certificate — one attempt is ordinary, three is a question.
03
Do not let the party running the draw choose the key
An unpredictable key is not the same as a key nobody selected. If it is minted by the same system, after that system has seen exactly who applied, the assurance rests entirely on trust.
Verifair
The key is derived, never generated: from the sealed list plus one value produced in public after the commitment — dice thrown in the room, or a signed round from a worldwide randomness network whose round number follows by arithmetic from the promised draw moment. A beacon draw can run unattended on a timer, so nobody sits between the value and the result.
04
Make the result reproducible from what was recorded
Same sealed input, same key, same rules must give the same ordering — every time, years later. Without this, a dispute can only ever be answered with a description of the process.
Verifair
The draw engine is a pure function of the sealed input, the key and the frozen rule set. Verification re-runs it and compares every rank and value. Where the engine version has moved on, the claim is refused outright rather than quietly weakened.
05
Answer more than one question — and be able to say “I can’t”
“Was it altered”, “was it computed correctly” and “did anyone choose the key” are three different questions with three different failure modes. Collapsing them into one green tick hides which one actually holds.
Verifair
Integrity, reproducibility and provenance are checked and reported separately, never merged. A draw held before commitment codes existed reports provenance as not applicable — neither a pass nor a failure, because it was run correctly under the rules of its day and cannot make this particular claim.
06
Let anyone check without the vendor, and without an account
A check that runs inside the vendor’s system is worth something, and it is not independence: the code that ran the draw and the code that checks it come from the same place. And a family should not need a login to see the answer.
Verifair
Every published draw has an open verification page that needs no account — families sign in the same way they applied, with a one-time code to their own email or phone, and the page for a published draw opens without even that. Alongside the answers it offers the sealed inputs and a fifty-line standard-library Python file that recomputes the ordering anywhere: on a laptop, or handed to an AI assistant that can run code.
A whole admissions season, not just a draw
The six requirements make a draw defensible. They are not what makes a season workable. Verifair lives inside the student information system, so an accepted family becomes an enrolled student without an integration project.
- Applying — public portal with no SIS account, one-time codes by email, SMS or voice, multi-programme ranking, live status, seven languages in family notifications.
- Eligibility — fully automatic address and district-boundary checks, document review with appeals, duplicate detection across periods, audition booking and scoring.
- Policy — priority tiers, caps with overflow, weights, two reserve policies, sibling policies, decision tables authored in the console and stored as immutable revisions.
- The draw — multi-programme match by deferred acceptance, a rehearsal that names nobody, a lock screen that stops you on unreviewed documents and likely duplicates.
- Offers — strict rank order, durable deadlines, automatic waitlist advance, exactly three audited overrides, round two.
- Records — hash-chained activity log, verification certificate PDF, encrypted contacts, retention you set per window.
Part III · stated plainly
Three things we still do not claim
Six requirements met is not everything proved. A verifier that overstates is worse than no verifier, so each of these is named on the certificate, in the report the script prints, or both.
That a ceremony operator typed what was rolled. No mathematics catches this — only a recording, a room of witnesses, and a second name in a log nobody can edit. Schools that want this link closed by mathematics choose the public beacon.
That each random value came from the sealed key. That step needs real application ids, and a public document must not carry them. The script checks everything built on top, and anyone with authorised access to the id export closes the last link with the same script.
That the ranking turned into seats correctly. Seating is not top-N — reserved buckets, cap overflow, sibling policies and deferred acceptance all decide it. Rewriting that in the script would end its one virtue: a hash, an exponent and a sort, auditable in an afternoon. The script says so; seating is covered by the integrity claim.
One more thing we are careful not to claim: fairer mathematics. A weighted lottery is statistically the same however it is implemented, and you should distrust any vendor who tells you otherwise. Verifair does not change anyone’s odds. It changes what can be shown afterwards — which, on the day a result is challenged, is the only thing anybody actually has.
If you would like to see the draw, the certificate and the verification page on your own data, we will arrange a walkthrough.
If you are planning your next admissions season and would like a walkthrough on your own capacities and priority rules, contact us and we will arrange it.
