Once a candidate has been scored, the detail behind that score lives on the Score tab in the candidate’s Application accordion. This guide covers how to read it, and how to change an assessment where you know something Tali couldn’t see.

For what a score means and how it’s worked out, see our Evidence Based Scoring Explained article. For setting up the requirements a candidate is scored against in the first place, see our Evidence Based Scoring Configuration article.

You will need access to the below permissions to work with the Score tab on a candidate’s application:

The Score tab is part of the new Applicant Screen experience, so everything in this guide applies there. It isn’t available on the legacy Application Screen.

Your System Administrator manages these against your role, and you can read more about how in our Managing Roles and Permissions article.

Each of the vacancy’s required and preferred skills appears as its own row in the candidate analysis. This guide describes the detailed view, and a compact view is also available, showing the same information in a briefer form. A row tells you two separate things, and it’s worth keeping them apart in your head, because a candidate can be a strong match on paper with thin evidence behind it, or a looser match that they’ve evidenced thoroughly.

The match badge describes how closely what the candidate has done lines up with the requirement.

A Not Found row doesn’t carry badges, because there’s no match and no evidence to describe.

Separately, each matched row carries an evidence badge describing how well supported that match is.

The evidence badge is about whether the work was actually shown, not how impressive the skill sounds. A skill that appears only in a list of skills, in a run of keywords, under a heading, or as a self rating can’t be Demonstrated, however senior or specialist the skill itself is, because all it tells you is that the word is on the page.

Reading the two badges together is the useful part. An Exact Match with a Claim Only badge isn’t a weak candidate, it’s someone who may well have the skill but hasn’t shown it, which is a good follow up question rather than a reason to move on.

If you’ve read our Evidence Based Scoring Explained article, this is where its two sub scores show up on screen. Match strength, together with the years of experience and skill recency covered further down, is what makes up Capability: how able Tali judges the candidate to be. The evidence badge is what feeds Evidenced: how well that capability is actually backed up.

Before anything else, it’s worth saying what isn’t involved. Eligibility requirements don’t feature in this at all. They’re a straight pass or fail, and they sit completely outside everything described below.

For everything that is scored, so required skills, preferred skills and behaviours, the match badge and the evidence badge work together. One isn’t simply added to the other. Both matter, but match strength is the bigger factor of the two, so a direct fit that hasn’t been proven still lands above a loose fit that has.

The table below runs from the strongest result to the weakest, with a simple 1 to 10 points scale alongside it to make the idea easier to picture.

The ordering within each match state is the same one the evidence badge table above describes: Demonstrated sits above Inferred, which sits above Claim Only.

Every matched row shows its Strongest Evidence: the single best supporting quote from the candidate’s application, with the job title, company, dates and evidence source shown underneath, so you can see not just what they said but where and when.

That evidence doesn’t only come from the CV. A quote can just as easily come from an answer the candidate gave directly on the application form, and the evidence source tells you which one you’re looking at. Today that means the candidate’s CV and their application form answers, with more source types planned for later phases. It’s worth knowing if you think of this as CV matching, because a real share of what sits behind a score comes from the form answers rather than the CV.

Where Tali found more than one piece of evidence for a skill, a ‘Show Additional Evidence’ control expands the row to reveal the others. A skill can carry several pieces of evidence rather than only one, so if a single quote looks thin, it’s worth expanding the row before drawing a conclusion.

Those additional quotes commonly come from different jobs across the candidate’s whole career, not just from different lines within the same role. A “Staff management” skill, for example, might be supported by both a recent role managing a larger team and an earlier, smaller one, shown together on the same row. That’s Tali gathering the evidence for a skill across a candidate’s entire work history rather than stopping at their most recent job, so it’s normal and expected rather than something to question.

A row also shows a Total Years of Experience figure. This is always worked out from the dates behind the evidence rather than typed in by anyone, so it’s built from real dates, or from a duration the candidate stated outright, rather than from an assumption about how long their career has been.

Because each skill is calculated from its own evidence, two skills on the same candidate can legitimately show different years figures. That’s expected rather than an inconsistency: a candidate who has been working for eight years might have six years against one skill and two against another, depending on which roles evidenced which.

How recently a skill was used matters too. A skill still in active use doesn’t fade at all, while one that hasn’t been used for a while loses a little of its value, and how much it loses depends on how deeply it was held in the first place: several solid years behind a skill survives a gap far better than a brief brush with it.

The vacancies behaviours, things like communication or teamwork, get their own rows too, and they read exactly the way a skill row does for the two badges: a match badge for how closely the candidate’s evidence lines up with the behaviour, and an evidence badge for how well that’s backed up.

What a behaviours row doesn’t carry is a Total Years of Experience figure or a Skill Recency, because a working style isn’t something that fades the way a technical skill does. Someone who communicates well doesn’t get rusty at it the way they might with a piece of software they haven’t touched in five years.

