A frozen snapshot of the candidate goes in at the top, a shortlist comes out at the bottom, and every job that falls out along the way is accounted for.
The thing to notice: nothing slow happens at match time. I compute the job vectors long before, at ingest, and the candidate's own vector is one short call over the already-extracted profile - so a run mostly just compares numbers, and only the top 50 jobs ever get the full scoring pass. The corpus itself is real: 141,897 English postings from the Djinni recruitment platform, fetched through the Hugging Face API, and the build script verifies the MIT licence against the live dataset card before a single row is ingested. Ten hand-authored trap jobs sit alongside them, honestly tagged as synthetic, so the demo can show the system rejecting things for good reasons.
Inside the matching engine · 2 of 3
Where the vectors come from.
The dotted boxes from the first slide, zoomed in - two pipelines, one embedding model at the end of both. That shared model is the whole trick: it's what makes a job and a candidate comparable at all.
Why the convergence matters: both pipelines end at the same model, so a job and a candidate land in the same 384-dimension space - and that's the only reason the distance between them means anything. Notice too that the candidate's vector is built from titles and canonical skills only, so a name, a school or a postcode can never drag a match around - fairness by construction, not by filter. Extraction uses the LLM when a key is present and falls back to heuristics when not, and both record an evidence span for every claim they make.
Inside the matching engine · 3 of 3
How we know it works.
Three layers of proof, and each answers a different question. Tests ask whether the code does what we claim. Evals ask whether the matching is actually any good. And the runtime record answers the question the other two can't: what actually happened on this run, for this candidate.
The layer worth dwelling on is the third, because it's the one users touch. Tests and evals run before anything ships - and the eval layer earned its keep immediately, catching four real defects on its first run, including a sponsorship trap that never triggered and a seniority score that compared bands across unrelated careers. But the runtime record is a product feature: TraceEvent means any candidate can ask why any job is or isn't in their list and get the actual decision path, SourceDocument means a bad extraction can be replayed from the original bytes, OutcomeEvent collects the training labels the V2 ranker will need, and LlmCache is what makes a repeated run deterministic. The dashed boxes are the only disposable part - and even there, a tested redaction formatter means a CV can never leak into a log line.