Finding what is missing

A gap only exists relative to a target. Analysing a CV in isolation produces a list of things it does not mention, which is infinite and useless.

Define the target first: a specific posting, a role type, or a set of roles the candidate is aiming at. Comparing against a set is often more useful than a single posting, because one posting’s idiosyncratic requirement is not a gap in a career.

The aggregate view is the one that changes decisions. A requirement appearing in a quarter of the roles someone is pursuing is telling them something about the market that no individual posting can, and it is also how you tell a genuine gap from a single employer’s wish list.

This is the distinction that determines whether the tool is helpful. Someone may have three years of a skill and never named it, because it was implicit in what they built. That is a documentation gap, and it is fixable today.

A genuine absence is different: the skill is not there, and no rewrite will produce it. Telling a candidate to "add Kubernetes to your CV" when they have never used it is advice that fails in the first technical conversation.

Since the tool cannot tell these apart from the document alone, it should ask rather than assert. Phrasing a finding as "your CV does not evidence this — do you have it?" converts roughly half of all flagged gaps into a stronger application rather than a discouragement.

• Present and stated — nothing to do
• Present but unmentioned — a wording fix, with evidence
• Adjacent experience — mention the transfer explicitly
• Genuinely absent — a learning goal, not a CV edit

A list of twenty gaps is demoralising and unusable. Most of them do not matter: postings list far more than employers require, and "nice to have" sections are aspirational.

Rank by whether the gap is genuinely blocking, how often it appears across the target roles, and how long it would take to close. Three ranked gaps change behaviour; twenty unranked ones make someone close the tab.

Weight by how the requirement was written rather than where it appeared. A skill in the job title and repeated through the responsibilities is a real requirement; one item in a list of twelve under a heading nobody wrote carefully usually is not.

Gaps are not equivalent. Some are a weekend of documentation; some are a year of experience nobody can shortcut. Presenting them as one list implies they are the same kind of problem.

Be honest about the difference, including when the answer is that this gap cannot be closed in the time available and a different target is the better move. That is more useful advice than an achievable-sounding plan that is not achievable.

Separate what makes a CV stronger from what makes a candidate stronger. A course completed this month is a real thing to list and is not equivalent to two years of production experience, and a tool implying otherwise is preparing someone for a conversation that will go badly.

A tool tuned to be thorough will find gaps in every application, and a candidate shown a list of deficiencies before every submission applies to considerably less. That pattern disproportionately affects the people who already under-apply.

Calibrate towards applying. Reserve firm discouragement for genuine eligibility failures — the right to work, a required licence — and frame everything else as something to address within the application rather than a reason to stop.

Tone is a design requirement here rather than a nicety. This output is read by someone being rejected regularly, and a technically accurate summary of everything they lack will close the product without improving the search.

The failure that costs trust is reporting something absent when it is plainly in the CV under a different name. A candidate who has "built CI pipelines" told they lack "continuous integration" stops believing the rest of the output.

Match semantically, not lexically, and require the analysis to point at the evidence it did or did not find. A gap without a stated basis is a guess, and one wrong guess discredits the correct findings alongside it.

Keep a labelled set and run it on every change. Twenty CV and posting pairs with known correct findings catch the regression where a prompt edit starts producing lexical matches again, which is otherwise invisible until a user complains.