Verifair

Admissions lotteries your school can defend

Run a weighted, auditable enrollment lottery on Campus — for one school or a whole district. Seal the pool with a published commitment code, derive the draw key from entropy produced after that seal, clear ranked programmes in a single match, reproduce the result months later, and keep a hash-chained audit trail behind every seat you award.

01

Priority rules follow your policy, not our code

Preferences, caps, reserved seats, weights and score ordering live in a versioned rule set, and the classification table behind it is authored in the admin console rather than deployed: edit a draft, publish it, and that revision becomes immutable. A rule set pins the exact revision a draw will seal. The tiers below follow the New York charter school example; the order of preferences is always school policy.

Returning students

Exempt from the draw. Their seats are reserved and taken off available capacity before the pool is built.

Siblings

Siblings can share one lottery number across a district-wide group, or upgrade each other’s waitlist position once one of them is seated — each school’s frozen rule set decides which policy applies.

District residents

Residency preference by district or community school district, with evidence verified before the draw is frozen.

Staff children

Capped as a percentage of total enrollment. Applications above the cap are demoted to another tier and re-ranked there — a cap costs priority, not the application.

Reserved seats

A cap is a ceiling; a reserve is a floor. Set aside a fixed count or a percentage of seats for a subgroup and choose whether general or reserved seats fill first. A reserved seat nobody eligible claims stays empty rather than leaking into the general pool.

Weighted subgroups

One at-risk subgroup may carry extra weight. A 1.6x weight means 1.6x the odds of ranking ahead — never a guaranteed seat.

Score-based ordering

A tier can be ordered by an assessment or audition score ahead of the random key, with the direction and scale you define and a stated policy for applicants who have no score — bottom of the tier, or out of the draw. A score never replaces the key; ties still break on it.

Equity tiers

Homeless, foster care and military family tiers ship built in, beside the returning, sibling, residency and staff-child codes. The catalogue itself is a school-side parameter list, so a preference your state adds next year is a catalogue entry, not a release.

Late applications

Two policies, and the rule set says which one applies: a late application either skips the draw and joins the bottom of the waitlist in arrival order, or enters the draw with every priority it claimed dropped.

02

How a single draw runs

Eight steps, in the same order, every time. The engine consumes a frozen projection of the applicants and the rule set — it never re-reads a live application mid-draw.

  1. Freeze

    Cut the applicant list, resolve every tier, weight, score and reserve eligibility once, fingerprint the snapshot, and publish a twelve-character commitment code before any randomness runs.

  2. Exempt

    Returning students leave the pool and their seats come off the available capacity.

  3. Seed

    The draw key is derived from the sealed list plus a value produced after the commitment — dice in the room or a signed public beacon round — never chosen by whoever runs the draw.

  4. Key

    Every application receives a random key; weighted applications get their better odds from the key itself.

  5. Rank

    Applications are ordered by tier, then score, then key, with capped overflow demoted and re-ranked until the order is stable.

  6. Allocate

    Seat buckets fill in the order your reserve policy sets, and inside a bucket strictly by the ranking. An applicant whose tier hit its cap with nowhere to overflow to takes no seat at all.

  7. Waitlist

    Everyone who missed a seat keeps their exact lottery position on the waitlist.

  8. Seal

    Results, derived key, input hash and commitment are written to a hash-chained audit log and published.

03

One district, one family view

A family applying to four schools in your district used to carry four portal links and read four separate results. One door now opens all of it — a district address, a one-time email code, and every application that family holds anywhere in the district on a single list. Each school still runs its own lottery on its own capacity and answers for it alone; what changed is the application steps and the tracking around them.

One door for the district

Families enter at a district address and sign in with a one-time code — no SIS account. Every per-school link already handed out keeps working exactly as before, and the application window screen now hands out the district address instead.

Every application on one list

Grouped by child, then by school, with the outcome beside each row: still in the draw, waitlisted at a stated position, or an offer with its countdown. An offer about to expire is pushed to the top — the most expensive thing to miss in a district-wide application is a deadline nobody noticed.

One form, many schools

Apply once and pick the schools; each school gets its own application and its own honest result, and one that fails stays selected instead of quietly disappearing. “Apply for another child” carries the guardian’s answers over and deliberately drops the student’s — a sibling should not open their sister’s form.

Claims travel, approvals never do

Seven portable priority claims pre-fill the next application, and a family may reuse a document it already uploaded — but only when it asks. Sibling and staff-child are asked again at every school, and a verification granted at one school is never carried to another.

Accepting one seat releases the others

Accepting an offer drops that student’s other pending offers across the district and advances those waitlists the same moment — after a by-name preview of exactly what will drop. Waitlist places are kept: a family can hold a seat and stay in line at the school it wanted more.

