Tailor hard. Defend every word.

The tailoring trade-off

Every time you sit down to tailor a CV for a specific vacancy, you’re making a bet between two ways of losing. Change too little, and the document still reads like the same one you sent to the last role and the one before that — close enough to the vacancy to be relevant, not close enough to look like you actually read it. A recruiter’s first scan doesn’t find anything that speaks to this job in particular, because there isn’t anything there that does. Change too much, and a different risk opens up: hand the rewrite to an AI writer, ask it to sound like exactly what the vacancy wants, and you can end up with claims you didn’t actually make yourself — a scope you didn’t own, a result you can’t walk through if someone asks you to.

Neither failure is really about effort. A candidate who works hard at tailoring by hand can still land on the generic side, because reordering a few bullets and swapping a keyword doesn’t establish that this specific experience answers this specific requirement. And a candidate who reaches for a generator to go further can still land on the indefensible side, because fluent output and true output are not the same test, and nothing in a generic rewrite distinguishes one from the other. The usual advice quietly picks a side of this trade-off instead of resolving it — either “make small changes so nothing’s overstated” or “let the tool go further, it sounds more confident.” Both leave you carrying the same underlying uncertainty into the interview: does this document say what I can actually back up?

Why polish was never the hard part

A text generator is genuinely good at one thing: making a sentence read better. It can tighten a verb, cut a run-on, remove the filler a first draft always carries. That’s real, and it’s also not the problem tailoring exists to solve. Surface polish doesn’t tell you whether a claim matches the seniority the vacancy expects, whether the responsibility you’re describing is the one the requirement is actually asking about, or whether the sentence you just approved is still something you can defend if someone follows up on it in the room. A smoother sentence about the wrong thing is still the wrong thing, only harder to catch, because it no longer reads like something a template spat out.

That’s the quiet failure mode of treating tailoring as a writing problem. The writing gets better while the fit gets no more accurate, and the applicant walks away with a document that sounds more finished than it is — right up until a hiring manager asks a question the polish never had to survive.

What actually dissolves the trade-off

The trade-off holds as long as tailoring and grounding are two separate steps — rewrite first, hope it’s still true later. QuantCV builds the grounding into the tailoring itself, so pushing harder on relevance doesn’t cost you the ability to defend the result.

Every generated claim has to trace back to something you’ve actually confirmed — a fact about what you did, where it came from, what it’s connected to — held in what QuantCV calls your Candidate Evidence Graph. Nothing gets written into a tailored CV because it would read well for this vacancy; it gets written because there’s a piece of confirmed evidence behind it, and that link is what the tool can show you if you ask where a line came from.

When a vacancy requirement isn’t covered by what you’ve confirmed, it surfaces as a visible gap — never papered over, never quietly dropped. Where your evidence already partly covers that requirement, a targeted question follows: one question, tied to that exact requirement, not a generic “tell us about yourself” prompt. You can answer it, skip it, or mark it not applicable. Either way, nothing moves from “unconfirmed” to “claim” without you confirming it first.

And every transformation the tailoring makes — what got included, what got left out, what got reordered, what got rewritten — lands in the Tailoring Manifest, tied to the requirement and the evidence behind it. A change that isn’t in the manifest isn’t supposed to exist. Excluding something from the vacancy-specific version doesn’t erase it from your Master CV either; the source stays intact, and what you’re looking at is always a derived, traceable version of it, not a replacement for it. Tailor as hard as the vacancy actually warrants, and you still know exactly what changed and why — which is the piece that trade-off assumed you’d have to give up.

Four ways to look at it before you send it

A finished CV isn’t read by one gatekeeper, and it doesn’t fail for one reason, so a single score would hide more than it tells you. Before you send an application, you can look at it through four separate views: View as ATS is the deterministic parsing view — structure and reading order, as a machine sees it; Recruiter Review shows how the first scan reads your positioning and clarity; Hiring Manager Review checks whether each claim is actually backed by the evidence behind it; Consistency Guard checks whether your CV and cover letter agree with each other. Each one catches something the others don’t, which is the point of keeping them separate instead of folding them into one number.

Import the CV you already have and look at what changes — every decision from there stays yours.