Scope
What the protocol measures
The test measures whether a named system recovers expected text and maps selected values to the correct fields. It keeps document extraction separate from job matching and recruiter decisions.
A passing field test for one parser says nothing about another parser unless that second system runs the same files.
Baseline record
Fixed resume content
The baseline uses fictional but realistic data. Every variant contains the same words, dates, punctuation, and section order.
- Identity
- Full name, city, email, phone, portfolio URL
- Experience
- Three employers, three titles, six dates, twelve bullets
- Education
- Degree, institution, graduation month and year
- Skills
- Twenty terms including C++, C#, .NET, CI/CD, and PostgreSQL
- Unicode
- Accented name, curly apostrophe, bullet, en dash, and ligature case
- Sections
- Summary, Work Experience, Projects, Education, Skills, Certifications
Variants
One document feature changes per file
| ID | Changed feature | Baseline held fixed | Primary failure to inspect |
|---|---|---|---|
| B-01 | Single-column DOCX | All content | Baseline field recovery |
| B-02 | Native-text PDF export | Layout and content | Character fidelity and content order |
| V-01 | Two-column PDF | Content and styles | Interleaved reading order |
| V-02 | DOCX table layout | Content and visual placement | Cell flattening order |
| V-03 | Contact data in page header | All other content | Missing contact fields |
| V-04 | Icon-only contact labels | Contact values | Lost field context |
| V-05 | Custom section headings | Section contents | Wrong section classification |
| V-06 | Image-only PDF | Visible page appearance | No native text extraction |
| V-07 | OCR-enhanced scan | Scanned page image | Recognition and order errors |
Expected data
Compare fields before calculating anything
The expected-data manifest stores each literal value and its relationship to nearby fields. An employer name must be present and attached to the correct title and dates. Finding the word somewhere is not enough.
{
"experience[0]": {
"employer": "Northstar Labs",
"title": "Data Engineer",
"start": "2023-04",
"end": "present"
}
}Outputs
Record separate error categories
Text recovery
Expected literal strings found in the extracted output.
Field accuracy
Expected values mapped to the correct field or candidate-profile location.
Relationship accuracy
Employer, title, date, and bullets remain part of the same experience entry.
Order fidelity
Extracted blocks appear in the intended reading sequence.
Character fidelity
Unicode characters return as the intended text instead of substitutions.
Run failure
The system rejects, times out, attaches without parsing, or returns no output.
Run record
Required metadata
- System and product name
- Visible version or release channel, when available
- Date and timezone of the run
- Account configuration and enabled modules visible to the tester
- Input file hash and variant ID
- Raw extracted text or field export
- Tester notes and repeat-run outcome
Sources used on this page
- Resume Parser FieldsRChilli Documentation
Shows the structured fields a commercial parser can return, including experience, education, contact details, and skills.
- Unsuccessful resume parseGreenhouse Support
Documents parse failures, a 2.5 MB parsing limit, and layout-related errors.
- Concept: Candidate Skills MatchWorkday Documentation
Documents an optional skills-match feature, its supported files, and its Strong to Low labels.
- Structure of a WordprocessingML documentMicrosoft Learn
Documents the paragraph, run, and text structure inside DOCX files.
- Recognize text in scanned PDFs with AcrobatAdobe Help Center
Explains that OCR adds a searchable text layer to a scanned PDF.
- What you may be missing when you search PDF documentsPDF Association
Demonstrates how PDF content order can differ from the order visible on the page.