Before any score exists: what a resume pool goes through first

Real applications arrive as exported PDFs, Word files a recruiter reformatted, screenshots, and photographs of printed pages taken on a phone. A tool that only handles clean text quietly drops the rest, and the pool you evaluate is not the pool that applied.

MinMaxHR parses PDFs, Word documents, plain text, HTML, and image and scanned formats through OCR. That is an intake requirement, not a feature. A candidate should not lose a role because of the file format their laptop produced.

The same candidate applies through the careers page, then again through a job board, then a recruiter forwards the same file. Deduplicating after scoring wastes the compute and, worse, gives one person several positions in a ranked list.

Detection happens by content hash at intake, before any model sees the pool. It costs nothing and it keeps the shortlist honest.

Some documents are not resumes. Some are resumes a scanner mangled. The system identifies the document type and checks whether the content can support an evaluation, and says so when it cannot.

This matters for the number recruiters actually care about. A pool where nine percent of files failed to parse is a different pool from one where everything read cleanly, and you should be told which one you have.

With a clean, deduplicated, readable pool, CandidRanker evaluates every candidate against that specific job description across eight named dimensions in a single pass. Same inputs, same outputs, every run.

Hab builds the same discipline into work outside hiring. In document processing and approvals workflows the intake stage decides the quality of everything downstream, and it is where most implementations are won or lost.