AI CV Screening in Hiring

Two different jobs go by the same name. The first is reading: pulling the experience, education, language, project and certificate fields out of the PDF and placing them in a fixed schema. The second is scoring: checking whether those fields meet the requirements of one specific posting. This page describes the first layer, while ranking against a posting belongs to the position fit score.

In practice that means reading does not depend on the posting. Whichever posting a CV is submitted to, it is extracted into the same schema and the same years of experience are computed. Only the second layer depends on the posting, which is why one candidate can hold two different fit scores on two postings.

Once reading finishes, a search text is built from the structured profile and split section by section: every experience and every project becomes its own chunk, while the identity and summary block stays a single chunk. At most 10 chunks are stored as vectors. The split exists so that an evidence search returns a focused passage instead of an average of the whole document.

• Submitting the form never makes the candidate wait on the analysis: the record opens, the confirmation screen appears right away and the analysis runs in the background
• The panel shows four progress steps: Reading CV, Processing Text, AI Analysis, Saving Results
• Once the structured data is ready, six narrative analyses run in parallel: summary, skills, education, languages, soft skills, experience
• A daily sweep job picks up applications that could not be analyzed; every recovered application is written to the event log

On the candidate side the only accepted format is PDF. The structural layer keeps a non PDF file, anything over 5 MB, a password protected PDF and a file past the page limit out of the analysis entirely; the page ceiling defaults to 15 and moves with an environment variable. DOCX and other formats apply only to the Drive import on the Enterprise plan, and even there they run through the same flow after conversion to PDF.

The gate runs before any credit is spent. When an invoice, a thesis or a contract is uploaded, no AI evaluation credit is consumed, the run is marked failed and there is nothing to refund. The document reaches the classifier as data, never as a command; what is looked for is not a word pattern but who the wording addresses. A candidate describing their own competence does not count as an instruction.

Finding an instruction marker does not stop the analysis. The record enters the human review queue, the detected wording is shown to HR verbatim, no text shown to the candidate changes and no candidate is rejected. In our measurement the effect of hidden text on the score came out at zero under both methods; the reason is not the scan, it is the rule that every item carries a verbatim quote.

Extraction is one multimodal call: the PDF goes to the model as it is, the output comes back at temperature 0 and is validated against a schema. If the schema does not hold, extraction errors out and no partial data is saved. The fields are fixed: personal details, summary, experiences, education, skills, languages, projects, certificates, achievements and publications.

Dates are converted from free text into one format. 03/2024, 2024-03-01, March 2024 and Mar 2024 all land in the same shape, and a date that cannot be resolved is left empty. The precision the candidate wrote is recorded too: when only a year is given the field is flagged as such, and near a threshold the hard criteria gate turns it into unknown rather than rejecting the candidate.

After extraction a correction layer runs in code: a record that belongs under projects but landed under experience is moved and saved with the reason for the correction. Normalization pulls role titles and degree names into one spelling without deleting the original, which is kept in a separate field. Language level is extracted exactly as the CV wrote it; mapping to a single scale happens in the next step, in one place.

• Employment type is taken from the CV's own wording and never inferred; volunteering is its own type, because a volunteer role with a professional title used to be counted as a job on a keyword match
• Every experience line keeps company, position, dates, responsibilities, achievements and technologies as separate fields
• On the education side school, department, degree, year, grade average and ongoing status are separate fields
• When extraction confidence comes out medium or low, HR sees a warning on screen and no data is hidden

Total years of experience are not an estimate, they are a calculation made in code. Overlapping roles count once, part time roles enter at half weight, internships and volunteer work stay out of professional years, and an ongoing role is pinned to the analysis date. The reasoning is recorded as well: overlap deduplicated, part time halved, internship excluded, date invalid.

The seniority label the model returns is capped downward against that calculation. Even when the model says senior, the label drops if the years do not support it; on an internship application the ceiling stays junior. A dimension score is not a number the model produced either, it is the share of a fixed evidence list that was met.

Added up, that means 89% of the overall score is computed from the CV in code, not asked of the model. The model produces no numbers; it answers, item by item, whether something is evidenced in this CV and leaves a verbatim quote next to its decision.

Once the analysis completes, a document level anomaly scan runs and combines two stuffing signals: a flag is raised when the number of declared skills passes the threshold while the usage ratio stays below it, or when the share of skill names that appear in no experience exceeds the threshold against the words in the document. The defaults are 25 declarations, a 35% evidence ratio, 3% unbacked keyword density and 1 month of future date tolerance; all of them move from company settings.

Skill matching is not literal equality but a canonical resolver: React, React.js, ReactJS and React 18 are one technology, and the comparison is ASCII folded, so a skill written with diacritics and the same skill written without them are one entry. So that the density signal is not biased against short CVs, it carries two floors: below 40 words it is not measured at all, and below 6 unbacked skills it produces no signal. The measured limit sits right here: in our own measurement this document level threshold missed medium scale stuffing.

A flag never rejects anyone, it closes a channel: when the stuffing flag is on, an item that appears only in the skill list earns no points. Invisible text detection is not performed, and that is a written decision: the color and the transparency of text cannot be read inside the compressed content of a PDF, and the project carries no library that would open it. The AI never changes an application status on its own, and the system does not learn from past hiring outcomes either.

• One CV analysis spends exactly one AI evaluation credit; if the run fails mid analysis the credit is refunded automatically
• The integrity gate, turning chunks into vectors and recomputing the score spend no credit; those come with the subscription
• If the same file is uploaded a second time, the analysis returns without downloading the CV; if the file differs but the facts are identical, extraction runs and the six analyses come from cache
• Staleness looks at four signatures: file digest, criteria digest, scoring configuration digest and analysis version
• When the same fact set turns up on another application, the same candidate gets an information note and a different candidate gets a human review record
• For a user without permission to see personal data, the matched CV passage and the quotes are masked on the server while the flag itself stays