Depending on the features selected by a consortium for its match, the following options may be available to students and sites:
Suppose both halves of a couple are each considering matches in two or more distant cities. It may be more important to them that they be matched nearby to each other, or they may want to bend that preference for certain sites, but not others. Couples’ matching gives them full control over that process.
Instead of ranking individual tracks, couples will rank pairs of sites; instead of each ranking perhaps 10 tracks, they might rank 100 permutations of their 10 individual options. But they will match only if both halves of the pair match successfully. If one partner fits, but the other does not, we move to their next paired preference. If one partner is bumped by a student preferred by that site, the other student is bumped too. Essentially, couples matching lets each member of the couple to selectively decline opportunities if the match would be undesirable based on their partner’s result.
Suppose a site has two tracks. While they might prefer three students in each track, it may be acceptable to have two in one track and four in the other. After the initial match is complete, if unfilled slots remain in a track, reversion directs the matching algorithm to move them to another track. At this point our algorithm allows any student who prefers a match to the newly reverted slot to “trade up,” or an unmatched student to claim it. Reversion settings can allow reverted slots to go to multiple tracks, or limit the number of slot that revert, but it all has to be set (effectively pre-programmed) by the site before the matching window closes in our user interface.
Suppose a program wants to avoid filling a track entirely from one school. They do this by enabling a school limit, and setting the maximum number of students from any one school that are permitted to match to this track. If there are three slots, the school limit is set to two, and two students from a given school are tentatively matched to the slot, another student from that school can only match by bumping one of their colleagues. The algorithm will prefer leaving the last slot vacant to adding a third student from that school. School limits are set per track, and cannot favor one university over another.
Sublists allow a site to subdivide their preferences for a given track between two lists, without creating a separate track. Suppose a site requires at least one student fluent in sign language, within a track that has three slots. While they would be happy to have two or three signers, they need at least one. To meet this need, the site could create a sublist with one slot for all signing candidates, and a sublist with two slots for all acceptable candidates. The highest available signing candidate would match to the first sublist, while the other two matches would come from the full list of acceptable candidates. Note that the ordering of the two sublists might be quite different — the best signing candidate (sublist 1) might be less preferable in general (sublist 2), but necessary for their deaf clients. The site might or might not allow an unfilled sublist 1 slot to revert to sublist 2… it’s customizable, and up to them.