Most job seekers maintain exactly one document called CV_Final_v7.docx and edit it directly for every application. By the third application of a real search this stops working. Edits made for one role bleed into the next. The "final" version of last week is now a tailored version for a role you did not get, and reverting it is a manual reconstruction job. By application twenty, the document is an unreadable archaeology of overlapping rewrites.
The fix is not better discipline. It is a different system: separate the canonical record of your career from the per-application output, and treat tailoring as a transformation, not an edit. This is what people in the industry mean by "master CV." Done right, it cuts the per-application effort from ninety minutes to under ten without compromising quality, and it makes AI tailoring tools actually safe to use.
Key takeaways
- A master CV is the canonical, complete record of your career. A tailored CV is a per-application derivative, generated from the master and shaped to a specific job description.
- Editing a single CV file in place is the source of most application-fatigue, version drift, and accidental information loss.
- The right system has three layers: master CV, project library, tailored output. Each plays a distinct role and is updated on a different cadence.
- A grounded AI tool consumes the master CV plus project library and produces a tailored CV without inventing experience. Without that source, the AI must hallucinate to fill gaps.
- Done correctly, this workflow scales linearly: the tenth application takes the same time as the second.
The single-file problem
Almost everyone starts the same way. You have one CV. It is two pages. It contains the things you have done at the level of detail you considered "good enough" for the last role you applied to. When the next role comes up, you open the same file and start adjusting.
Three failure modes recur.
The first is information loss. You cut a bullet about a database migration because the new role does not care about it. Six applications later you apply to a database role and the bullet is gone — and you cannot remember the metric you originally wrote, because the version with that bullet has been overwritten.
The second is per-application drift. Each application introduces small edits: a sharper verb here, a different metric framing there, a section reorder. None of these decisions are recorded as decisions. Three months in, you cannot answer why your current "main" CV says "led" instead of "owned" for one role and "drove" for another. You stop trusting the file.
The third is scale collapse. Applying to one role with a 90-minute tailoring pass is fine. Applying to twenty is not. You either start sending a generic CV to most of them or you stop applying. Both outcomes are bad, and both come from the same cause: you are doing creative work per application instead of a transformation.
The single-file workflow is structurally limited. Adding more discipline does not fix it. You need a different shape.
The three-layer system
A workable system separates source from output. Three layers, each owned and updated independently.
Layer 1: the master CV
The master CV is the complete, canonical record of your career. It contains every role you have held, every meaningful bullet for each role, every relevant skill, and the full education and certification history. It is not formatted for any specific application. It is not filtered for relevance. It is the union of everything that might be useful for any future role.
A good master CV runs three to five pages. That is fine because it is never sent. Its purpose is to be the source of truth from which every tailored CV is derived. The constraint on the master CV is completeness, not concision.
You update it whenever you ship something noteworthy: a project went live, a metric came in, a promotion happened, a new tool was learned to a useful depth. Update it in the moment, not in a frantic pre-application pass when you remember half of what you did.
Layer 2: the project library
The project library is the layer most candidates do not have, and it is the one that makes the system actually work. It is a structured list of your specific projects — distinct from the role-level summary in the master CV — each captured with enough context to be reused.
Each project record has the same shape:
- Project name and one-line summary (what was it).
- Context (why did it exist, what problem did it solve, who was the customer or stakeholder).
- Tech stack or methodology (how was it done).
- Your scope (which parts you specifically owned, alongside whom).
- Outcome (what changed, with the actual metric if you have one — or an honest estimate marked as such).
Projects belong in the library if they could plausibly support a bullet on a tailored CV. A good library has fifteen to thirty projects across your career; some short, some career-defining. The point is that when a JD mentions "real-time data pipelines," you are not searching your memory for relevant work. You are filtering a list.
The project library is also the layer that gives a grounded AI tool something to work with. A model rewriting bullets from a structured project record cannot invent project details — it has been given the project. The same model rewriting from a vague role summary has no choice but to fabricate when the JD asks for specifics.
Layer 3: the tailored CV
The tailored CV is the output. It is the one to two-page document, formatted for ATS parsing, that you actually submit. It is regenerated per application from the master and the project library, with selection and rephrasing rules applied to match a specific job description.
A tailored CV is a derivative artefact. You should not be precious about it. If you generate it, send it, and never look at the file again, the system is working as intended. The next role gets a different derivative, generated fresh. There is no "merging" of one tailored CV into another.
This is the conceptual shift that makes the system scale: the tailored CV is disposable. The master CV and project library are durable. You invest your time in keeping the durable layers correct, and the disposable layer becomes cheap to produce.
How tailoring actually works in this system
Given a master CV plus project library plus a target job description, the tailoring pass does five things in sequence.
- Extract requirements from the JD. Hard requirements (must-have skills, tools, qualifications), soft requirements (collaboration patterns, working style), and domain vocabulary. The framework from how to tailor a CV to a job description covers this in detail.
- Match requirements to the project library. For each requirement, find the project records that support it. This is a filtering operation against structured data, not a creative writing task.
- Select bullets from the master CV. Choose the five to eight most relevant bullets per role, weighted by JD overlap and recency. Less relevant bullets are dropped from this output, not deleted from the master.
- Rephrase, do not invent. Rewrite selected bullets in the JD's vocabulary, using only facts present in the source records. No new metrics. No new technologies. No expanded scope.
- Reorder and format. Sequence sections and bullets so the most relevant material appears first, then format the whole thing as ATS-parseable .docx.
Each step is a transformation of structured input into a slightly different structured output. None of them require fabrication, and the AI's role is rewriting and selection, not creation.
A worked example
Consider a backend engineer applying to two different roles in the same week.
Role A: Senior Backend Engineer at a fintech, JD mentions distributed systems, Kafka, payments domain, regulatory compliance.
Role B: Senior Backend Engineer at a developer tools company, JD mentions API design, SDK development, developer experience, open source.
Same engineer. Same career. Two genuinely different CVs needed.
In a single-file workflow, this is two ninety-minute tailoring sessions, with the second one starting from a CV already half-mangled by the first.
In the three-layer system, the engineer's master CV contains both projects: a payments reconciliation pipeline (Role A flavour) and an internal SDK that became open source (Role B flavour). The project library has each captured as a structured record.
Tailoring pass for Role A pulls the reconciliation pipeline project to the front, surfaces Kafka and PostgreSQL prominently, leans into the regulatory framing already in that project's record, and demotes the SDK work to a single line in a "Other notable work" section. Total time, with a grounded tool: forty seconds for the draft, six minutes for review and tweaks.
Tailoring pass for Role B promotes the SDK project, surfaces API design decisions and the open-source release, and demotes the payments work. The master CV is unchanged. The Role A tailored output is unchanged. Both tailored CVs are honest derivatives of the same source.
Bullet rewrite, before and after
From the master CV (role-level, generic):
- "Worked on the payments reconciliation pipeline at Acme."
From the project library record for the same project:
- Project: Payments reconciliation pipeline rebuild
- Tech stack: Kafka, PostgreSQL, Go, AWS
- Scope: Owned the streaming consumer and the dispute-handling state machine; partnered with two other engineers on the storage layer
- Outcome: Cut end-of-day reconciliation time from 4 hours to 22 minutes; reduced manual exception cases by ~60%
For Role A (fintech):
- "Owned the streaming consumer and dispute-handling state machine in a payments reconciliation rebuild on Kafka and PostgreSQL, cutting end-of-day reconciliation from four hours to 22 minutes."
For Role B (developer tools), the same project might appear as a single line — or not at all — because it is not the relevant material. The bullet is not invented. The metrics are not invented. The scope is not invented. Only the selection and the framing change between the two outputs.
What an AI tool can and cannot do here
A tailoring tool is useful only if it respects the system. The right division of labour is:
You own the master CV and the project library. No AI should be writing project descriptions for projects you have not actually done. The library is where honesty enters the system.
The AI owns rephrasing and selection. Given the master, the library, and a JD, the AI picks the right bullets and rewrites them in the JD's language. This is high-volume, low-creativity work that benefits from automation.
The boundary matters. Tools that generate experience from a JD with no source material — the "blank test" from the grounded AI resume guide — are not tailoring tools. They are fabrication tools that happen to produce documents shaped like CVs.
RecastCV's tailor-CV feature is built around this division. You upload a master CV. You add projects to a library. The tailoring pass uses both as the only sources of truth. The AI cannot insert a metric or a technology that is not already in your records — and if your records are incomplete, the output makes the gap visible rather than papering over it. For a side-by-side with a tool that takes the opposite approach, see RecastCV vs Teal.
How often to update each layer
A common cause of system collapse is treating all three layers as if they need the same update cadence. They do not.
- Master CV: monthly, plus on every shipped milestone. Add new bullets, update metrics that have come in, capture promotions or scope changes. Five to ten minutes most months.
- Project library: per project, ideally as soon as the project ends. Capture the full record while you still remember the details. A project added two years late will be missing the specifics that make it useful.
- Tailored CV: per application. Generated, sent, archived. No ongoing maintenance.
If the master CV is more than three months stale when you start applying, do a one-hour catch-up pass before tailoring. The tailoring quality is bounded by the master's completeness; updating the master is the highest-leverage hour you can spend.
When the system fails
Three patterns cause the system to break down.
The master CV is too clean. If you have already filtered the master CV to "the parts I think are important," the tailoring pass cannot resurrect material for a role that needs different emphasis. The master should err toward completeness, even when bullets feel redundant or low-priority. Filtering happens at the tailoring stage, not the source.
The project library is empty or shallow. Without per-project records, the AI is rewriting from role summaries. Role summaries do not contain enough specificity to support tailored bullets without invention. This is the single most common reason tailoring outputs feel generic — there is no detail to draw on.
Tailored outputs leak back into the master. If you "improve" the master CV by copying a phrasing from a tailored output, you are reintroducing the single-file problem. The master should accumulate facts, not phrasings. Phrasings are application-specific and belong in the disposable layer.
FAQ
Frequently asked questions
What exactly is a master CV?
A master CV is the complete, canonical record of your career — every role, every meaningful bullet, every relevant skill — kept in one place and not formatted for any specific application. It is typically three to five pages and is never sent to employers. Its purpose is to be the source of truth from which a tailored, one-to-two-page CV is generated for each application. The constraint on the master CV is completeness; the constraint on the tailored CV is concision and JD relevance.
How is a master CV different from a tailored CV?
The master CV is the input. The tailored CV is the output. The master CV contains everything you have done across your career, captured at full detail. The tailored CV is a per-application derivative — selected, reordered, and rephrased to match a specific job description, formatted to one or two ATS-parseable pages, and submitted to a single employer. You maintain one master CV. You generate as many tailored CVs as you have applications.
Why is a project library separate from the master CV?
The master CV is organised by role. A project library is organised by project. The same project may have happened during one role but be relevant to many target jobs, and the structured fields in a project record (context, scope, tech stack, outcome) are exactly what an AI tool needs to rewrite a bullet without inventing details. A role-level summary in a master CV is too high-level to support tailored bullets reliably; the project library fills that gap.
How long should the master CV be?
Three to five pages is normal for a master CV with five-plus years of experience. Length does not matter because the master is never sent. What matters is whether every meaningful bullet from your career is captured at sufficient detail to be reused. If your master CV is two pages, it is probably already filtered — and you have lost the source material that lets you tailor for less obvious roles.
Can I run this system without an AI tool?
Yes. The three-layer structure (master CV, project library, tailored CV) is workflow-level and works manually. The AI tool just makes the per-application transformation faster — under a minute instead of thirty to ninety. If you do it manually, expect roughly an hour per application for tailoring once the master and library are in place. That is faster than starting from scratch each time, but slower than a grounded AI pass.
What if my career is short and I do not have many projects?
The system still applies — it just has fewer items in each layer. A graduate or early-career candidate may have a one-page master CV and four or five projects in the library. The shape of the system does not change. The benefit is also smaller because the per-application time savings scale with the size of your master CV, but the discipline of keeping source separate from output still pays off the moment you start applying to materially different roles.
Does this system work for non-technical roles?
Yes. The three layers are role-agnostic. A product manager's project library will contain initiatives, launches, and stakeholder programmes instead of code projects. A marketer's library will contain campaigns, channels, and reports. The structure — context, scope, methodology, outcome — applies to any work that has a beginning, a middle, and a measurable result.
Where to start
If you are currently maintaining a single CV file, the migration is one evening's work.
Start by promoting your current CV to a master CV. Add back everything you have trimmed over the past year — pull from old versions in your email outbox if needed. Aim for completeness over concision; the document does not need to be sendable.
Next, extract a project library. Go role by role and identify the three to ten projects per role that could plausibly support a tailored bullet. Capture each one in the structured shape (context, stack, scope, outcome). This is the highest-leverage hour you will spend on your job search, because it is the input that determines the quality of every future tailoring pass.
Finally, generate a tailored CV from the new master and library on your next application. If you are using RecastCV, the master upload and project library are the first-run setup; the tailoring is automatic from there. If you are doing this manually, follow the six-step tailoring framework.
The first application using the system will feel slower than usual because you are setting up the durable layers. The second will be faster than your old workflow. By the fifth, the difference is large enough that going back to a single-file workflow feels obviously wrong.
If you want to see what the credit-based version of this looks like in practice — three free credits at signup, no subscription, credits never expire — the pricing page walks through the packs.