JD-aligned screening with an honesty boundary

How we built the scoring engine

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.

Data inputs

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.

Matching logic

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.

Evidence capture

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.

Example table of input fields

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"

Typical workflow for a recruiter

I use the tool each morning when I open a new requisition. The steps are short, repeatable, and leave a paper trail.

Step 1: Paste JD

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.

Step 2: Upload resume

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.

Step 3: Review scorecard

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.

Step 4: Add notes

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.

What the scorecard contains

The output is deliberately limited to what can be traced back to the source documents.

Fit score scale

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.

Strengths vs JD

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.

Gap flags

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.

Evidence lines

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.

How we stay within EEOC guidelines

I designed the system to avoid any inference about protected characteristics. The following sections explain the concrete steps I took.

Attributes we ignore

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.

How we avoid proxy signals

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.

Audit trail

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.

What this is NOT

I want to be clear about the limits of the tool so you do not mistake it for something it is not.

Not a guarantee of hire

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.

Not a replacement for human judgment

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.

Not a black‑box ranker

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.

How we handle edge cases

Real‑world inputs are messy. I built specific guards for the situations I see most often.

Missing sections

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.

Very long documents

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.

Multiple languages

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.

Ambiguous abbreviations

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.

How we update the model

Improvements come from user feedback and from external guidance on safe AI use.

Feedback loop

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.

External standards

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.

Versioning

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.

Operator checklist for JD-aligned screening with an honesty boundary

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.

Before you change production

- Freeze the branch or config revision you will measure against. - Record the current failure mode with one concrete input and one concrete output. - Confirm which identity the job runs as, and whether that identity can reach data it should not. - Open the primary references you will cite: https://owasp.org/www-project-top-10-for-large-language-model-applications, https://www.nist.gov/itl/ai-risk-management-framework.

While you run the check

- Prefer one reproducible path over ten anecdotal screenshots. - Write the expected safe outcome before you trigger the tool or query. - Capture the exact command, prompt, schema, or regex under test — not a paraphrase. - If the system can act (send, write, delete, transfer), require a confirmation boundary in the same pass.

After you finish

- File residual risk with an owner and a date, even when the scan is clean. - Do not convert a green check into sales language that claims completeness. - Re-run the same checklist when the model, tool schema, or validation rules change.

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.

How I explain limits to buyers

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.

References

- https://owasp.org/www-project-top-10-for-large-language-model-applications - https://www.nist.gov/itl/ai-risk-management-framework

Frequently asked questions

What is in the scorecard?

It lists strengths matched to the JD, gap flags, and the evidence behind each call.

Is the score explainable?

Yes. Every call includes evidence, so you can see why a candidate scored as they did.

Do I need to format the resume?

You paste the resume and the JD; the tool handles the comparison.

Who should use it?

Recruiters and hiring managers who want consistent, evidence-backed screening against a written JD.

References

- EEOC — Prohibited employment policies - NIST AI RMF

Want to try the product? CandidateScore

Generated 2026-09-17 · primary sources only · no fabricated traffic metrics

Related reads

- Evidence-backed resume scorecards beat black-box ranks — CandidateScore - The LX AI Micro-SaaS Topic Matrix