Recruiting & HR Tech

An LLM-Powered Resume Parsing and Candidate Scoring Platform for Two-Sided Hiring at Scale

How Pfactorial Technologies built a resume parsing and job-matching pipeline that turns unstructured PDF resumes into structured, scored candidate profiles for a two-sided hiring platform.

August 21, 2026

OUTLINE

ENGAGEMENT SNAPSHOT

Pfactorial_Case_Study_ResumeIntelligence image 1

Figure 1 - Key figures from this engagement, at a glance.

EXECUTIVE SUMMARY

Our client operated a two-sided hiring platform where candidates upload resumes and recruiters review scored shortlists, with the core constraint of turning free-form PDFs into structured, comparable data for two audiences who wanted opposite things from the same match.

A single generic LLM pass wasn't enough on its own: malformed or irrelevant uploads needed to be caught before they reached a costly model call, an incomplete job description produces confident nonsense from a language model if it's scored rather than rejected, and a candidate wanting to know what's missing and a recruiter wanting a single sortable number can't be served by one prompt.

Pfactorial built the platform's resume intelligence pipeline: an LLM-backed parser wrapped in a lightweight classifier gate, and two purpose-built scoring prompts - one for candidates, one for recruiters - behind a validation layer that rejects incomplete job descriptions before they reach a model.

Why this engagement is representative This engagement demonstrates Pfactorial's ability to take a working but fragile multi-service ML pipeline and consolidate it into one auditable call with real fallbacks, a repeatable pattern for any document-heavy platform carrying legacy specialist models.

THE CHALLENGE

Turning free-form resumes into data two different audiences could trust meant solving problems that don't show up until real resumes and real job posts start arriving.

1. A single generic LLM call isn't enough to safely parse arbitrary uploads

Malformed, irrelevant, or non-resume uploads needed to be caught before they reached a costly LLM call, so a lightweight classifier had to gate the pipeline first.

2. Candidates and recruiters want opposite things from the same match

A candidate wants to know what's missing so they can improve their resume; a recruiter wants a single sortable number. One scoring prompt can't do both honestly.

3. An incomplete job description produces confident nonsense

Scoring against a JD lacking a title, skills, or responsibilities gives a plausible-looking but meaningless score unless the JD is validated and rejected first.

4. External job data sits in a legal gray zone a scraper can't resolve on its own

Nine of eleven target sites explicitly prohibit automated collection in their terms of service, and no site has granted written consent, so that data had to stay separated from safe production use.

The real brief Not "call an LLM on the resume" but "gate every call behind cheap validation first, and score the same match twice - once for the person, once for the recruiter - because they are not asking the same question."

THE SOLUTION

Pfactorial built a three-layer pipeline - application, backbone, and an independent scraping subsystem - that turns a PDF into structured JSON and then compares that JSON against a job description with two separate, audience-specific scoring passes.

Pfactorial_Case_Study_ResumeIntelligence image 2

Figure 1 - Every resume passes through a cheap classification gate before it ever reaches a model, and scoring only runs once the job description itself has been validated.

Architectural principles

Validate before you spend on a model call - A binary resume/non-resume classifier and a JD completeness check both run before any LLM call, catching the majority of bad input at negligible cost.
Collapse a fragile chain into one call with a fallback - The eleven-service predecessor architecture produced good section-level accuracy but needed ten or more round trips per resume and was hard to debug when one service degraded; the LLM parser replaced that chain with a single call plus a fallback path.
Score twice, not once, when the audience differs - Candidate-facing and recruiter-facing scoring are separate endpoints with separate prompts and separate output shapes, because a candidate needs gaps to fix and a recruiter needs a number to sort by.
Keep the model layer stateless and swappable - The backbone persists nothing and only takes a payload and returns JSON, so the primary model and its fallback can be swapped without touching the application layer that owns identity, resumes, and jobs.

CAPABILITIES DELIVERED

Each capability maps onto one of the platform's two audiences or the shared pipeline underneath both.

CAPABILITY	WHAT IT DOES
Guest resume scoring	Anyone can upload a resume and score it against a fixed set of job links with no account, which is how the funnel starts.
Candidate resume builder & profile	Candidates build or upload up to three resumes; shared detail tables auto-populate one profile so a candidate fills their history once.
Candidate-facing gap scoring	Candidates get a match percentage, missing keywords, and missing skills - framed to prompt an edit rather than gatekeep.
Recruiter-facing ranked scoring	Recruiters get five weighted numeric fields with no prose, built to feed a sortable candidate list.
ATS-readiness guidance	Candidates get concrete formatting rules - single-column layout, real text not images, unambiguous dates - for the reasons resumes fail to parse in the first place.
External job aggregation	A two-stage scraper collects links, then extracts details from external job boards to widen the pool candidates can apply against.

