The industry admits this is unsolved. Every builder will write "increased revenue by 47%" if the number makes the bullet stronger and nothing stops it. This method makes that a failure, not a flourish.
A tool asked to strengthen a bullet will reach for a figure. If you do not catch it, you have walked into an interview defending a number you never produced.
Testers of the major builders found the same thing across all of them: the generators produce fictional achievement metrics, and one of them will suggest "increased revenue by 47%" with no context. None of them can verify a number they suggested. It happens because the training signal rewards a bullet that sounds strong, and a number is the shortest route to one.
The invented figure is usually in range, which is what makes it dangerous. Forty-seven percent is a believable improvement in most industries, so it survives your own review and you send it. Then an interviewer asks how you measured it and you have three bad options: admit you made it up, bluff the methodology, or withdraw the application.
The reason an agent can invent is that it is completing a sentence rather than checking a document. Give it a ledger of your own facts first and make every output line traceable to an entry in it, and the completion step has nothing left to guess with. This is the whole difference between a tool that writes prose and one that can be held to account.
Copy it into Zaira and paste your real history. It writes against a sourced evidence ledger and hands back every unsourceable line as a question instead of a claim.
Three outcomes, one loop. You stop losing interviews to questions you cannot answer, you get a document with no invented figures left in it, and you keep a record of where each claim came from.
Step 1 turns what you said into a numbered evidence ledger you correct before a word is written. After that the writing step has nothing to guess with, which is the actual mechanism that stops invention — not a warning not to do it.
Step 0 and Step 2 agree the refusals in advance and in detail, including the subtle ones: no team size converted into a percentage, no duty upgraded into an outcome, no title lifted, no tool attached to a role it was not used in. Those are how invented figures actually get in.
Step 4 returns one row per factual sentence with the ledger ID behind it, and unsourceable lines come back as the exact question needed to resolve them. You are not approving a document on trust; you are approving it on provenance.
The questions people ask once they realise they cannot trust an AI-written bullet.
Yes, and the people who test them say so plainly. Across the major builders the same finding comes back: they generate fictional achievement metrics, and they cannot verify a number they suggested, because the number is never checked against anything. One of them will produce a figure like a revenue percentage with no context behind it. The commercial tools have not solved this, which is why it is worth building a method around rather than assuming a tool handled it.
Because plausible is exactly what gets past you. An invented figure that is wildly out of range gets caught in your own review. One that sits inside the normal range for your industry survives your read, goes out with the application, and then fails in the interview when you are asked how you measured it — at which point you are withdrawing from a process you had already won. The cost lands at the worst possible moment.
It makes it honest, which is a different thing, and it makes specific lines weaker — the ones that were only strong because of an invented result. What it does not weaken is the rest of the document, because it is a restriction rather than a rewrite: every sourced fact you have is still available to you. In practice the finished resume is shorter on numbers and longer on defensible sentences, and it survives a technical interview, which is the only test that matters.
It is faster, and the reason is that checking is a lookup while writing is a search. You are confirming whether a fact exists rather than trying to decide how to describe one, and a ledger built once is reused for every application thereafter. That reuse is why the method is worth setting up properly: the ledger is an asset you build once, and every tailored variant after it is checked against the same source.
Then you have two honest options and the method supports both. Either you supply the figure now and it enters the ledger like any other fact, or you describe the scope in words instead — the size of the team, the volume, the timeframe, the constraint you worked under. Scope is legitimate evidence and does not require a percentage. What is not available is a figure you cannot source, even if the work itself was real.