How the matching works · Medical Trainee Matching

What "stable" means

The result is a stable matching. Stability has a precise meaning: there is no blocking pair: no trainee and institution who would both rather be matched to each other than to what they actually received.

Concretely, a trainee–institution pair would "block" the result if the trainee prefers that institution to their assigned placement, and the institution either has a spare post or prefers that trainee to someone it was given. If no such pair exists anywhere, the matching is stable. Stability is the accepted fairness standard for this kind of allocation: no one is left with a justified grievance that a place they wanted was given to someone the institution ranked lower.

The algorithm

The engine uses deferred acceptance (Gale–Shapley with quotas), the same family of method used by national medical residency matches such as the US NRMP. Trainees "propose" to institutions in their order of preference; an institution provisionally holds the best applicants it has seen up to its number of posts and releases the rest, who then propose to their next choice. The process repeats until no one has a better move. Because trainees do the proposing, the result is trainee-optimal: of all the stable matchings that exist, it is the one the trainees collectively prefer.

Two properties matter for trust. The algorithm is deterministic and order-independent: the same files always produce the same result, regardless of row order or which institution is processed first. And for the proposing side it is strategy-proof: a trainee can never do better by misreporting their true preferences, so the honest list is always the best list to submit. There are no knobs a human can turn to favour one party over another.

Independent verification

Stability isn't taken on faith. After every match, a separate checker, written independently of the matching engine, scans the result for blocking pairs. It acts as a correctness oracle: the matcher proposes an answer, and the checker, which shares no logic with it, confirms that answer is stable before it is returned. A result is only ever surfaced if it passes.

Because the method is deterministic, this also means an outcome is fully reproducible: given the same two files, anyone running the same process arrives at the same matching.

The audit report

Each run can produce a downloadable audit report containing:

a unique fingerprint (SHA-256 checksum) of the exact input files used, so the inputs behind a result can't be quietly swapped;
the blocking-pair count from the independent checker (zero for a valid result);
enough metadata to re-run and confirm the outcome from the same inputs.

Priority group matching

Some intakes need certain trainees placed before others are considered, for example trainees already on a programme ahead of new applicants. In priority group mode, the engine runs once per group in strict order: a group is fully matched against the posts still available before the next group is considered. Institutions can cap how many trainees they take from a given priority group, subject to a configurable limit (50% of a multi-post institution's posts by default) that stops any one group monopolising capacity.

Here fairness is defined within each group: every group's result is stable against the posts that group was entitled to. A pair that spans two groups (an institution that would rather have an unmatched higher-priority trainee than one it already holds) is not treated as a violation, because the priority rules deliberately forbid that placement. The independent checker enforces this group-wise definition and confirms no institution exceeded its caps.

No conflict of interest

The college collects preferences; the matching is run by a neutral third party with no stake in the outcome. Neither side can influence an individual placement: the algorithm decides, and the independent stability check proves it. This separation mirrors the principle behind national residency programmes.

How your data is handled

Input files are processed in memory only to compute the match and are never stored. The service runs in a single, access-controlled location, and the tool itself is login-protected per organisation. In the default mode nothing is retained once the match completes; an opt-in History mode stores the results for your organisation's own future reference, scoped so no organisation can see another's. Input files are never stored.