Rule-based vs. contextual resume parsing: where each one breaks

For years, most “resume parsing” in applicant tracking systems has been built on rules: regex for emails and phone numbers, keyword lists for skills, and heuristics like “the first bold line near the top is probably the name.” That approach works passably on a narrow band of resume formats and breaks on the layouts it wasn’t written for: two columns, a skills table, or a section header it wasn’t told to expect.

Where rule-based parsing genuinely breaks down

• Multi-column layouts. Reading order becomes ambiguous the moment there are two columns; a rules engine that reads left-to-right, top-to-bottom will interleave text from unrelated columns into one garbled stream.
• Non-standard section headers. Rules key off expected header text like “Experience” or “Education.” A resume that uses “Where I’ve Worked” or skips headers entirely needs its own new rule, forever.
• Dates mixed with an ongoing role. “Present,” “current,” or a blank end date all mean the same thing to a human reader and need different handling to a rule that only knows fixed date patterns.

Where contextual extraction moves the ceiling — and where it still isn’t perfect

Extraction that reads for meaning is not written against a list of expected headers or a fixed reading order the way a rules engine is, so a new header or layout does not need a new rule. How well that holds on two-column layouts and unusual headers is something we have not measured, and multi-column layouts remain among the formats that can produce wrong or incomplete output. That isn’t “solved,” and it’s worth being specific about where it still falls short rather than claiming otherwise: in live testing, the extraction model didn’t always follow the requested date format exactly — it sometimes returned “June 2021” instead of the requested “2021-06” — and in one live test it returned null instead of the literal string "present" for an ongoing role’s end date (a second live test on the same field correctly returned "present"). In our parser, an email, phone number or date the model reports but cannot quote from the resume, including a date in any form other than YYYY, YYYY-MM, YYYY-MM-DD or "present", comes back as null and is named in the response’s withheld list. A null with no withheld entry means the model did not report that value. Those are real, known limitations, not hypothetical ones, and they’re exactly why this kind of extraction still needs the same discipline as any other AI output.

The honest tradeoff

Rule-based parsing is cheap, fast, and fully deterministic, but brittle against the real variety of resume formats in the wild. Contextual extraction needs no new rule for a new layout, but it’s probabilistic, not deterministic — which means it needs the same guardrail any AI extraction needs: a confidence score, and a policy for what happens when that score is low.

How Aervik Labs’ AI Resume Parser handles this

The AI Resume Parser accepts a resume as plain text, a file URL, or base64-encoded file data, and returns normalized JSON — contact info, work history, education and skills — with a confidence score and a withheld list in each successful response. Treat a low-confidence response, a non-empty withheld list, or any field returned as null or an empty array, as needing human review, not ground truth. Update, 2026-09-11: this paragraph originally described an estimated_seniority_level field. That field has been removed; the API no longer classifies the candidate, only reports what the document says. Resumes are personal data by definition, so it’s also worth knowing that Aervik Labs does not store submitted content beyond what’s needed to process the request — no database, no logging of resume content, no retention of any extracted field once the response is returned. Parsing runs on an AI model, so the resume is sent to our model provider, Anthropic, which processes it under its own data-retention policy. Each request also passes through RapidAPI and Cloudflare (security).