Talent Matching
What changes for a recruiter's day-to-day work when matching is evidence-based.
Talent matching is the practical, day-to-day face of the Candidate Match Score — this page focuses on what changes for a recruiter's actual workflow when matching moves from keyword filtering to evidence-based scoring, rather than the formula's internal mechanics (covered in depth on the dedicated CMS page).
The short version: keyword matching filters out qualified people for using different words than the ones a recruiter guessed to search for, and it lets through unqualified people who happened to pad a resume with the right nouns. Evidence-based matching does neither, because it reads for meaning rather than string overlap.
On this page
01The keyword-matching problem in practice
A Boolean search for "project manager" AND "Agile" AND "Scrum" will silently exclude a candidate who wrote "led sprint planning and delivery for a cross-functional product team" — genuinely describing the same experience in different words, which happens constantly with candidates from non-traditional backgrounds, career changers, and non-native English speakers translating their experience into a second language. The keyword filter has no way to know these are the same thing; it can only match strings.
The failure runs in both directions. A candidate who lists "Agile," "Scrum," and "stakeholder management" in a skills section without ever describing what they actually did with those methodologies will pass the same filter a genuinely experienced candidate might fail. Keyword matching optimises for resume vocabulary, not job-relevant evidence — the two frequently diverge.
02What changes with dimension-based matching
Expertini extracts competency dimensions directly from each job description — not a generic template, the specific requirements of that specific posting — and evaluates a CV against each dimension for documented evidence, regardless of the exact words used. "Reduced page load time by 40% through backend query optimisation" and "improved application performance through database tuning" score similarly against a dimension like "performance optimisation experience," because both describe the same underlying evidence.
In practice this means a recruiter's shortlist changes shape. Fewer strong candidates get filtered out for vocabulary mismatch; fewer weak candidates get through purely on keyword density. The shortlist that results tends to be smaller and stronger, not just differently ordered.
03Where this matters most
The gap between keyword and evidence-based matching widens with three specific candidate populations: people transitioning between industries (whose relevant experience is described in a different industry's vocabulary entirely), candidates writing in a second language, and candidates from educational or professional backgrounds that don't map onto a recruiter's mental template for "what this role's resume looks like." None of these groups are less qualified on average — they're simply less legible to a keyword filter, which is a property of the filter, not the candidate.
04How this connects to the underlying score
Talent matching and the Candidate Match Score are the same mechanism described from two angles: this page from the recruiter's outcome, the CMS page from the formula's internals. Every matching decision Expertini makes is backed by the same dimension-level evidence and the same deterministic arithmetic — nothing described here happens "automatically" in some separate, less-explainable layer.
05A concrete before-and-after
Consider a job description requiring "experience leading data migration projects." A keyword filter searching for "data migration" and "project lead" would miss a candidate whose CV says "oversaw the transition of a legacy customer database to a new CRM platform across three regional offices" — genuinely the same experience, described operationally rather than in the exact phrase a recruiter guessed to search. Dimension-based matching reads the second phrase as strong evidence for the same underlying competency, because it evaluates what was actually done rather than whether specific words appear.
This pattern repeats across industries with different specifics: a healthcare candidate describing "coordinated post-operative care across a 12-bed unit" against a JD asking for "patient management experience," or a finance candidate writing "built variance models flagging forecasting drift" against a requirement for "financial modelling skills." In each case the vocabulary gap is real and the underlying evidence gap is not — which is precisely the distinction keyword matching cannot make and evidence-based matching is built to make.
Platform architecture & operations
A1How this is architected in the platform
Talent Matching 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
How is talent matching different from keyword search?⌄
Does talent matching replace the need to write a good job description?⌄
Can talent matching help with career-changer or non-traditional candidates?⌄
At a glance
- JD-derived dimensions per job, never a generic template
- Linguistic criticality weighting from your own JD wording
- Evidence-cited rationale on every dimension
- Tier bands from Exceptional to Low
- Evidence-bounded scores — style can't add points
- Fair to career-changers and second-language candidates
See talent matching on your own hiring.
Bring a real job description to a 30-minute demo — free trial included.
Book a demo