Pfactorial_Case_Study_ResumeIntelligence image 3

Figure 2 - One structured parsing pipeline feeds two audience-specific scoring passes.

Design note The candidate-facing score is floored above zero by design - a deliberate product choice to keep the score motivational rather than a calibrated pass/fail signal, which also means it cannot be read as a probability of getting the job.

ENGINEERING FOR SCALE AND RELIABILITY

Five decisions kept the parsing and scoring pipeline defensible as usage and job-site coverage grew.

A binary classifier gate before every LLM call

A model trained on 1,000 resumes decides resume-or-not in one cheap inference, stopping the most common category of bad or malformed upload before it costs an LLM call.

JD validation before scoring, not after

A job description missing a title, skills, or responsibilities is rejected outright rather than scored, because an incomplete JD produces confident nonsense from a language model - this is the cheapest guard in the system.

A primary model with a real fallback, not a single point of failure

Groq LLaMA3-70B is the default for parsing and scoring, chosen for cost and latency, with GPT-4o-mini as the fallback when Groq errors or rate-limits.

Keep the specialist model chain rather than delete it

The eleven-service predecessor architecture - layout extraction, section classification, category prediction - is still deployed where it's still the better tool, particularly for OCR on scanned documents and category prediction.

Separate the deterministic scorer from the LLM scorer

The earlier rule-based scoring endpoint, using Levenshtein skill overlap and spaCy designation similarity, remains a documented alternative precisely because it is reproducible where the LLM scorer is not.

DELIVERY APPROACH

The engagement built outward from a specialist-service foundation toward a consolidated LLM pipeline, then layered dual scoring and external sourcing on top.

1. Specialist-service architecture - shipping eleven narrow, orchestrated services - layout extraction, section classification, skill extraction, timeline building, category prediction - to establish section-level parsing accuracy first.

2. LLM-based parser consolidation - replacing the multi-service chain with one schema-shaped LLM call plus a classifier gate, cutting ten-plus round trips per resume down to one.

3. Rule-based post-processing - adding deterministic cleanup - phone and date normalisation, work-history day totals - so the model isn't asked to do arithmetic it gets wrong.

4. Dual scoring endpoints - building separate candidate- and recruiter-facing scoring prompts behind a shared JD-validation gate.

5. External job collection - standing up a two-stage scraper - link collection, then site-specific extraction - running independently of the application on its own schedule.

RESULTS AND IMPACT

Pfactorial_Case_Study_ResumeIntelligence image 4

- Key outcomes from this engagement.

The classifier-gated LLM parser and the two audience-specific scoring endpoints are live in production, replacing a fragile eleven-service chain that needed ten or more round trips per resume with a single call plus a documented fallback.

Because validation runs before every model call - a resume/non-resume gate on parsing, a completeness check on job descriptions before scoring - the system spends its LLM budget on inputs likely to produce a usable result rather than confident nonsense on bad input.

What it enabled commercially

Recruiters can now filter and rank scored candidates in one list instead of reading resumes manually, and candidates get actionable, ATS-aware guidance on why a resume might be scoring badly - both running on a pipeline that can absorb new external job sources without a redesign, once site permissions are resolved.

WHY PFACTORIAL

This engagement reflects Pfactorial's ability to take a working but fragile multi-service ML pipeline and consolidate it into a single, auditable call with real fallbacks - without discarding the specialist models where they're still the better tool for the job.

Pfactorial_Case_Study_ResumeIntelligence image 5

- Service lines this engagement draws on.

Engagement enquiries Pfactorial Technologies works with organisations that need document-heavy, LLM-backed pipelines - resume parsing, candidate matching, structured extraction from unstructured uploads - built to survive real production traffic, not just a demo. If you're evaluating an ML pipeline that has to gate its own costs and stay explainable, we're happy to give you an honest read on scope and risk before anyone commits to anything. · pfactorial.ai

APPENDIX A - TECHNOLOGY STACK

The technology stack underpinning the system, grouped by the layer it serves.

Pfactorial_Case_Study_ResumeIntelligence image 6

Result and Analysis

ENGAGEMENT SNAPSHOT

How Pfactorial Technologies built a resume parsing and job-matching pipeline that turns unstructured PDF resumes into structured, scored candidate profiles for a two-sided hiring platform.