The examples below show how a requirement, a quote and the four things above, match strength, evidence type, years of experience and recency, come together in practice.

Example A, the highest end of the scale

Match strength is Exact: the requirement is team leadership, and the quote describes actually running a team, the same activity. Evidence type is Demonstrated, because a specific context is described rather than the skill simply being named. Years of experience comes out at three years, which is a meaningful figure, since the biggest jump is between no experience and some, and three years is well past that point. On recency, the role is still current, so the skill is in active use and there’s no fade at all. Every factor pulls the same way, which puts this at the top of the scale, 10 out of 10 on the example points.

Example B, a good match held back by proof

Match strength is Exact, because the words on the page name the requirement directly, but evidence type is Claim Only: it’s named with nothing behind it, and sitting in a skills list can’t make it Demonstrated. There’s no years figure and no recency, because there’s nothing to calculate either from. That lands mid scale at 7 out of 10, a genuinely strong match that simply hasn’t been proven yet.

Example C, the same strong match, reduced by time

Match strength is Exact and evidence type is Demonstrated, because a specific task is described, with two years behind it. The skill hasn’t been used since 2017 though, so it’s had several years to fade, and two years’ worth fades faster than a more deeply held skill would. Same match and evidence as Example A, but it lands below 10 out of 10 purely because of the time gap, which shows years and recency keep mattering even once match and evidence are as strong as they get.

Example D, adjacent match, claim only

Match strength is Adjacent: supervising is closely related to leading a team and genuinely transferable, but a step removed in scope from actually leading one. Evidence type is Claim Only, since it’s only named in a list with nothing describing what it involved. There’s no years figure, and recency doesn’t apply. Two uncertainties stack up here, landing this low on the scale at 4 out of 10. It’s worth a genuine follow up question, but it isn’t close to a confirmed fit yet.

Example E, adjacent match, demonstrated

Match strength is Adjacent: covering as shift lead for a small team is closely related to team leadership and genuinely transferable, but it’s a smaller scope and setting than the role asks for. Evidence type is Demonstrated, because a specific context is described. Years of experience is still building, since the role is recent, but it counts for something. On recency, this is a current role, so there’s no fade. The result is a real, proven capability a step below a direct match in scope, sitting mid scale at 6 out of 10.

Example F, weak match, demonstrated

Match strength is Weak: it’s genuinely related to team leadership, but it’s a one off, low detail instance rather than anything resembling actually leading a team, so it’s only loosely relevant. Evidence type is Demonstrated, because a specific instance is described, so as far as it goes it’s proven rather than just claimed. Years of experience works out at around a year, taken from the job’s dates, which is a real contribution on its own. On recency, the role ended in 2022 and the skill hasn’t come up since, so there’s been a gap, and with only around a year behind it, more of that value fades over that gap than it would for someone with several years in the same skill. Even with genuine years behind it and proven evidence, the match itself is so thin that this lands right near the bottom of the scale, 3 out of 10. Match strength is what’s holding this one back, not the proof or the experience.

Examples A, D, E and F all use the same requirement, Team Leadership, on purpose, so they’re worth reading side by side as one illustration of how the same requirement can land anywhere on the scale depending on the candidate’s actual evidence.

Alongside the skills your vacancy asked for, the analysis includes an Other Skills section: skills Tali found on the candidate that this role didn’t ask for. It’s there to show you what else the candidate can do, which is often useful when you’re weighing someone up for a different role or a wider team.

These rows work the same way as any other, with Strongest Evidence, the quote, the job details, the evidence source and Show Additional Evidence all behaving identically. The difference is that they carry no match badge, because there’s no requirement to match them against, and they use a neutral unfilled circle icon in place of the usual match state icon.

Everything above describes how a skill row reads. A Preferred Qualifications row works differently, because a qualification is a simpler thing to establish: it’s either matched to something real in the candidate’s record or it isn’t. There’s no match strength and no evidence strength to grade, so a qualification row carries no Exact, Adjacent or Weak badge, and no Demonstrated, Inferred or Claim Only badge.

The supporting detail is different too. In place of a job title, company and employment dates, a qualification’s evidence shows the issuing body and the completion date, since a qualification isn’t tied to a period of employment the way a skill is.

The role’s eligibility requirements are listed alongside the skill analysis, each with its current state, so you can see the must haves separately from anything that’s scored.

An eligibility requirement is still fundamentally a pass or fail check: it’s either confirmed or it isn’t. What’s changed is how much detail sits behind that answer. A requirement row can now carry the same supporting detail a skill row does, so where Tali has found something relevant you’ll see a match badge, an evidence badge, a Total Years of Experience figure, the Strongest Evidence quote, and the job title, company and dates it was attributed to, underneath the requirement itself. That detail reads in an extremely similar way to a skill row, with one addition: the row also shows which eligibility requirement that evidence was matched against, so you can see exactly what Tali was checking it for.

