EduMatch — matching you can inspect and argue with.
A transparent tutor-matching engine scored on relevance, constraint safety, explainability, fairness, and stability — every recommendation states exactly why it appears, and you can move the weights yourself. This benchmark isolates and tests the ranking method; the live product built around it runs at edumatch.asafarim.com.
benchmarks/edumatch.Where the real product stands today
EduMatch is a live app (edumatch.asafarim.com), not just this benchmark. It ships a full conversational "Learning Brief" flow — intake, immediate help, up-to-5 tutor matching, prepared proposals, booking, and progress tracking — built on Auth.js accounts and a real Postgres schema. It currently runs in showcase mode: profiles are synthetic and checkout is a $0 mock, so nothing here is a paying marketplace yet. Guardian approval for minors and full localisation beyond English/Dutch are not built. The production matching engine (apps/edumatch/lib/server/brief-matching.ts) has since diverged from the simplified weights this benchmark demonstrates — see Method below.
How the reference run scored
Five benchmark dimensions
Do the top recommendations agree with a labeled ground truth?
Share of student needs whose full ranked order exactly matches the hand-reviewed label in fixtures/labels.json.
Does every recommendation actually meet the student's hard requirements?
Share of ranked results that satisfy every hard constraint (subject, level, language, availability, mode/distance) — measured across every need, not assumed.
Does every recommendation state exactly why it appears?
Share of ranked results whose per-factor contributions sum exactly to the displayed composite score.
Do two equally-qualified tutors score identically regardless of an unrelated tag?
Maximum composite-score difference between the constraint-identical twin tutors (T-01/T-04) across every need where both are eligible. 0 means the engine is blind to the only attribute that differs between them (cohort tag).
Does adding an unrelated candidate leave the existing order unchanged?
Whether adding an unrelated, constraint-failing tutor to the candidate pool leaves the existing ranking order unchanged.
Why the ranking is trustworthy
The engine is pure: no database, no clock, no randomness. Every distance is Haversine over fixed synthetic coordinates, and rating is Bayesian-damped toward a neutral prior so a handful of five-star reviews cannot outrank a long, consistently strong track record.
Default weights here (distance 30% · subject 25% · level 15% · rating 20% · verification 10%) are a starting point, not a fixed policy — the Match Explorer lets you move them and re-rank live, using this exact engine. They are illustrative, not what production runs: the live app's matching engine now scores eight factors (subject 24% · level 16% · language 14% · schedule 12% · rating 12% · mode 10% · responsiveness 6% · proximity 6%) and treats verification as a hard eligibility filter rather than a weighted score.
The engine models qualification and logistics only: subject, level, language, availability, mode/distance, rating, and verification. It has no field for age, gender, ethnicity, disability, religion, or any other protected attribute — there is nothing to weight, by construction, not by a filter bolted on afterward.
Limitations
- Ground truth (fixtures/labels.json) is hand-reviewed against a small, hand-authored fixture set — it demonstrates the method, not statistical significance at scale.
- Fairness here means "blind to an attribute the engine was never given" (the cohort tag). It does not certify fairness across attributes a production system might inadvertently correlate with — that requires real-world data audits this benchmark cannot provide.
- Latency figures are representative reference timings from a fixed run, not live measurements — the engine itself runs in low single-digit milliseconds against this fixture size.