Withdrawal has a deadline

When a family accepts elsewhere while already holding a seat, the registrar gets a queued request with a working-day deadline — remind, escalate, then apply. Until it is worked the child counts twice in two schools’ rolls, so the request is never left to wait forever.

04

One clearing when families rank programmes

Draw programmes one after another and you eventually seat a child at the programme that happened to clear first, over one who ranked above them. A match clears every participating programme at the same moment, from one sealed input and one derived key. It covers the programmes of a single school: a match that spanned schools would decide two institutions’ capacity from one seed, which neither could answer for on its own.

Ranked programmes

Families rank the strands a school runs in a grade — general, dual-language, a maths or a science track. A match needs two programmes, not two ticked windows: one application window offering two programmes in the same grade already qualifies.

Deferred acceptance

Student-proposing deferred acceptance: no seat is final until the run settles, and an applicant displaced by a better-ranked one falls to their next choice rather than out of the run. Ranking honestly is the best a family can do — there is nothing to game.

Reserved seats hold inside a match

A match fills seat buckets through the same function a single draw uses: in your reserve policy’s order, by ranking inside a bucket, skipping whoever is not eligible. An unclaimed reserved seat stays empty, and every seated record names the bucket its seat came out of instead of declaring them all general.

One freeze, one proof

A match freezes, publishes its own twelve-character commitment code, derives its key from entropy produced afterwards and verifies exactly like a draw. The rehearsal fills seats through the same code path as the real run, so the distribution you approve on screen is the one you get.

05

Proof, not promises

“Was the list edited?”, “was the draw computed correctly?” and “did anyone choose the key?” are three different questions — Campus checks and reports each one separately, years after the season ends and on paper when a board or an authorizer asks.

Integrity check

Re-hashes the published results and compares them with the hash sealed at execution. Detects any later edit without re-running the engine.

Reproducibility check

Re-runs the draw with the recorded key and the frozen input, then compares it rank by rank against what was published.

Provenance check

Confirms the draw key was derived from the sealed list and public entropy recorded after the commitment — not generated by whoever ran the draw. Reported on its own, never folded into a single pass/fail.

Commitment code

Freeze publishes a twelve-character code from the sealed list, rules and promised draw moment — while the key still does not exist. Alter the sealed snapshot afterwards and the run refuses to execute.

Public verification

A public draw kiosk for the room, an open verification page that reads without running anything and needs no account, and a single-file Python script — standard library only — that anyone can run offline to recompute the ordering from the published bundle.

Draw certificate

A dated, aggregate-only PDF stating what was drawn, under which rules and from which sealed input. The server issues it from the run itself; nothing is typed up afterwards.

06

Two surfaces, one service

Staff and families never share a screen, a login or an endpoint.

Enrollment periods

  • Grade capacities and returning student counts
  • A rule set bound to each period
  • Live application funnel

Application form

  • Fields, sections and validation are configured, not coded
  • Answers land on the application beside the priority claims
  • The same form designer the rest of Campus uses

Rule authoring

  • Priority tables edited in the console, not deployed
  • Drafts stay editable, published revisions never move
  • Each rule set pins the revision a run will seal

Lottery run

  • Freeze, execute, publish and verify in one stepper
  • Rehearsal before the real draw
  • Duplicate and evidence gates before freeze
  • Multi-programme match on the same freeze and proof path

Applications & scores

  • Search, scoring and withdrawals
  • Portable priority claims pre-fill each new application; documents reused only when a family opts in
  • Duplicate detection across the period and across the district
  • Claim review with proof documents; reviewers cannot freeze or draw

Evaluations & auditions

  • Sessions with capacity, families book their own slot
  • Reminders, attendance and no-shows
  • Scores entered singly or in bulk, straight into the ranking

Offers & waitlist

  • Seat offers with enforced response deadlines
  • Accepting one offer drops other pending offers and advances those waitlists
  • Registrar withdrawal queue when a family accepts at another school

Reports & audit

  • Projectable results for public sessions
  • Hash-chained audit trail
  • Board-ready reporting and exports

Privacy & erasure

  • Erase one applicant, or a whole period, on request
  • A preview of every field and file a run would touch
  • Refused while a draw or an enrollment still depends on it

Guardian portal

  • District or school entry — one-time code sign-in, no SIS account
  • One application list across every school in the district
  • Accept with a preview of every other offer that will drop

Planning your next admissions season?

See a complete lottery run — freeze, draw, publish and verify — on your own capacities and priority rules.

Google PlayApple Store

© 2026 Mersys Campus