The ranking is stable
Identical order tomorrow. No model drift, no temperature. If the ranking changed, something real changed and you can find out what.
CheckedIn · the score receipt
Ask why she scored 71. Get the arithmetic, not a paragraph.
Most tools give you a number and a generated paragraph. The paragraph is produced separately from the number, so the two can quietly disagree. Here the explanation is that same arithmetic written out, so they cannot.
71 Good fit
| Requirement | Necessity | Weight | Coverage | Matched via, and the evidence | Recency | Contribution |
|---|---|---|---|---|---|---|
| React, 5+ years | must-have | 18 | 100% | exact matchReact named in 3 of 4 roles, most recent 2026 | current | +18.0 |
| PostgreSQL | should-have | 10 | 95% | known aliasCV says “Postgres”, catalogue maps it to PostgreSQL | current | +9.5 |
| TypeScript | should-have | 10 | 80% | close enough“ES6 / modern JavaScript”, no TypeScript named | 2 years | +8.0 |
| Kubernetes | should-have | 8 | 0% | no evidenceNothing in the CV supports this | — | 0.0 |
| Team leadership | nice-have | 6 | 60% | close enough“mentored two juniors”, no formal reporting line | current | +3.6 |
| AWS | nice-have | 5 | 80% | known alias“EC2, S3, Lambda” named individually | 4 years | +4.0 |
fit = the sum of the contributions, divided by the sum of the weights, times 100.
That is the whole formula. Strengths, gaps and risks are read straight off these rows, so
the summary at the top can never contradict the table underneath it.
Illustrative ledger for one role. Columns, behaviour and the formula match the product.
The column people actually use
“Matched via” is the difference between a score and an argument.
When a score looks wrong, this column usually explains it in a glance. Four ways a requirement can be met, each worth a different amount.
◆
Not “they listed Postgres”
But “they listed Postgres, the role asked for PostgreSQL, and those are a known alias”. One of those you can take to a hiring manager.
◆
Recency is priced in on purpose
Five-year-old React counts for less than current React. If a strong candidate scores low, this is often why.
The evidence ladder
1.00
Measured
An assessment they actually sat. This replaces the claim.
0.95
Exact match
The skill is named, as the role named it.
0.80
Known alias
Postgres for PostgreSQL. The catalogue knows they are the same.
0.60
Close enough
Similar, but a judgement rather than a fact.
0
No evidence
Nothing in the CV supports it. Not a penalty, just a zero.
Fig 1
A measured result sits at the top of the same scale everything else is scored on. That is
why measuring changes the ranking instead of decorating the profile.
Zoom out
Seven factors, and the ones that did not apply drop out.
A factor the role never stated is removed from both sides of the division, never quietly scored zero.
FactorWeightMatchStateWhy
Skills 40% 72% Strong 8 requirements, 6 covered
Experience 20% 100% Strong 7 years against a 5-plus band
Notice period 12% 55% Gap 60 days, role wants 30
Location 10% 100% Strong Pune, role is Pune hybrid
Salary 10% 80% Strong ECTC ₹22 lakh against a ₹18 to 24 band
Education 8% 100% Strong B.E. Computer Science
Employment type — — Not evaluated Candidate never answered
Read this twice
“Not evaluated” is not zero. It means the factor could not be assessed, so it renormalised out of the calculation entirely. The header tells you how many were scored, and a candidate is never punished for a question the role never asked.
What arithmetic buys you
Three properties you only get if no model is grading each CV.
Fixing the JD is free
Correct a wrong seniority and every candidate re-scores at no cost. In a tool that grades each CV with a model call, that fix means paying to re-grade the whole database. Which is why nobody ever fixes the typo.
Tuning becomes something you do
Change a weight and the whole database re-ranks, also for nothing. So tuning stops being something you avoid because of the bill.
When it says something is wrong
Four flags, and what each one is telling you.
FlagWhat it meansWhat to do
Insufficient evidenceToo little to score honestly: no core skills or experience factor, or fewer than three applicable factors.Treat the score as provisional. Usually a thin or scanned CV.
Must-cap appliedA must-have was not met, so the total is capped.The candidate is missing something the role called a dealbreaker. The fit is still shown rather than hidden.
Knocked outA hard gate rejected them outright.Check the knockout reason, which names the gate. A knockout raises a review task, so nobody disappears silently.
Requirement kind unscoredA requirement was extracted but is not a scoreable dimension.Informational. It still shows in the ledger.
Where the AI actually is, and where it is not.
Worth being precise, because “AI-powered matching” is the phrase everyone uses for something else.
AI reads. Once.
A JD becomes a weighted requirement spec; a CV becomes a structured profile. A human approves the requirements before the role goes live. An unreadable JD creates nothing and raises a task, rather than a half-built role scoring everyone against an empty spec.
Arithmetic scores. Every time.
No model call, no clock, no randomness. That is the reason the three properties above are true. Nothing is auto-rejected except by screening questions you wrote, and a knockout raises a review task rather than making someone disappear.
Try to break it
Send a JD and three CVs. Tell us which score is wrong.
That is a better demo than a slide deck, because the receipt lets you point at the exact row you disagree with. Most of the time it is a should-have that somebody marked must-have.