Truthful Personalization: Turning Evidence into a Role-Specific CV

A strong evaluation tells career-ops which proof points matter, but it does not give the system permission to manufacture them. This chapter follows the next boundary: how a candidate's evidence becomes a role-specific CV without turning job-description language into false experience. The practical test is simple. A tailored document should sound as if it belongs to the role, while every factual claim should still be traceable to the candidate's own records or to an explicitly confirmed exception.

The source of truth has tiers

career-ops treats candidate evidence as a hierarchy rather than as one undifferentiated folder. The primary tier includes the user's CV, proof-point digest, profile configuration, personalization file, and writing samples. These files are the ground truth for claims about work, skills, numbers, authorship, and identity. They may be incomplete, but they are the places where a candidate can deliberately confirm or correct a fact.

A derived tier includes accumulated interview stories and company-specific preparation notes. Those files are useful because they contain narrative structure: a difficult decision, the sequence of actions, an outcome, and a reflection. They can help a candidate remember how to explain an experience. They are not automatically equivalent to the primary CV for quantified claims. An interview note may have been drafted to match a particular posting, and a plausible scale figure can become more confident each time it is copied into a new story. Career-ops therefore requires a number from a derived source to trace back to a primary file or carry an explicit provenance marker.

That distinction protects against a subtle form of fabrication. The number does not have to be invented in the current session to be unsafe. It may have entered a story bank during an earlier attempt to make a candidate sound like a good match. Repetition gives it the appearance of history, but repetition is not corroboration. The system's preferred answer to an unconfirmed number is not a forced guess. The candidate can confirm it, provide the correct figure, keep the story as qualitative narrative, or say they do not know. An honest unknown is safer than a confident estimate that later appears in a résumé, cover letter, and interview answer.

The same rule applies to authorship. Using a platform, language, or framework does not establish that the candidate built it. A project mentioned in a job description does not become a candidate project because it would improve keyword coverage. The candidate's records must explicitly support authorship. This is particularly important for a tool like career-ops, whose own repository contains many technologies and integrations. The system can help a candidate describe real experience with those tools; it cannot infer that the candidate authored career-ops or any other open-source artifact merely because the tool is present in the workspace.

Evidence source What it can safely provide
Primary candidate files Factual claims, metrics, roles, skills, and authorship when recorded there
Derived interview material Narrative structure and phrasing; numbers only with provenance or primary support
Job description Role vocabulary, requirements, and context about the employer's request
Model interpretation A proposed framing that still needs to stay inside the evidence boundary

The job description is therefore not a candidate source. It tells the system how the employer names a capability and where that capability appears in the role.