The ATS Formulas Behind Hiring Decisions
Six algorithmic scoring methods used across the industry, explained plainly — and where Expertini's own approach diverges.
Almost every ATS with any form of automated candidate ranking is running one (or a blend) of a handful of well-known scoring approaches under the hood, whatever marketing name a given vendor puts on it. This page describes six of the most common ones in plain terms — what each does, and where each tends to break — before explaining specifically how Expertini's own formula differs.
On this page
- 1. Keyword Density Formula
- 2. Semantic Vector Similarity
- 3. Knockout Binary Logic
- 4. Weighted Relevance Scoring
- 5. Recency & Duration Algorithms
- 6. Skill Match Ratio
- Where Expertini's approach diverges
- A fully worked example, from the published paper
- How this is architected in the platform
- Operational and audit posture
- Frequently asked questions
011. Keyword Density Formula
Counts how often specific terms from the job description appear in a CV, sometimes weighted by term frequency. It's the oldest and simplest approach, and its core weakness is well documented: it rewards a CV that happens to repeat the right nouns, regardless of whether the surrounding text describes real, relevant experience — and it penalises candidates who describe genuine experience in different words than the ones counted.
022. Semantic Vector Similarity
Converts both the CV and job description into numerical vector representations (embeddings) and measures how close those vectors sit in vector space — a mathematically more sophisticated cousin of keyword matching that captures some meaning-level similarity rather than exact string overlap. It's a real improvement over pure keyword density, but on its own it's still a single similarity number with no dimension-level breakdown of which specific requirements were actually met.
033. Knockout Binary Logic
A yes/no filter on hard requirements — a candidate either has a required certification, work authorization, or years-of-experience threshold, or they're removed from consideration entirely. This is useful for genuinely non-negotiable requirements, but implemented crudely it can silently eliminate strong candidates over a technicality (a certification described with slightly different wording, for instance) with no visibility into why they disappeared from the pipeline.
044. Weighted Relevance Scoring
Assigns different importance weights to different criteria (say, skills weighted higher than years of experience) and computes a blended score. This is a reasonable general approach — it's structurally similar to how Expertini's own CMS formula works — but the result is only as good as how the weights were set and how each individual criterion was actually measured underneath.
055. Recency & Duration Algorithms
Weights experience by how recent it was and how long a candidate held a given role, on the reasoning that a skill used three months ago is likely sharper than one used eight years ago, and a six-year tenure suggests something different than six one-year stints. Useful signal, but applied mechanically it can penalise legitimate career gaps (parental leave, further study, caregiving) that have nothing to do with actual skill currency.
066. Skill Match Ratio
A simple ratio: skills the candidate has, divided by skills the job requires. Easy to compute and easy to explain, but it treats every listed skill as equally important and purely binary (present or absent), with no way to represent that a candidate strongly evidences one skill and only briefly mentions another.
07Where Expertini's approach diverges
CMS — Candidate Match Score, detailed in full on its own page — is closest in spirit to weighted relevance scoring, but with three specific differences: the dimensions and their weights (JRIS) are derived fresh from each job description's own language rather than a generic fixed rubric (or, since July 2026, defined or approved explicitly by the hiring team — Manual and Hybrid CMS fix the dimensions and weights on the job itself, with the AI confined to reading CVs against them); each dimension's evidence score (CSS) comes from an AI extraction step reading for documented evidence rather than a keyword or vector-similarity proxy; and a dedicated hard-blocker rule handles genuinely mandatory requirements explicitly and visibly, rather than either silently knocking a candidate out or letting a weighted average quietly absorb a missing requirement. It's a combination of the better properties of several of these methods rather than a wholly separate category of technique.
08A fully worked example, from the published paper
The published CMS paper (Syed, 2026 — on Expertini Research at research.expertini.com) stress-tests the formula on a deliberately hard case: a senior engineer with nine-plus years of documented Python experience — strong on every technical dimension — applying to a classified national-security role that requires an active TS/SCI clearance he does not hold. His CV is written entirely in healthcare vocabulary (clinical systems, HIPAA, patient data), so it shares almost no literal words with the job description.
The extraction stage maps those healthcare-worded achievements onto the role's dimensions and scores each one. Python development: evidence score 100 against an importance weight of 100. Education and experience: 100 against 90. High-scale data and analytics: 95 against 85. Architecture and object-oriented design: 90 against 80. Version control: 90 against 50. Agile ceremonies: 60 against 60. And the mandatory clearance: evidence 0 against the maximum weight of 100. The weighted sum comes to 42,375 over a weight total of 565 — a CMS of 74.96.
Per-dimension JRIS and CSS profile for the paper's worked case study — the missing mandatory clearance is pinned to evidence 0 at the maximum weight, and the weighted result lands at 74.96 (Syed, 2026, Fig. 3)
Every alternative approach gets this candidate wrong in a different direction. A keyword formula scores him around 30–40 percent — near-zero vocabulary overlap with the job description — and rejects him before any human sees the profile. An unconstrained LLM asked for a single score tends to be captivated by his metrics and can score him above 90, glossing over the legal barrier entirely. The weighted formula with an explicit hard-blocker lands him at roughly 75: clearly a strong engineer, clearly flagged on the one dimension that actually blocks immediate placement, and correctly positioned for talent-pipeline consideration rather than either bin. Every number in this example can be recomputed by hand from the two tables in the paper — which is the entire point of a published, deterministic formula.
The same candidate under three scoring architectures — roughly 32 percent from keyword matching, 92 from an unconstrained LLM, 75 from the hybrid framework: the only score that both clears the review threshold and flags the real blocker (Syed, 2026, Fig. 2)
Both figures come straight from the paper, which you can download in full as a PDF — every number in this example is in its tables.
Platform architecture & operations
A1How this is architected in the platform
The ATS Formulas Behind Hiring Decisions is not a bundle of point products — it is a slice through one platform. The platform is deliberately server-rendered: every view is prepared by the application server and shipped as complete HTML, with no client-side framework, no third-party CDN scripts, and no build pipeline between the data and the page. What renders is what the server computed — the property that makes the interface auditable.
All persistence runs on a single search-native document store; every query carries the organisation's identifier as a mandatory filter at the lowest query layer. Tenant isolation is therefore structural — a property of how every request is composed — rather than a policy that relies on application code remembering to check.
Every capability referenced on this page resolves to a registered tool or connector: the tools directory and the integrations catalogue are renderings of the same registries the application enforces at runtime, so what this page describes and what the product gates can never drift apart.
A2Operational and audit posture
Screening is deterministic and published — the same inputs produce the same outputs, hard requirements block rather than average away, and the methodology is public on the research page. Actions that touch external systems are explicit and journalled per event; usage reporting aggregates the same journals the actions write, not a parallel telemetry system.
Anything that leaves the request path — notification fan-out, webhook delivery, activity journalling, mail — runs in fire-and-forget background threads. A slow external endpoint can never make the interface hang, and a failed side effect is logged rather than silently retried into inconsistency.
Everything written is yours to take: CSV exports and the Data Export app cover the same stores the product itself reads. The exit is as open as the entrance — by design, not concession.
Frequently asked questions
Does every ATS use the same scoring formula?⌄
Is semantic vector similarity the same as Expertini's CMS?⌄
Why do knockout filters sometimes reject good candidates?⌄
Is a more complex formula always better?⌄
At a glance
- Six common industry approaches described in plain terms
- Each has a well-documented failure mode, not just a strength
- CMS combines weighted scoring with fresh per-job dimensions
- Hard blockers are flagged explicitly, never a silent knockout
- Dimension-level cited evidence, not a single opaque similarity number
See the ats formulas behind hiring decisions on your own hiring.
Bring a real job description to a 30-minute demo — free trial included.
Book a demo