Every CV Tool Says Its AI Won't Invent Facts. Here Are Seven Tests That Find Out

Why the claim needs testing at all

A language model asked to improve a CV is being asked, in effect, to make the candidate sound better. Inventing a plausible achievement is a very good way of doing that, and the model has no way of knowing you did not want it. The failure is not random noise; it is the model doing its job in a direction you did not intend.

The specific failures worth worrying about in a recruitment context are not exotic. A percentage appears that was not in the source. Two roles' responsibilities merge into one bullet, attributing an outcome to the wrong job. An acronym is expanded into a company name that does not exist. A date shifts by a year and closes an employment gap nobody asked to hide.

Any of those reaches a client under your branding. The candidate then gets asked about it at interview, and the person who looks careless is you.

Test 1: the figure that must survive

Take a CV with several numbers in one bullet — a revenue figure, a percentage and a headcount — and run it at the tool's strongest rewrite setting. Then compare the numbers, one at a time, against the original.

You are checking two things. First, that every figure is still present. Second, and less obvious, that each figure is still attached to the same claim. "Revenue grew 20% while costs fell 10%" and "revenue grew 10% while costs fell 20%" contain an identical set of numbers, and a vendor checking only for presence will pass the second one happily.

Ask the vendor directly whether their check is per-document or per-section. A figure moved from one job to another is a fabrication in every way that matters, and a document-level count will not see it.

Test 2: the acronym trap

Put an unfamiliar acronym in the CV — an employer abbreviated to three letters — and run a full rewrite. A model trying to be helpful will often expand it, and it will expand it into something that sounds entirely reasonable.

The distinction to look for: expanding HMRC to His Majesty's Revenue and Customs is derived from the acronym and correct. Expanding BCS to Brackenhill Construction Services spells the acronym perfectly and is a company nobody has heard of, because it does not exist. Both look equally plausible in a finished document.

A vendor that has thought about this will be able to describe how the two cases are separated. A vendor that has not will tell you their prompt says not to invent things.

Test 3: what happens when the check fails

This is the most revealing question in the list, and it takes one sentence: when your system detects that the AI has added something, what does the recruiter get?

There are only a few possible answers and they are not equally good. The document is returned with the invention removed — which means something rewrote the rewrite, and you should ask what. An error is shown and nothing comes back — safe, but useless on a deadline. The original reviewed content is returned unchanged with a notice explaining what was rejected — this is the one you want, because it fails toward the truthful document rather than toward no document.

The wrong answer, and the common one, is that nothing happens, because nothing was checking.

Test 4: edit, then rewrite, then look for your edit

Correct something by hand in the extracted record — fix a job title the parser misread — and then run a rewrite. Now find your correction in the output.

This catches an architectural problem rather than an AI one. If rewrites are applied cumulatively on top of the previous output, your edit can be overwritten, and each successive rewrite drifts a little further from the source document. If rewrites are rebuilt from the original parse with your edits re-applied on top, the correction survives and the drift cannot accumulate.

Ask which of those two the tool does. It is a question about how the product is built, and the answer tends to be honest because the vendor rarely expects it.

Test 5: the round trip on a bad scan

Feed the tool a genuinely poor input — a scanned PDF, a CV that is one wall of unbroken text with no headings, a document where the dates are in a table. This is the median real CV, not the exception.

What you are testing is whether the tool tells you when it is unsure. A parser that silently guesses an employer name on a layoutless document, and presents the guess with the same confidence as a value it read cleanly, is the more dangerous of the two failure modes, because there is nothing to review.

Good behaviour here looks like: a blank field rather than a wrong one, a visible confidence signal, and a way to see where in the original document a value came from.

• Does an uncertain field come back empty, or filled with a guess?
• Can you click a field and see the source page it was read from?
• Does the tool surface alternative readings it considered?
• Is there a warning when very little of the document was recovered?
• What happens to a scanned image with no extractable text?

Test 6: ask where the guarantee stops

This is the question that separates vendors who have done the work from vendors who have written the copy. Ask: what class of change can your check not detect?

Every honest answer to this is a limitation, and hearing one should increase your confidence rather than reduce it. Deterministic checks are good at things with an objective identity — figures, dates, structured fields like employers and job titles, capitalised entity names. They are much weaker at general meaning. A sentence can be rewritten to imply seniority the candidate did not have without introducing a single new number or proper noun.

A vendor who tells you their system catches everything is either not describing a real mechanism or has not looked hard enough at their own. The useful follow-up is: given that, what does the product do about the part you cannot check? The only good answer involves a human seeing a diff.

Test 7: can you see what changed, and can you undo it?

