How Meritline ranks

Everything below happens in your browser. No part of it runs on a server.

1. Extract. Text is pulled out of each PDF, DOCX or TXT file locally (pdf.js and mammoth).
2. Gate. A fixed keyword-and-structure heuristic decides whether the file looks like a CV. Files it rejects are shown to you with the reason — never silently dropped.
3. Embed. The job description and each CV are turned into 384-dimension vectors by all-MiniLM-L6-v2, an INT8-quantised ONNX model that runs on WASM in a Web Worker. The first run downloads the model (~23 MB) from this site — self-hosted and SHA-256-verified before use — and caches it in your browser.
4. Score. Cosine similarity between the job-description vector and each CV vector. That single number is the match index.
5. Rank. Sorted by similarity at full precision, ties broken by filename using a fixed byte-order comparison.

Alongside the score, a static dictionary of skill terms is matched against the job description and each CV to show which required skills appear. That matching is a display aid — it does not change the score.

There is no language-model call, no sampling, no temperature, and no randomness anywhere in the score path. Given the same job description, the same CV text and the same model, the pipeline produces the same number.

The honest limits of that claim:

• The model is pinned by name, not yet by file hash. We do not currently verify that the weights the CDN served are the weights we expect. Hash-pinning is planned.
• Text extraction depends on the PDF library version. A different version can extract slightly different text from the same PDF, which would change the score.
• INT8 inference on WASM is deterministic on a given build, but we have not yet published a cross-browser reproduction test. Until we have, treat "identical on any machine" as untested rather than proven.

The score_id is sha256(sha256(jd) + sha256(cv) + model id + rubric). Two runs over the same inputs produce the same id, so you can tell whether a number came from the inputs you think it did.

The match index orders candidates against this job description. It is not a percentage, a probability, or a prediction that someone will be hired.

Cosine similarity is one holistic number. It is not broken into sub-scores because there are no sub-scores to show — anything presented as a component breakdown of this number would be manufactured. The matched and missing skill lists are separate, honestly-derived information.

Read this if you are assessing bias exposure. By default the model embeds the CV text as extracted, in full. That includes the candidate's name, email address, phone number and anything else printed on the CV, and the score can therefore be influenced by it.

Blind screening — an optional toggle on the New run screen — redacts names, emails, phone numbers and links from each CV before the text reaches the model. It is best-effort direct-identifier removal, not a fairness guarantee: proxies and inferable signals remain, so the adverse-impact monitor still measures outcomes after the fact. When blind screening is off, the full CV including personal details is scored.

CV contents are scored on your device and are never uploaded.

Signing in sends your Google identity. Recording a decision sends a score id and the action — never CV text, names, or filenames.

In full, the network requests a ranking run makes are: the one-time model and runtime download from this site (self-hosted and hash-verified — see verify), Google sign-in, a session check, and — when you shortlist or reject someone — a small message containing a score id and the action name. CV text, candidate names and filenames are not in any of them.

Scores and decisions are recorded in this browser only. They are reproducible from the same inputs, but they are not yet signed by a server, so they cannot prove to a third party when they were made.

Concretely: a receipt today proves reproducibility (re-run the inputs, get the same id) but not custody (nothing independent attests to when the run happened or that the result was not edited afterwards). Server-signed receipts are the next piece of work.

Meritline records the actions you take — open · shortlist · reject — so the run has a decision history. They are never fed back into the ranking. There is no auto-reject and no path where the software decides.

There is deliberately no "advance" action. Moving a candidate through stages is what an applicant tracking system does, and Meritline hands off to yours rather than competing with it. Runs recorded before this was removed may still show an advance in their history.

On a 252-CV benchmark across 7 job descriptions, Recall@20 is 0.807 (95% CI 0.714–0.850), Spearman rho is 0.708 (0.650–0.747) and Precision@5 is 0.257 (0.143–0.486). That rho fails the 0.900 floor we set ourselves, and we have not moved the floor. The reference ranking is constructed by the corpus generator rather than written by people, so it measures agreement with a specification, not with hiring judgement. That is why results are grouped into bands rather than presented as an exact order.

What that benchmark cannot tell you:

• The reference ranking is constructed, not human. Every CV is generated from stated attributes, and the “right” order is those attributes scored by the generator’s own weights. So the number measures agreement with a specification, and it is circular in a way human annotation would break. Kendall’s W — the statistic that would tell you whether people even agree with each other about this — is pending human annotation, and we report it as pending rather than inventing one.
• It scores text that is already extracted, so it measures the ranker, not the PDF and DOCX extraction in front of it.
• It runs on onnxruntime-node, not the WASM runtime your browser uses, and the CVs are synthetic prose rather than real writing.

The other figure quoted about Meritline is a Spearman rank correlation of 0.9286 against a hand-written ranking of 21 CVs. That is a determinism fixture, not an accuracy result: it is what we re-run to prove that blocking every external origin changes nothing about the output. Read as accuracy it flatters us by a wide margin, because the CVs are synthetic, the hand ranking was written by the same person who designed them, and 21 candidates on one role is a sample small enough that a single position moves the score. The 252-CV corpus above is harder, larger and more representative, which is why it — and not 0.9286 — is the number we stand behind.

The model these numbers describe is all-MiniLM-L6-v2, pinned and hash-verified — see verify for the hashes and the reproduction evidence.