Candidate Match Score (CMS)
The formula, the inputs, and the arithmetic — shown in full, not summarised.
÷ Σ(JRIS)
The Candidate Match Score is Expertini's deterministic scoring formula, published in full as an academic paper (Syed, 2026, "From Stochastic to Deterministic: A Multi-Criteria Decision Analysis Framework for Bounded Semantic Parsing in AI-Driven Recruitment Screening") and implemented as ordinary, auditable code inside the product. This page explains the formula itself, in enough detail that you could reimplement it independently and get the same numbers — which is the entire point of publishing it.
CMS is not a brand name for "our AI is good." It's a specific weighted-sum calculation, described below, that takes structured input from an AI extraction step and produces a single score between 0 and 100 through arithmetic a human can check by hand.
On this page
01The formula
CMS = Σ(CSSᵢ × JRISᵢ) / Σ(JRISᵢ), summed across every competency dimension i identified for a given job. CSS (Candidate Skill Score, 0–100) measures how strongly the anonymised CV evidences a given dimension. JRIS (Job Requirement Importance Score, 0–100) measures how critical the employer said that dimension was, derived directly from the language in the job posting: phrases like "must have" or "required" map to a JRIS of 90–100, "preferred" maps to 50–70, and "a plus" or "nice to have" maps to 30–50.
Because both CSS and JRIS sit on a 0–100 scale, the weighted average naturally lands in the same 0–100 range without needing an extra normalisation step — a detail that matters because an earlier, uncorrected version of a similar formula in one of our internal drafts inflated scores by a factor of 100 before the ×100 term was identified and removed. We mention this not to bury a mistake but because it's a useful illustration: a formula this simple is still worth checking arithmetically, which is exactly what publishing it in full allows anyone to do.
02Where the dimensions come from
CMS does not use a fixed, generic rubric applied to every job. For each posting, the extraction step identifies between five and nine competency dimensions directly from that job's specific description — a senior nurse posting and a senior backend engineer posting will produce almost entirely different dimension sets, weighted according to the specific language the employer used. This is a deliberate design choice: a fixed rubric either misses what actually matters for a given role, or forces every job description into an unnatural template to fit the scoring system, which defeats the purpose of writing a real job description in the first place.
03Hard blockers: where the formula refuses to average away a missing requirement
A pure weighted average has one well-known flaw: a candidate can compensate for a completely missing mandatory requirement with strength elsewhere. CMS closes this specific gap with a hard-blocker rule — any dimension the job description marks as strictly mandatory, for which the CV shows zero evidence, is pinned to CSS = 0 and flagged separately in the output, regardless of how the rest of the weighted average computes. A candidate can still receive a numeric score above the hard blocker (the arithmetic doesn't hide it), but the audit report makes the blocker impossible to miss, and most hiring teams configure their pipeline to treat a flagged hard blocker as an automatic filter rather than a mere data point.
04A worked example
Take a role with four dimensions: "Python & distributed systems" (JRIS 95, "required"), "cloud architecture" (JRIS 85, "required"), "team leadership" (JRIS 65, "preferred"), and "open-source contributions" (JRIS 40, "a plus"). A candidate whose CV strongly evidences the first two (CSS 98 and 95) but shows no leadership experience at all and no public open-source work (CSS 0 and 0) computes as: (98×95 + 95×85 + 0×65 + 0×40) / (95+85+65+40) = (9310+8075+0+0)/285 = 61.0. Because "team leadership" was marked preferred rather than required, this isn't a hard blocker — it's simply a mid-range score reflecting genuinely partial fit, which is exactly what the raw evidence supports.
The published paper works a harder case the same way — a strong engineer blocked by one missing mandatory requirement — and shows every dimension's weight and evidence score side by side:
Per-dimension JRIS and CSS breakdown from the paper's worked case study: six strong dimensions and one mandatory requirement at evidence 0, computing to 74.96 (Syed, 2026, Fig. 3)
The full paper is available to download as a PDF, and also published on Expertini Research at research.expertini.com.
05What CMS is not
CMS does not predict job performance, and we don't claim it does — no scoring system, human or automated, has a strong enough track record to justify that claim, and anyone telling you otherwise about their own product should be treated with scepticism. It measures documented evidence of stated requirements, nothing more. It is explicitly designed as decision support that narrows a pool for human judgement and structured interviews, not a replacement for either. And it inherits any bias present in the job description itself — if a JD's requirements are written in a way that unnecessarily excludes qualified candidates, CMS will faithfully score against those requirements rather than correct for them.
Platform architecture & operations
A1How this is architected in the platform
Candidate Match Score (CMS) 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
What does CMS stand for?⌄
Is the CMS formula public?⌄
Can two recruiters get different CMS scores for the same candidate?⌄
What happens if a candidate is missing a required skill?⌄
Does a high CMS score guarantee a good hire?⌄
At a glance
- Published formula: CMS = Σ(CSS×JRIS)/Σ(JRIS)
- Dimensions per job: AI-derived, or recruiter-defined via Manual/Hybrid CMS — never a generic rubric
- Hard-blocker rule for missing mandatory requirements
- Scores bounded 0–100 by construction — no inflation factor
- Fully reproducible by hand from the audit report
- Peer-reviewable academic methodology
See candidate match score (cms) on your own hiring.
Bring a real job description to a 30-minute demo — free trial included.
Book a demo