This is useful in both directions. On a confirmed requirement it shows you what the confirmation was actually based on, so you can check whether it rests on a direct answer or on something looser. On a requirement that couldn’t be confirmed, any evidence shown tells you how close the candidate came, which is often the difference between a quick question and a longer conversation.

Once someone has edited a requirement, the row carries a “last modified by [name] on [date]” tooltip, so it’s clear who confirmed a requirement and when. That matters on requirements a person has to check by hand rather than something found in the application.

A requirement Tali couldn’t find evidence for shows with a warning icon, the requirement’s name, and the text “No evidence found for this requirement”.

This is worth reading as exactly what it says. It means nothing in the application spoke to that requirement either way, not that the candidate doesn’t meet it. It’s common on requirements that can’t be confirmed from an application at all, such as right to work, which always needs checking directly with the candidate rather than relying on anything in the application. These are the requirements to confirm with the candidate yourself, using the steps further down.

A requirement in this state can still show supporting detail underneath it where Tali found something related without being able to treat the requirement as met, in the same form as a skill row: a match badge, an evidence badge, a years figure, a quote and its attribution. Read that as context rather than as a confirmation, and check the requirement with the candidate either way.

Where an eligibility requirement is marked as not met, the candidate’s score is hidden rather than shown, and a red ‘Not Met’ banner appears in its place, along with an option for you to act on the outcome.

A Not Met verdict always has a visible reason behind it, so you’re never left with a bare fail and nothing to explain it. Most often that reason is a direct ‘No’ answer to a screening question naming the credential, or an explicit statement from the candidate that they don’t hold it or don’t have the experience the requirement asks for. Whichever it is, you can read what the verdict was based on and judge it for yourself before deciding what to do next.

The score is hidden because it would be misleading: a candidate who doesn’t hold something the role genuinely requires isn’t well described by a percentage. Nothing happens to the candidate on its own, though. No candidate is progressed or rejected automatically, so acting on a Not Met outcome is a step you choose to take.

Sometimes you’ll know something Tali couldn’t, whether that’s context a candidate gave you on a call or a licence you’ve checked personally. Hovering over a row reveals an edit pencil, which opens the Edit Skill Modal. The pencil only appears if you hold the Score - Editor permission.

The same modal handles both skills and eligibility requirements.

Every skill needs at least one piece of evidence, so a skill can’t be saved with nothing behind it. You can add entries as well as work with the ones already there.

It’s worth being clear with yourself about when to do this. An override is for recording something you’ve genuinely checked or been told directly, a licence you’ve seen, or a specific example a candidate talked you through on a call. It isn’t a way to nudge a score towards a decision you’ve already made on other grounds, and a score edited to fit a conclusion stops being useful to anyone who looks at the candidate after you.

Where the evidence came from a conversation rather than the application itself, use the Source field to say so, and choose the Evidence Type that honestly matches what you heard: Demonstrated if the candidate described a specific example to you, or Claim Only if they simply confirmed they have the skill without describing how they’ve used it.

Editing an assessment only affects the candidate you’re looking at. It doesn’t change how anyone else is scored, on this vacancy or any other.

Each evidence entry has its own fields:

Years of Experience isn’t something you type. It’s worked out from the dates you choose.

When you open the modal on an eligibility requirement rather than a skill, it also includes a Category selector. This is how you record the outcome of a check you’ve made yourself, so a requirement that came back with no evidence doesn’t simply sit unresolved.

There are three options:

Setting the Category to Not Met is what produces the Not Met banner and hides the score described above. Setting it to Confirmed records the requirement as met, so it stops showing as an outstanding gap on the candidate.

Timing matters here. If you’ve reached out to a candidate about a requirement and haven’t heard back yet, leave it as Not Found rather than guessing either way, because that’s exactly the state an unresolved requirement is meant to sit in. Confirmed and Not Met should both reflect something you’ve actually checked, not an assumption you’re expecting to be right about, since the row records your name against the change and it’s read as a decision on the record rather than a placeholder.

Once you save, the row records your change, and the “last modified by” tooltip shows that you were the one who confirmed it.

Editing a skill or an eligibility requirement changes that row straight away. Add a date, correct a job title, change any other detail, and the row shows your change as soon as you save it.

The candidate’s overall score is a separate thing. Your edit doesn’t feed into it on its own, so the score you can see still reflects the assessment as it stood before you made any changes. It only catches up once the candidate has been rescored.

That’s deliberate, because it means you don’t have to rescore after every single edit. You can work through a candidate, make all the changes you want to make, and then rescore once when you’re ready.

This only happens because of changes someone has made by hand in the way described above. Nothing else puts a candidate into this state.

Every rescore is recorded in the candidate’s timeline, so there’s a lasting record of what was reassessed and when.

You can order your candidate list by score from the filters tab, so the strongest matches sit together. Each score is still one candidate measured against the role’s requirements rather than a ranking against other candidates, so ordering by it groups the best evidenced matches at the top rather than ranking people against each other.