Inside NexeraHR's resume-parsing pipeline
August 18, 2026 · Muhammad Hammad · Co-founder & Engineer, Vision Nexera · 1 min read
Updated
Resume parsing looks like a solved problem until you meet real resumes: two-column layouts, five date formats, job titles that mean different things at different companies. Our pipeline gets reliability from three decisions: a strict output schema, rules where determinism wins, and every human correction becoming a permanent test case.
Why parsing is the hard part of an ATS
Everything downstream (matching, ranking, screening) inherits the quality of the structured profile, so a parsing error is not one bad field but a candidate mis-ranked for every role they touch. And the input is adversarially diverse: designers ship resumes as visual art, engineers as plain text, executives as scanned PDFs. A pipeline that only handles the well-formatted majority quietly discriminates against everyone else.
Decision one: the schema is the contract
The extractor's job is not 'read this resume' but 'produce this exact structure': typed fields, controlled vocabularies for things like employment type, explicit null for genuinely absent data. A strict schema converts the fuzzy question 'did the model understand?' into the checkable question 'is this output valid and accurate per field?', which is the question you can build a business on.
Decision two: LLM where judgment, rules where determinism
Language models are superb at the genuinely ambiguous parts: reading a two-column layout, inferring that 'Growth Lead' is a marketing role. They are unnecessary risk for dates, emails, and phone numbers, where boring normalization code is faster, cheaper, and correct every single time. The pipeline splits the work accordingly and is better for it in both cost and accuracy.
Decision three: corrections become fixtures
When a recruiter fixes a parsed field, that correction is captured as an evaluation fixture: a real resume with a verified right answer. The eval set therefore grows exactly where the pipeline is weakest, and every change to prompts or models runs against it before shipping. Parsing accuracy stops being a vibe and becomes a number with a history.
This is also why we distrust vendors quoting universal parsing-accuracy percentages: accuracy against which fields, on whose documents, verified by whom? The honest claim is a methodology, and this one (schema-first extraction, deterministic normalization, human-corrected fixtures) is ours, transferable to any extraction problem a client brings us.