Skip to content
CogniYukti

Read and match

Parsing is table stakes. Showing your working is not.

Every applicant tracker parses a resume. The question is what happens when it gets something wrong — and whether you find out before or after you have sent the candidate to a client.

What is different

Each field carries the sentence it came from.

The read produces a set of canonical fields — who they are, how to reach them, where they are, what they do now, how long they have been doing it, how senior that makes them, and what they studied. Alongside those, your own custom fields are filled from the same document.

Every one of them shows the line it came from. So reviewing an extraction is reading four sentences rather than trusting a form, and the field that was guessed looks different from the field that was quoted.

  • Reviewed before it is saved

    The extraction is something you look at, not something that silently becomes the record.

  • Corrections become the truth

    Fix a field and the correction is captured against that record; the corrected value is what the next round reads as true. It is a loop inside your workspace, not a model somebody else trains.

  • Your custom fields too

    Filled from the same document, with the same source line — except the ones you classified sensitive, which are never sent to the reader at all.

  • Roles are read the same way

    The job description goes through an equivalent pass, which is what makes a verdict per requirement possible later.

Built here, not localised here

A CV is written the way its market writes them.

A bare ten-digit phone number. A location that is a neighbourhood rather than a city. A salary written in lakhs, or as an annual figure with a unit nobody outside that market uses. A recruiter abbreviation in the location field because that is what recruiters type.

Products built elsewhere store these as strings and let you search on them badly. Here they resolve — which means the person in Whitefield turns up when you filter for Bengaluru, and a budget written as twelve LPA is a number you can compare.

What the document saidWhat the record holds
  • 98XXXXXX21+91 98XXXXXX21a bare local number resolves to its country
  • WhitefieldBengalurua neighbourhood is still the city
  • Canary WharfLondonand it holds wherever you hire
  • 12 LPA₹12,00,000local salary units become comparable figures
  • £65k£65,000so do the shorthands everyone writes
None of this is clever. It is the difference between a product that reads the document your market actually writes, and one that had a currency symbol added to it.
Illustrative

Volume, honestly

Bulk import is a spreadsheet, not a folder of CVs.

If you are moving from another system, the import path is a structured one — your export, or a CSV or Excel file, with a dry run and a preview before anything commits, and a rollback if it goes wrong.

What there is not is a path where you point the product at three hundred PDFs and walk away. CVs are read one at a time, from the places they genuinely arrive — an application, an email, the browser extension, a database search.

The sceptical questions

Worth asking, and worth answering precisely.

Everyone parses resumes. What is actually different here?

Two things you can check on a document of your own. Every field shows the sentence behind it, and your correction to a field is what the next extraction treats as true. We do not claim resume parsing as a differentiator — we claim those two behaviours.

Does it extract notice period or current salary?

Not as canonical fields. If you need them held, make them custom fields and they are filled from the document like anything else — subject to the sensitivity classification, which is the right conversation to have about a salary on file.

Can we drop a folder of CVs in?

No. Bulk import works from a spreadsheet, with a dry run and a rollback. A folder of PDFs is not a supported path.

Where do the corrections go?

To your workspace only. They are captured against the record and read by the next extraction round for your tenant. Nothing leaves it.

What happens when a CV is badly formatted?

Fields it cannot support with a line from the document come back empty rather than filled with a plausible guess. An empty field you can see is cheaper than a wrong one you cannot.

Book a demo

Bring the worst CV you have.

The last one is the test. Anyone can parse a tidy CV.

  • A two-column PDF, or a scan
  • One with a bare ten-digit number and a neighbourhood for a location
  • One where the salary is written in lakhs
  • Correct a field we got wrong, then run it again