One career, many versions

Some things should change per application and some must never. The mistake is leaving that boundary implicit and hoping the generator respects it.

What varies: the summary, which achievements appear, their order, their length, which skills are listed first. What does not: employers, titles, dates, figures, qualifications. Encode this distinction in the system rather than in a prompt.

Encoding it means the fixed fields are copied from the structured record rather than produced by generation at all. A model that never writes a date cannot get a date wrong, and that is a stronger guarantee than any instruction telling it to be careful with dates.

• Variable — summary, achievement selection, ordering, emphasis, length
• Fixed — employer names, job titles, dates, metrics, credentials
• Never generated — anything with no supporting record

A candidate can end up describing the same role as "led a team of four" in one version and "collaborated with a team of four" in another. Individually both are fine. Together, if both reach the same employer or the same recruiter’s desk, they are a credibility problem.

Generating from one structured record largely prevents this, because the underlying facts are shared. Where phrasing genuinely differs, keep it within what is defensible in conversation — the candidate has to stand behind every version.

Public profiles count as another version whether or not you manage them as one. A recruiter comparing a tailored CV against a professional profile that says something different is looking at exactly the same inconsistency, and that comparison happens on almost every serious application.

Moving from a generic CV to a targeted one is a large improvement. Moving from a targeted one to a highly targeted one is a small one, and the effort is better spent on the free-text answers and the cover letter, which are read more carefully.

Build the system to do the useful eighty percent automatically and stop. Endlessly re-tailoring is a way of feeling productive that produces very little change in outcomes.

Most of that eighty percent is two operations: reorder so the relevant experience is first, and make sure the posting’s actual vocabulary appears where it is true. Everything beyond those two is refinement, and refinement is where the returns flatten.

Aggressive tailoring can present someone as a specialist in something they have touched twice, because that is what the posting asked for. They then interview for a role they are not ready for, which wastes their time and the employer’s.

Cap how far emphasis can move from the centre of someone’s experience. If a posting requires a version that misrepresents them, the honest output is that this is not a good match — which is more useful than a document that gets them into the wrong room.

A workable cap is proportional rather than absolute. If a skill accounts for a small fraction of someone’s actual experience, it should not become the headline of their summary, and a system that measures that ratio can refuse the transformation without needing a human to notice it.

Quality here is mostly determined before generation runs. Handing a model the whole CV and the whole posting and asking for a tailored version produces mediocre output, because it has to do selection, ordering and writing simultaneously with no structure to work from.

Doing the selection deterministically first works far better: extract the posting’s requirements, score each achievement in the record against them, pick the top handful per role, and hand the model an ordered list with instructions to write them well. It is now doing one job instead of three.

This also makes the output inspectable. When a version emphasises the wrong thing, you can see whether the selection was wrong or the writing was, and those have completely different fixes.

Forty applications means forty documents, and a candidate preparing for an interview needs the one that was actually sent. Without version tracking, they are guessing at what the interviewer is holding.

Store each generated document against its application, show it on the application record, and make it retrievable in one action. This is unglamorous and it is the difference between a useful system and a folder full of files named resume-final-3.

Store the immutable file, not the parameters to regenerate it. A record saying which template and selection were used will produce a different document in three months when the model or the profile has changed, and the one thing the candidate needs is the document the interviewer is reading.