Explainable candidate scoring: why a fit score needs written reasons

Why a fit score on its own is not enough

A bare score hides everything a reviewer needs to know. A candidate shown as 64 might have missed one essential requirement and excelled at the rest, or met every requirement weakly, or had half their CV lost in a bad PDF extraction. The number looks the same in all three cases, and the right action is different in each.

Unexplained scores also fail the people around the decision. A hiring manager who disagrees with a ranking has nothing to argue with. An HR lead asked why a candidate was not shortlisted cannot answer. And an internal or external review of the process has no record of what the system actually considered.

There is a behavioural problem too. When reviewers cannot see reasons, they tend to fall into one of two habits: trusting the number completely, or ignoring the tool and reading every CV again. Both waste the effort of building it. Written reasons give reviewers a third option: read the explanation, check the evidence, and agree or override in seconds.

What an explainable candidate score contains

An explainable score is a small structured report, not a single number. A well-designed one contains:

• An overall score for ordering the list, on a fixed scale such as 0 to 100.
• A verdict per requirement: met, partly met, not met, or no evidence found. The last two are different: 'not met' means the CV shows something that falls short; 'no evidence' means the CV is silent and the question may need to be asked at interview.
• Evidence for each verdict: a short quotation or reference to the part of the CV the verdict relies on, such as the role, employer and dates.
• A written summary of the candidate against the role in a few plain sentences.
• Flags for anything that lowers confidence: unreadable sections, unclear dates, a requirement the model could not assess.
• Provenance: which version of the role definition and which model produced the result, so the score can be reproduced or explained later.

HireDash, the AI résumé-screening product FLUIDS designed and built, covers the core of this structure. Each candidate is shown with a fit score from 0 to 100, a written summary and a requirement-level breakdown, and custom extraction questions can add consistent answers, such as a yes/no, a number, a category or a short summary, across every candidate for the role. The other elements in the list are design recommendations for any screening tool, not a description of HireDash.

How must-have and nice-to-have requirements should affect a score

Must-have requirements should behave differently from nice-to-haves, because a candidate who lacks a licence the job legally needs is not a slightly weaker candidate. There are three common ways to combine them, and the choice should be made deliberately by the hiring team, not left to a model's judgement.

Whichever approach you pick, show it on screen. A reviewer looking at a candidate should be able to see that the score is lower because a must-have is unconfirmed, not because of a long list of minor gaps. HireDash lets the hiring team set requirements and scoring priorities when defining the role, which is where this decision belongs.

Be careful with hard gates on 'no evidence'. If a CV simply does not mention a requirement, the honest verdict is 'no evidence', and many teams prefer to keep such candidates visible with a flag rather than exclude them automatically.

Why every reason should point to evidence in the CV

A written reason is only trustworthy if it can be traced to the CV. Language models write fluent explanations, and a fluent explanation can describe experience the candidate never claimed. Requiring evidence turns a persuasive paragraph into a checkable statement.

1. Ask for the evidence with the verdict. The model returns, for each requirement, the verdict and the exact words from the extracted CV text that support it.
2. Verify the quotation in software. Before display, the system checks that the quoted text really appears in the extracted CV. A quotation that does not match is a warning sign that the reason may be invented.
3. Show the evidence next to the reason. The reviewer sees the claim and its source together and does not need to search the PDF.
4. Let reviewers mark a reason as wrong. Corrections become examples for testing the next version of the prompt or model.

The same discipline applies to other AI features that work from a source document. An AI exam generator should tie each question to the course material it came from, and a Quran app's AI should stay tied to a named tafsir, as covered in our guide to AI guardrails in Islamic apps. In each case the rule is the same: retrieve the source first, then generate, and keep the source visible.

How to calibrate candidate scores

Calibration means checking that scores line up with how experienced reviewers judge the same candidates, and that they stay stable. It is the difference between a number that orders a list sensibly and a number that only looks precise.

• Compare with blind human review. Take a sample of CVs for a role, have two experienced reviewers grade them against the same requirements without seeing the scores, and compare. Large disagreements point to unclear requirements or weak extraction.
• Test consistency. Score the same CV more than once. Language models can vary between runs; if the score swings noticeably, display bands such as strong, possible and weak rather than precise numbers, and tighten the instructions.
• Re-test after every change. A new model version, an edited prompt or a reworded requirement can shift every score. Keep a fixed test set and re-run it before releasing changes.
• Do not compare across roles. A score is relative to one role definition. A 70 for a junior accountant and a 70 for a project manager say nothing about each other.

Calibration also tells you where to set review thresholds. If blind reviewers routinely shortlist candidates the tool ranks in the middle, the cut-off is too high or a requirement is mis-weighted. Fix the role definition first; it is usually the cause.

What a candidate fit score does not mean

A fit score summarises how a CV compares with a written role definition. It is worth being explicit, inside the product and in team training, about what it is not:

• Not a prediction of job performance. A CV describes claims about the past; it says little about how someone will work in your team.
• Not an accuracy figure. In HireDash, the 0 to 100 score is a product field for ordering review, not a measured accuracy statistic.
• Not a judgement of the person. It measures the match between one document and one role definition, both written by people and both imperfect.
• Not a reason on its own to reject. Scores and generated explanations are decision support; the hiring team checks the evidence and decides who progresses.

Saying this clearly protects candidates and the company. It also shapes how reviewers use the tool, which matters as much as how the model is built. Our guide to human review and bias checks in AI hiring covers the review process around the score, and AI résumé screening explains the pipeline that produces it.

FLUIDS builds AI features with explanations designed in from the start, for companies in Saudi Arabia and the GCC. See the HireDash case study, read about AI features inside your product, or talk to us about custom software for your own hiring workflow.