Verifair

Admissions lotteries your school can defend

Run a weighted, auditable enrollment lottery on Campus: a frozen applicant list, a recorded seed, results that can be reproduced months later, and a hash-chained audit trail behind every seat you award.

01

Priority rules follow your policy, not our code

Preferences, caps, weights and reserved seats 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 rules 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 either win seats together or upgrade each other’s priority once one of them is seated — on the waitlist as well.

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.

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.

Late applications

Applications that arrive after the deadline skip the draw and join the bottom of the waitlist in arrival order.

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, then hash the result together with the rule revision that produced it.

  2. Exempt

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

  3. Seed

    A cryptographic seed is generated and recorded so the whole draw can be replayed later.

  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

    Reserved buckets and general seats are filled following your reserve and sibling policy.

  7. Waitlist

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

  8. Seal

    Results, seed and input hash are written to a hash-chained audit log and published.

03

Proof, not promises

“Was the list edited afterwards?” and “was the draw computed correctly?” are two different questions, and Campus answers them separately — years after the season is over, 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 seed and the frozen input, then compares it rank by rank against what was published.

Tamper-evident input

The frozen applicant projection is hashed at freeze time. If that record no longer matches its hash, the run refuses to execute.

Public draw

A live public run mode and a kiosk display open the draw to families — the digital equivalent of holding the lottery in the school hall.

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.

Separation of duties

Claim review is a role of its own. A reviewer works their own school’s queue and cannot freeze, draw, publish, or read the audit log they are the subject of.

04

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

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

Applications & scores

  • Search, scoring and withdrawals
  • Duplicate detection across the period
  • Claim review with proof documents
  • Validated addresses and an anonymous applicant map

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 response deadlines
  • Waitlist movement in exact lottery order
  • Cross-programme matching

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

  • One-time code sign-in, no school account needed
  • Apply, track status, accept or decline a seat
  • Isolated from every administrative endpoint

Planning your next admissions season?

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

Discover the possibilities of an integrated digital platform

Google PlayApple Store

© 2026 Mersys Campus