Per-job resume rewriting

Handing a model a CV and a posting and asking for a tailored version is how facts drift. Each rewrite is a fresh interpretation of prose, and dates, titles and figures mutate slightly with every pass.

Keep a structured source of truth — roles, dates, achievements with their metrics, skills with evidence — and generate documents from it. The facts then live in fields that do not change, and the model composes rather than reinterprets.

The drift is worst when versions are chained. Tailoring version eleven from version ten, which came from version nine, compounds small mutations until a job title has quietly changed and nobody can point to when — which is exactly the failure a single canonical record eliminates.

Good tailoring is mostly about what you leave out and what you lead with. The same career, ordered differently and trimmed differently, reads as a different candidate to two different employers — without a single altered fact.

So the first pass is selection: which achievements are relevant to this posting, in what order, at what length. Only then does generation phrase the selected items. Teams that start with generation end up fighting hallucination they created themselves.

Selection is also cheap and inspectable in a way generation is not. Scoring each achievement against the extracted requirements is deterministic enough to debug, and when a version emphasises the wrong thing you can see immediately whether selection or phrasing was at fault.

• Score each achievement against the posting requirements
• Select and order by relevance, trim to a realistic length
• Generate phrasing only for the selected items
• Verify every generated line against the structured record

Even with structured input, generated text can invent a detail — a team size, a percentage, a technology that was not in the record. It will be plausible, which is precisely why it survives review.

Run a verification pass that checks each claim against the source data and rejects anything unsupported. This is a machine-checkable property when the source is structured, and it is the difference between an automated document and a liability.

Watch for inflation as well as invention. "Contributed to" becoming "led", "helped migrate" becoming "owned the migration" — these introduce no new facts and change what the candidate is claiming, and they are the version of this problem that a naive claim-matching check will miss.

A CV rewritten wholesale by a model reads like every other model-written CV: the same rhythms, the same verbs, the same shape. Recruiters reading hundreds of these have started to spot the pattern, and it reads as effort avoided rather than effort spent.

Preserve the candidate’s phrasing where it works. Change emphasis, order and length; change the words only where the original genuinely obscures something relevant.

A reasonable default is to leave a bullet alone unless there is a specific reason to touch it. Rewriting everything on every application maximises both the drift risk and the sameness, and it buys nothing over rewriting the three lines that actually needed to change for this posting.

The quality of the whole pipeline depends on how well the posting is parsed, and postings are not written to be parsed. Responsibilities, requirements, nice-to-haves and company boilerplate are interleaved, and the same requirement often appears three times in different words.

Extract to a normalised list with a weight, rather than a flat set of strings. A skill named in the job title and repeated in the responsibilities matters more than one item in a bulleted list of twelve, and a selection step that treats them equally will lead with the wrong thing.

Deduplicate by meaning, not by string. A posting asking for "Kubernetes", "container orchestration" and "K8s experience" has stated one requirement three times, and counting it three times distorts every score downstream.

Once documents are generated per application, each one differs, and the candidate will be interviewed against a specific version. Not knowing which is a real problem in a real conversation.

Store the exact document sent with the application record, permanently. It is also what lets you improve — comparing which tailoring choices preceded responses is the only feedback this system will ever get.

Store the selection alongside the file, not just the file. Knowing which achievements were chosen and in what order is what makes the comparison across applications meaningful, and it costs a few fields to record at the moment the document is produced.