by CandidateScore (LX AI)
Paste JD + resume, review the scorecard, and keep humans accountable for offers. Do not invent demographic inferences.
I started by defining a clear contract between the job description and the resume. The engine reads plain text, extracts clauses, and maps each clause to a skill or requirement phrase. I avoided any model that tries to guess hidden traits; instead I forced the system to show the exact text it used for each match.
The tool accepts two blocks of text: the job description and the resume. No file parsing, no metadata extraction, just the raw strings you paste. I keep the original formatting inside the evidence block so you can see the exact sentence that triggered a score.
For each requirement clause I compute a similarity score using a term‑frequency inverse‑document‑frequency vector. If the similarity passes a threshold I mark it as a strength; otherwise it becomes a gap. The final fit score is the weighted average of all clause scores, scaled to 1‑10.
Every strength or gap stores the source sentence from the resume and the source clause from the JD. I store them as plain text snippets, not as embeddings, so you can audit the decision later. This evidence block is what makes the score explainable.
| Field | Description | Example |
|---|---|---|
| Job description | Free‑form text of the role | "Experience with Python and REST APIs" |
| Resume | Free‑form text of the candidate | "Built REST APIs using Python for two years" |
| Matched clause | JD clause that found a similarity above threshold | "Experience with Python and REST APIs" |
| Evidence snippet | Exact resume sentence used for the match | "Built REST APIs using Python for two years" |
I use the tool each morning when I open a new requisition. The steps are short, repeatable, and leave a paper trail.
I copy the full job description from the hiring manager’s email and paste it into the left box. I do not edit or summarize; I keep the original wording.
I paste the resume text into the right box. If I have a PDF I first convert it to plain text with a free offline tool, then paste.
The engine returns a fit score, a list of strengths, a list of gaps, and the evidence for each. I scroll through the evidence to verify that the match is real and not an artifact of stray keywords.
I add a short note in my applicant‑tracking system linking to the scorecard URL. This note records the date, the score, and any follow‑up questions I have for the candidate.
The output is deliberately limited to what can be traced back to the source documents.
The score ranges from 1 (little overlap) to 10 (near‑complete overlap). I treat scores below 4 as a clear mismatch, scores 5‑7 as worth a conversation, and scores 8‑10 as strong candidates for an interview.
Each strength is a JD clause that the resume satisfied. I show the clause text, the similarity percentage, and the evidence snippet from the resume.
Each gap is a JD clause that did not meet the threshold. I show the clause text, the best similarity found, and a note that no evidence met the cutoff.
For every strength and gap I provide a direct quote from the resume. I never infer meaning; I only show what the candidate actually wrote.
I designed the system to avoid any inference about protected characteristics. The following sections explain the concrete steps I took.
The model never looks at name, address, graduation year, or any field that could hint at age, gender, race, disability, or national origin. I strip those fields before processing if they appear in the resume text.
I check for indirect cues such as school names that correlate with certain groups, or phrasing that might reveal affiliation. If a term appears on a internal watchlist I flag it for manual review and do not use it in the similarity calculation.
Every run writes a log entry that includes the hash of the input texts, the version of the scoring code, and the timestamp. I keep these logs for six months so I can demonstrate that no demographic data was used in a decision.
To stay current with risk management practices I refer to the NIST AI RMF when I review the logics and the watchlist.
I want to be clear about the limits of the tool so you do not mistake it for something it is not.
The score reflects similarity to the written job description only. It does not predict future performance, cultural fit, or team dynamics. I never present the score as a promise that the candidate will succeed.
The recruiter or hiring manager must review the evidence, talk to the candidate, and make the final call. The tool only supplies consistency and traceability.
Unlike opaque models that give a single number with no explanation, CandidateScore shows every strength, every gap, and the exact text that produced each result. You can see why a candidate scored as they did.
Real‑world inputs are messy. I built specific guards for the situations I see most often.
If a resume lacks a skills section I still parse the whole document for keyword matches. I do not penalize a candidate for a non‑standard layout.
I truncate inputs to 10 000 characters before similarity scoring to keep runtimes predictable. I store the full text in the evidence block so nothing is lost for review.
I detect the language of each block with a lightweight classifier. If the resume and JD are in different languages I return a warning and do not compute a score.
I expand common acronyms using an internal dictionary before computing similarity. If an acronym is not in the dictionary I treat it as a literal token.
Improvements come from user feedback and from external guidance on safe AI use.
Every month I export anonymized scorecards with recruiter notes on false positives and false negatives. I review those notes to adjust the similarity threshold or to add new stop‑words.
I follow the OWASP Top 10 for LLM Applications when I evaluate prompt injection risks, even though the tool does not expose a prompt interface to end users.
Each release gets a semantic version tag. I publish a short changelog that lists any changes to the stop‑word list, the similarity threshold, or the evidence extraction logic.
I keep a written checklist next to every release that touches this topic. The list is boring on purpose: name the owner, name the evidence artifact, and name the rollback. If a step cannot produce a file, a ticket, or a log line, it is not a step — it is a wish.
| Signal | What to record | Stop-ship? |
|---|---|---|
| Unexpected write or send | Tool name, args, identity | Yes until gated |
| Missing confirmation on destructive action | Call path and bypass | Yes |
| Untrusted text treated as instruction | Source surface and resulting action | Yes for agent reach |
| Scanner clean, judgment open | Deferred items + owner | Only if core path safe |
candidatescore helps with the measurable first pass. Architecture choices, legal sign-off, and customer-facing claims still need a human owner. Treat every checklist row as decision support, not a certificate.
When a prospect asks whether the product "covers everything," I answer with the boundary: automated checks catch known patterns; novel chains and policy judgment still need review. That honesty keeps support load down and keeps the blog aligned with what the product actually does.
If you need a second opinion, pair this write-up with the references below and with your own staging reproduction. Do not skip the reproduction step just because a model wrote a confident summary.
It lists strengths matched to the JD, gap flags, and the evidence behind each call.
Yes. Every call includes evidence, so you can see why a candidate scored as they did.
You paste the resume and the JD; the tool handles the comparison.
Recruiters and hiring managers who want consistent, evidence-backed screening against a written JD.
Want to try the product? CandidateScore
Generated 2026-09-17 · primary sources only · no fabricated traffic metrics