A guarantee you cannot inspect is a promise. Ask to see the before-and-after view, and check three things about it: that it shows every change rather than a summary, that it covers prose and not only structured fields, and that undo genuinely restores the previous state rather than re-running the model.

If the meaning of prose is ultimately the reviewer's judgement — and it is, in every tool in this category — then the quality of the review interface is the actual product. A tool with a weaker AI and an excellent diff is safer than a tool with a stronger AI and no way to see what it did.

How ConnectIQ answers these, including where it stops

It would be poor form to publish this list without answering it. Rewriting is four explicit modes rather than a slider: Format only makes no rewrite call at all, Tidy is a conservative copy-edit, Polish improves phrasing, and Transform is a full professional rewrite. The mode you pick is the mode that runs.

A guard checks the output before you see it — deterministic in what it rejects, and model-assisted only in what it forgives. Structured fields — employers, titles, dates, qualifications — are restored verbatim. Figures must form an identical set per scope rather than per document, so a number cannot migrate between jobs, and each figure must stay attached to its own clause, which is what stops the grew-20-fell-10 reversal. Common metric-polarity flips are rejected. Capitalised entities must be grounded in the source, and acronym expansion passes a deterministic gate only when the initials of the phrase spell an acronym the CV already contains. Past that gate the borderline case is put to a separate, isolated check that sees one flagged token and answers one closed question — so a plausible-sounding company expansion is declined by default. That makes the guard deterministic in what it rejects and model-assisted in what it forgives, and it fails closed: any error, timeout or non-answer leaves the rejection standing.

When the check fails, you get the reviewed source back with a notice saying what was rejected, never the unvalidated output. A failed rewrite retries free, re-prompted with the rule it broke, and if a band still cannot pass it steps down rather than erroring — so you always receive a document plus an honest account of what happened to it. Rewrites rebuild from the parse with your edits re-applied, so a correction you made by hand cannot be overwritten by a later rewrite.

And the boundary, stated plainly, because Test 6 is the one that matters: the guard covers structured fields, figure presence and attribution, common metric-direction changes and capitalised-entity grounding. It cannot detect every general meaning change in Polish or Transform prose. That part is the reviewer's approval via the diff. We would rather write that sentence here than let you discover it later.

• Four explicit modes, one of which makes no AI call at all
• Figures conserved per section, not per document
• Each figure checked against the clause it belongs to
• Acronym expansion gated on initials the CV already contains, then arbitrated by a check that fails closed
• A rejected rewrite returns the reviewed source plus a notice
• Rewrites rebuild from the parse, so manual edits survive
• Prose meaning in Polish and Transform is the reviewer's call, via the diff

The shortest version

If you only have ten minutes with a vendor, ask two questions. What happens to the document when your check fails? And what can your check not detect?

The first tells you whether a check exists. The second tells you whether the people who built it understand it. A vendor who answers both specifically has done the engineering; a vendor who answers either one with a reassurance has written a prompt and hoped.

Frequently asked questions

Can AI rewrite a CV without inventing anything?

A model alone cannot guarantee it — instructing a model not to fabricate reduces the rate but does not enforce it. What can be enforced is a check applied to the output afterwards: comparing figures, dates and structured fields against the source and rejecting the result when they do not match. Ask vendors what enforces the claim, not whether they make it.

What is the most common AI fabrication on a CV?

In practice: figures that appear or move between roles, achievements merged from two different jobs into one bullet, acronyms expanded into organisation names that do not exist, and dates normalised in a way that closes an employment gap. All four read as plausible in a finished document, which is exactly what makes them dangerous.

Does a deterministic check catch every fabrication?

No, and a vendor claiming otherwise is worth a second look. Deterministic checks are strong on things with an objective identity — figures, dates, employers, job titles, capitalised entities. They are weak on general meaning: prose can be rewritten to imply seniority without introducing a new number or name. That residue is why a reviewable before-and-after diff matters as much as the guard does.

Should recruiters use AI on candidate CVs at all?

Used with a review step, yes — the alternative is twenty to forty minutes of manual reformatting per CV. The requirement is that you can see what changed and that the tool fails toward the truthful document. Used without a review step, you are submitting text under your agency's name that nobody has checked.

What should I ask a CV formatting vendor about their AI?

Two questions carry most of the weight. What does the recruiter receive when your check detects an invention — the corrected document, an error, or the original with a notice? And what class of change can your check not detect? Specific answers to both indicate real engineering; reassurance in place of either indicates a prompt.

Try it on a real CV

Turn a candidate's own CV into a branded client submission you can check before it leaves the building. No card required, and every AI change is shown as a diff you approve before sending.

• Start free
• How the review step works
• Pricing and cost per CV
• More guides